קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
אחרי שהאפליקציה תעבד את הבקשה להצעת מחיר מ-Google, היא צריכה ליצור
ולשלוח תשובה. במדריך הזה מוסבר איך לתכנת את האפליקציה כדי ליצור
את התשובה.
יצירת הודעת Protobuf BidResponse
Authorized Buyers שולח את BidRequest כגוף ההודעה של
POST של HTTP. אם נקודת הקצה לבידינג מוגדרת לשימוש בפורמט Protobuf, האפליקציה צריכה לשלוח תשובה עם הכותרת Content-Type שמוגדרת כ-application/octet-stream וגוף הודעה שמכיל פרוטוקול של מאגר נתונים בסדרה. מאגר הפרוטוקול הוא הודעה מסוג BidResponse כפי שמוגדר ב-openrtb.proto. האפליקציה שלך חייבת להחזיר קובץ מנתח
BidResponse בתגובה לכל BidRequest. זמן קצוב לתפוגה ותשובות שלא ניתן לנתח נחשבות לשגיאות, ו-Google מגבילה את קצב שליחת הצעות המחיר של בידינגרים עם שיעורי שגיאה גבוהים.
אם אתם לא רוצים להגיש הצעות מחיר על חשיפות, תוכלו להגדיר רק את השדה BidResponse.ext.processing_time_ms ולהשאיר את כל השדות האחרים ריקים. אפשר לקבל את openrtb.proto מ
נתוני עזר.
מזהה הקריאייטיב
הערך BidResponse מציין קריאייטיב דרך
שדה BidResponse.seatbid.bid.crid (מגבלה של 64 בייטים). גם לנכסי קריאייטיב דומים צריכים להיות ערכים ייחודיים בשדה הזה אם יש להם מאפיינים בולטים שונים, כולל, בין היתר: גודל, כתובת URL שהוצהרה, מאפייני קריאייטיב וסוגים של ספקים. במילים אחרות, עליכם להקצות מזהי קריאייטיב שונים לשתי מודעות:
מראה או התנהגות שונים.
עיבוד לתמונות שונות.
עיבוד באמצעות אמצעים שונים (לדוגמה, מודעה אחת מורכבת מתמונה והשנייה מורכבת מסרטון).
כשמעצבים את האפליקציה, צריך להחליט על דרך שיטתית ליצירת מזהים שתתאים לסוגי הקריאייטיב שאתם מתכננים לשלוח.
מאפייני מודעה
Google ממליצה להצהיר על מאפייני קריאייטיב כדי לתאר את המודעה
המאפיינים והטירגוט שלו באמצעות שילוב של
BidResponse.seatbid.bid.apis והקבוצה
BidResponse.seatbid.bid.attr, או
תוסף BidResponse.seatbid.bid.ext.attribute. בהמשך מוסבר איך מגדירים מאפיינים:
VPAID
מגדירים את BidResponse.seatbid.bid.apis לערך VPAID_1 או VPAID_2. בפורמט JSON, אפשר להגדיר את הערך הזה כך:
1 או 2 בהתאמה.
MRAID
מגדירים את BidResponse.seatbid.bid.apis לערך MRAID_1 או 3 עבור פורמט JSON.
SIZELESS
הגדרה של BidResponse.seatbid.bid.attr לערך
RESPONSIVE, או 18 בשביל ה-JSON
הפורמט.
PLAYABLE
כדי לציין זאת, מגדירים את BidResponse.seatbid.bid.attr לערך USER_INTERACTIVE או 13 לפורמט JSON.
תגובות לבקשות להצעת מחיר שנשלחו ממגישי הצעות מחיר ב-Exchange וברשת של מגישי הצעות מחיר שמשתתפים בתוכנית Open.
הבידינג דומה לשיטות הבידינג של Authorized Buyers שמשתתפים בתוכנית הרגילה
בידינג בזמן אמת. לקוחות שמשתמשים ב-Open Bidding יכולים לציין מספר קטן
בשדות נוספים, ובכמה שדות קיימים עשויים להיות שימושים חלופיים. למשל:
OpenRTB
Authorized Buyers
פרטים
BidResponse.imp[].pmp.deals[].id
BidResponse.ad[].adslot[].exchange_deal_id
מזהה העסקה ממרחב השמות של פלטפורמת ה-Exchange שמשויך לבידינג הזה ומדווח לבעלי האפליקציות.
אסימון המשמש לזיהוי פרטי הקונה הסופי מצד שלישי, אם מערכת ה-Exchange כמציע במכרז Open Bidding היא מתווך. הוא מתקבל
קונה מצד שלישי ויש להעבירו אל Google ללא שינוי בהצעת המחיר
תשובה.
המלצות
להפעיל חיבורי HTTPS מתמידים (שנקראים גם 'Keep-alive', או
'שימוש חוזר בחיבור') בשרתים. כדאי להגדיר את הזמן הקצוב לתפוגה ל-10 שניות לפחות. במקרים רבים, כדאי להגדיר זמן קצוב ארוך יותר. Google מאמתת זאת במהלך בדיקות זמן האחזור הראשוניות של האפליקציה, כי תוכנית Authorized Buyers שולחת בקשות בקצב גבוה וצריך להימנע מהזמן הנוסף שנדרש ליצירת חיבור TCP נפרד לכל בקשה.
מומלץ לכלול את כתובת ה-URL האופציונלית למעקב אחר חשיפות כדי לעקוב אחרי הזמן שבו החשיפות מוצגות, ולא אחרי הזמן שבו המשתמש שהגיש את הצעת המחיר הגבוהה ביותר זכה. בגלל הנטישה
בין ניצחונות לבין עיבודים, כך מתקבל מעקב מדויק יותר
סטטיסטיים.
עליכם לדאוג שהקוד של מגיש הצעות המחיר לא תלוי בשדות שהוצאו משימוש.
מה שעלול לגרום להצעות מחיר להיכשל ולגרום לשגיאות.
כוללים את BidResponse.seatbid.bid.w ו-BidResponse.seatbid.bid.h ב-BidResponse. א'
BidResponse לבקשה שכוללת כמה גדלים של מודעה חייבת
כוללים את השדות האלה, אחרת הם יוסרו מהמכרז.
אפשר להגביל את גודל התשובה לערך של פחות מ-8K. תגובות גדולות מאוד עלולות להאריך את זמן האחזור ברשת ולגרום לחריגות מזמן הקצוב.
חשוב: הודעות ה-Protobuf שמופיעות ב
הדוגמאות מיוצגות כאן כטקסט קריא לאנשים. עם זאת, זו לא הדרך
ההודעות נשלחות דרך החוט. כשמשתמשים בפורמט Protobuf של Google או OpenRTB, מתקבלות רק הודעות BidResponse בסדרה.
אפשר ליצור הודעה מסוג BidResponse ולסדר אותה בסדרת ביטים באמצעות הקוד הבא ב-C++:
BidResponse bid_response;
// fill in bid response with bid information
string post_response;
if (bid_response.SerializeToString(&post_response)) {
// respond to the POST with post_response as the content
} else {
// return an error to the POST
}
ציון הקריאייטיב
התגובה להצעת מחיר מציינת את הקריאייטיב שיוצג אם הצעת המחיר תזכה. הצעת המחיר חייבת לכלול אחד מהפורמטים הנתמכים של המודעות (AMP, וידאו, מודעות מותאמות). כאן
אנחנו מציינים את הקריאייטיב באמצעות השדה html_snippet.
לחלופין, אפשר לציין את הקריאייטיב באמצעות אחד
על סמך פורמט המודעה:
מודעה שעבר עיבוד על ידי SDK
BidResponse.seatbid.bid.ext.sdk_rendered_ad
דפי AMP
BidResponse.seatbid.bid.amp_ad_url
וידאו
BidResponse.seatbid.bid.adm
מותאמת
BidResponse.seatbid.bid.adm_native
מציינים מודעה שמתארחת בשרתים שלכם באמצעות קטע קוד HTML בשדה BidResponse.seatbid.bid.adm. קטע הקוד מוקף ב-iFrame שמוחדר בדף האינטרנט, וכתוצאה מכך המודעה מאוחזרת ומוצגת כשהדף נטען. צריך ליצור את קטע קוד ה-HTML כך
מודעה (מודעת באנר או מודעת מעברון) מוצגת בצורה תקינה בתוך iFrame, וב
המתאים למיקום המודעה שעליו אתם מגישים הצעות מחיר.
בנוסף, גודל המודעה המוצהר בתגובה להצעת מחיר חייב להתאים בדיוק לאחד
של שילובי הגדלים בבקשה להצעת המחיר כאשר:
המודעה היא מודעת באנר רגילה (לא מודעת וידאו, מודעת וידאו מותאמת או מודעת מעברון).
המגיש הצעת המחיר הצהיר על הגודל בתשובה להצעת המחיר. הצהרת הגודל היא
נדרש כשבבקשה מופיע יותר מגודל אחד.
יש חריג למודעות מעברון. הרוחב של מודעות מעברון
צריך להיות לפחות 50% מרוחב המסך ואת הגובה של 40% לפחות
את גובה המסך.
אפשר לציין נכס קריאייטיב מסוג קטע קוד HTML באמצעות כל קוד HTML תקין שמוצג בצורה תקינה, אבל חשוב לזכור את ההגבלות על ציון השדה crid בקטע יצירת הודעת BidResponse.
אחת מהשימושים האפשריים היא להוסיף מידע נוסף לארגומנטים של כתובות ה-URL שאוחזרות מהשרתים שלכם כחלק מהעיבוד של המודעה. כך תוכלו להעביר חזרה לשרתים שלכם נתונים שרירותיים לגבי החשיפות.
פקודות מאקרו הן טקסט שמוטמע בשדות מסוימים של תגובה להצעות מחיר,
כתובות URL שמוחלפות בערך רלוונטי בזמן הצגת המודעה. לדוגמה,
אם הצעת המחיר הזוכה כללה את המאקרו AUCTION_PRICE ב-HTML
בקטע הקריאייטיב שנכלל בהצעת המחיר שלך, המאקרו יוחלף
שאפשר לפענח אותו כדי לקבוע את הסכום ששילמתם על החשיפה
המכרז.
אפשר לכלול מק"טים בשדות הבאים:
BidResponse.seatbid.bid.adm
יש תמיכה במאקרו בפורמטים הבאים: קטע קוד HTML, מודעות וידאו מותאמות אישית, כתובת URL של סרטון ו-VAST XML של סרטון.
משתמשים באפשרות הזו במקום ב-BidResponse.seatbid.bid.burl אם צריך יותר מכתובת URL אחת לחיוב.
לדוגמה, אפשר לכלול מאקרו כחלק מקטע HTML על ידי הטמעת ${MACRO} בכתובת ה-URL שמשמש לאחזור הקריאייטיב, כאשר MACRO הוא אחת מפקודות המאקרו הנתמכות שמתוארות במפרט OpenRTB.
פקודות מאקרו של Google RTB
Google תומכת בפקודות מאקרו נוספות מלבד אלה שנמצאות ב-OpenRTB
מפרט הם מופיעים בפורמט שונה, והם יופיעו כך
%%MACRO%% אם הוא מוטמע בכתובת URL. הטבלה הבאה מתארת
פקודות המאקרו הבאות:
מאקרו
תיאור
ADVERTISING_IDENTIFIER
מאפשרת לקונים לקבל IDFA של iOS או מזהה פרסום של Android בזמן עיבוד החשיפה.
למידע נוסף בנושא פענוח של מזהי המפרסם
אפשר לקבל פרטים נוספים.
CACHEBUSTER
ייצוג מחרוזת של מספר שלם אקראי ללא סימן באורך ארבעה בייטים.
CLICK_URL_UNESC
כתובת ה-URL של הקליק על המודעה, המערכת לא תסמן בתו מילוט (escape). בקטע הקוד, תו בריחה (escape)
של כתובת האתר לקליקים של צד שלישי צריכה להופיע ישירות
במאקרו.
לדוגמה, אם כתובת ה-URL של הקליק של הצד השלישי היא
http://my.adserver.com/some/path/handleclick?click=clk,
אפשר להשתמש בקוד הבא עם הגרסה עם תווי בריחה (escape) יחיד.
של כתובת ה-URL לקליקים של צד שלישי לאחר הפעלת המאקרו:
כתובת ה-URL קודם כל תרשום את הקליק ב-Google, ואז תפנה לכתובת אחרת
לכתובת האתר לקליקים של הצד השלישי.
CLICK_URL_ESC
כתובת ה-URL של הקליק על המודעה עם תווי ה-escape. שימוש בטיוטה הזו במקום
CLICK_URL_UNESC אם צריך להעביר קודם את הערך באמצעות
שרת אחר שיחזיר הפניה אוטומטית.
הפעולה הזו תירשם את הקליק ב-my.adserver.com, שתהיה אחראית להפניה לכתובת ה-URL שהועברה בפרמטר google_click_url. בהנחה
my.adserver.com גורם ליציאה מהטווח
google_click_url.
אפשר לצרף כתובת URL עם שני תווי בריחה אחרי %%CLICK_URL_ESC%%. אחרי שה-my.adserver.com מבצע את ה-Unescape, נשארת גרסה של כתובת ה-URL עם בריחה אחת שמצורפת ל-google_click_url. כשה-google_click_url ייאוחזר, הוא יוסר ממנו ה-escape שוב ואז תתבצע הפניה אוטומטית.
CLICK_URL_ESC_ESC
כתובת ה-URL של המודעה עם תווי escape כפולים. משתמשים בערך הזה במקום ב-CLICK_URL_UNESC אם צריך להעביר את הערך דרך שרת אחר, שיחזיר לאחר מכן הפניה אוטומטית.
הורחב ל-http: אם בקשת הצעת המחיר לא מחייבת SSL או
https: אם הבקשה להצעת המחיר מחייבת SSL.
SITE
הדומיין של כתובת ה-URL של התוכן, עם תוויות בריחה (escape) של כתובות URL, או המזהה האנונימי של מלאי שטחי הפרסום האנונימי.
SITE_URL
הוצא משימוש. הוחלף על ידי המאקרו SITE שמספק פונקציונליות זהה.
TZ_OFFSET
הסטייה מאזור הזמן.
VERIFICATION
הערכים השונים בסביבת הייצור והמועד שבו הקריאייטיב נסרק
בצינור האימות. הפורמט הוא:
%%?VERIFICATION:true-val:false-val%%, כאשר אפשר להשתמש בכל הערכים
מלבד מאקרואים עבור true-val ו-
false-val, כולל מחרוזות ריקות. עבור Open Bidding,
מומלץ שפלטפורמות ה-Exchange ישתמשו במאקרו הזה; ברגע שהם עושים את זה,
הפלטפורמות לא צריכות לבצע שינויים.
לדוגמה, אם הקריאייטיב צריך לכלול
%%?VERIFICATION:-1:5000%% ואז הטקסט החלופי
יהיה 5000 בהצגת מודעות ו--1 בהגשה
של צינור עיבוד הנתונים. המטרה היא לעזור להבדיל בין שתי הקבוצות האלה של פינגים.
WINNING_PRICE
עלות החשיפות המקודדות (כלומר עלות לחשיפה במקום עלות לאלף חשיפות) במיקרו-מטבעות של מטבע החשבון. לדוגמה, עלות מנצחת לאלף חשיפות בסך 20 ש"ח
תואם עלות לאלף חשיפות (CPM) של 5,000,000 מיקרוים או 5,000 מיקרו-עלות להתקנה (CPI). הקוד המפוענח
הערך של WINNING_PRICE במקרה הזה יהיה 5,000.
המחיר הזוכה מצוין בעלות להתקנה (CPI).
כדי לנתח את המאקרו הזה, תצטרכו להטמיע אפליקציה שמפענחת את אישורי המחירים. למידע נוסף, אפשר לעיין בדף פענוח של אישורי מחירים.
WINNING_PRICE_ESC
WINNING_PRICE, המערכת תסמן בתו מילוט (escape) את כתובת ה-URL.
Google דורשת להשתמש בCLICK_URL_UNESC או
מאקרו CLICK_URL_ESC בתוך הקריאייטיב של המודעה המוצגת על ידי הצד השלישי
המודעה. Google משתמשת במאקרו CLICK_URL למעקב אחר קליקים.
כתובת בריחה של כתובת URL בפקודות מאקרו משתמשת בסכמה הבאה:
תו הרווח מוחלף בסימן פלוס (+).
תווים אלפאנומריים (0-9, a-z, A-Z) ותווים מתוך הקבוצה !()*,-./:_~ לא משתנים.
כל שאר התווים מוחלפים ב-%XX, כאשר XX הוא ההקסדצימלי
מספר שמייצג את התו.
הגבלות ודרישות לבעלי תוכן דיגיטלי
בקשת הצעת המחיר כוללת מידע על סוגי ההגבלות והדרישות שמפרסמים מטילים על נכסי הקריאייטיב במכרז.
BidRequest.bcat
אפשר להשוות בין הקטגוריות החסומות שצוינו בשדה הזה לבין הקטגוריות שזוהו בנכסי הקריאייטיב ששלחתם באמצעות השדה detectedCategories ב-Real-time Bidding API.
BidRequest.imp.ext.allowed_vendor_type
BidRequest.imp.secure
בפועל, הערך הזה תמיד יהיה true כי Google דורשת תמיכה ב-SSL לכל נכסי הקריאייטיב.
BidRequest.imp.{audio/banner/native/video}
BidRequest.imp.{audio/banner/native/video}.api
BidRequest.imp.{audio/banner/native/video}.battr
BidRequest.imp.{audio/banner/video}.mimes
לעולם אל תגישו הצעות מחיר על מודעות שמכילות תכונה מוגבלת. לגבי תכונות מותרות, כמו סוג הספק, מחזירים מודעה רק אם סוג הספק שלה נמצא ברשימה allowed_vendor_type בקובץ BidRequest. הצעת המחיר צריכה לכלול רק את פורמטים המודעות שצוינו בבקשת הצעת המחיר על ידי מילוי שדות כמו BidRequest.imp.banner. פרטים נוספים זמינים בתגובות לשדות האלה בהגדרה של מאגר ה-Protocol BidRequest.
אם מודעה מוחזרת בחודש BidResponse, עליך
הגדרה מדויקת של BidResponse.seatbid.bid.attr,
BidResponse.seatbid.bid.cat, וגם
BidResponse.seatbid.bid.adomain או
BidResponse.seatbid.bid.adm_native.link.url שדות ב
BidResponse אם למודעה יש כמה ערכים רלוונטיים
צריך לכלול כל ערך. אפשר לראות את התגובות בשדות האלה ב-
בהגדרה של מאגר הנתונים הזמני של הפרוטוקול BidResponse לפרטים נוספים.
המערכת תמחק תשובות שלא הוגדרו בהן השדות האלה.
פתיחת המדידה
מדידה פתוחה מאפשרת לך לציין ספקי צד שלישי שמספקים
שירותי מדידה ואימות למודעות שהוצגו באפליקציה לנייד
בסביבות שונות.
הפורמטים הנתמכים של מודעות כוללים מודעות וידאו, מודעות באנר ומודעות מעברון. לקבלת מידע נוסף
מידע על השימוש במדידה פתוחה בתגובה להצעת מחיר שכוללת את
בפורמטים, קראו את המאמר Open Measurement SDK
מאמר במרכז העזרה.
דוגמאות לתשובות לבקשות להצעת מחיר
בקטעים הבאים מוצגות תגובות לדוגמה לבקשות להצעות מחיר לסוגים שונים של מודעות.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2024-10-16 (שעון UTC)."],[],[]]