עיבוד הבקשה

אינטראקציה של בידינג בזמן אמת מתחילה כש-Google שולחת בקשה להצעת מחיר לאפליקציה שלכם. במדריך הזה מוסבר איך לכתוב קוד לאפליקציה כדי לעבד את בקשת הצעת המחיר.

בקשת ניתוח

‫Google שולחת בקשה להצעת מחיר שעברה סריאליזציה בפורמט OpenRTB JSON או Protobuf, שמצורפת כמטען ייעודי (payload) של בקשת POST. הפורמט שמתקבל תלוי בהגדרה של נקודת הקצה. דוגמה לבקשה להצעת מחיר

צריך לנתח את הבקשה הזו כדי לקבל את ה-BidRequest שעבר סריאליזציה. אם אתם משתמשים בפורמט Protobuf, אתם צריכים להוריד את openrtb.proto ואת openrtb-adx.proto מהדף נתוני עזר, ולהשתמש בהם כדי ליצור ספרייה שאפשר להשתמש בה כדי לנתח את ההודעה BidRequest. לדוגמה, קוד ה-C++‎ הבא מנתח בקשה שניתנה למטען ייעודי (payload) של POST במחרוזת: 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

אחרי שיש לכם את BidRequest, אתם יכולים לעבוד איתו כאובייקט, לחלץ את השדות שאתם צריכים ולפרש אותם. לדוגמה, ב-C++‎, איטרציה על עסקאות ב-OpenRTB‏ `BidRequest` יכולה להיראות כך:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

מספרי לקוח לחיוב

אתם מקבלים בקשת בידינג כשמלאי שטחי הפרסום של בעל תוכן דיגיטלי מטורגט על ידי הגדרות טרום-טירגוט אחת או יותר שלכם. BidRequest.imp.ext.billing_id יאוכלס במספרי לקוח לחיוב של כל הקונים שעומדים בדרישות, ובהגדרות טירגוט מראש רלוונטיות. בנוסף, עבור מלאי שטחי פרסום של עסקאות, אפשר למצוא מספרי לקוח לחיוב שמשויכים לקונים הרלוונטיים באמצעות BidRequest.imp.pmp.deal.ext.billing_id. כשמגישים הצעת מחיר, אפשר לציין רק מספרי לקוח לחיוב של קונים שנכללים בבקשה להצעת מחיר.

אם בקשת הצעת המחיר כוללת כמה מספרי לקוח לחיוב, צריך לציין בשדה BidResponse.seatbid.bid.ext.billing_id את מספר הלקוח לחיוב של הקונה שאליו רוצים לשייך את הצעת המחיר.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

איך קובעים קטגוריות חסומות

כשמגישים הצעת מחיר, הקריאייטיב שכלול בה לא יכול לכלול קטגוריות שזוהו ונחסמו על ידי בעל האפליקציה. אחרת, הצעת המחיר מסוננת מהמכרז.

כדי לראות אילו קטגוריות נחסמו בהצגת חשיפה, בודקים את השדה BidRequest.bcat, שמאוכלס בקטגוריות מטקסונומיה שהוגדרה בחשבון.

בדוגמה הבאה מוצגות קטגוריות חסומות על סמך טקסונומיה מוגדרת של קטגוריות מודעות:

טקסונומיית התוכן של IAB בגרסה 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

קביעת קטגוריות לפי הקשר

בקשות להצעות מחיר יכולות לכלול שדות של קטגוריות הקשריות שמתארים את האתר או האפליקציה שבהם מתרחשת חשיפה. השדות האלה משתמשים גם בטקסונומיות של קטגוריות מודעות, אבל הם מייצגים את ההקשר של החשיפה, ולא הגבלות על הקריאייטיב. יכול להיות שהשדות האלה לא משתמשים באותה טקסונומיה כמו השדה BidRequest.bcat. ‫Google או בעל התוכן הדיגיטלי יכולים לספק את הקטגוריות ההקשריות האלה. שימוש בקטגוריות לפי הקשר יכול לשפר את הערכת החשיפות, את הטירגוט לפי הקשר ואת ההגנה על המותג.

קטגוריות הקשריות שזוהו על ידי Google

‫Google מאכלסת את השדות הבאים בקטגוריות התוכן של IAB שזוהו באתר, באפליקציה או בדף:

שדה תיאור
BidRequest.site.cat מערך של מזהי קטגוריות תוכן שמתארים את האתר.
BidRequest.site.pagecat מערך של מזהי קטגוריות תוכן שמתארים את הדף או התצוגה הנוכחיים של האתר.
BidRequest.app.cat מערך של מזהי קטגוריות תוכן שמתארים את האפליקציה.
BidRequest.app.pagecat מערך של מזהי קטגוריות תוכן שמתארים את הדף או התצוגה הנוכחיים של האפליקציה.

אפשר למצוא את הטקסונומיה המדויקת שמשמשת בשדות האלה לבקשה נתונה להצעת מחיר בשדות BidRequest.site.cattax או BidRequest.app.cattax. יכול להיות שלא תמיד יאוכלסו שדות של קטגוריות הקשריות בגלל העדפות של בעלי האתרים או חששות רגולטוריים. מידע נוסף זמין במאמר קטגוריות הקשר לפי תקן OpenRTB ב-Google Ad Manager.

אותות שמספקים בעלי תוכן דיגיטלי

בנוסף לקטגוריות הקשריות שזוהו על ידי Google, בקשות להצעות מחיר עשויות להכיל גם אותות שסופקו על ידי בעל התוכן הדיגיטלי, שמתארים גם את ההקשר של חשיפה. בניגוד לקטגוריות לפי הקשר ש-Google מזהה, האותות האלה מאוכלסים רק אם בעל האפליקציה מספק אותם. האותות האלה נשלחים באובייקטים BidRequest.site.content ו-BidRequest.app.content, כמו content.data.segment ו-content.genre. הטקסונומיה שמשמשת לרשומות content.data.segment מדווחת ב-content.data.ext.segtax. מידע נוסף זמין במאמר בנושא אותות שמספקים בעלי תוכן דיגיטלי (PPS) לבידינג בזמן אמת (RTB).

קובצי מילון

הבקשה להצעת מחיר משתמשת במזהים שמוגדרים בקובצי מילון, שזמינים בדף נתוני העזר.

פקודות מאקרו של כתובות URL של מגיש הצעות המחיר

אופציונלית, אפשר להשתמש בפקודות מאקרו כדי להוסיף חלק מהמידע מBidRequest לכתובות URL של נקודות קצה לבידינג. אם מגדירים כתובת URL של נקודת קצה עם פקודת מאקרו אחת או יותר, הן יורחבו אם המידע הזה קיים בבקשה להצעת מחיר. לדוגמה, זה יכול להיות שימושי אם רוצים לבצע איזון עומסים על סמך מידע ב-BidRequest. כדי לבקש תמיכה בפקודות מאקרו חדשות, צריך לפנות למנהל החשבון.

Macroתיאור
%%GOOGLE_USER_ID%%

הוחלף במזהה המשתמש ב-Google שנמצא ב-BidRequest.user.id. לדוגמה, כתובת ה-URL של מגיש הצעות המחיר http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% תוחלף בזמן השליחה של הבקשה במשהו כזה: http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl.

אם מזהה המשתמש ב-Google לא ידוע, מוחלפת מחרוזת ריקה, והתוצאה דומה לתוצאה הבאה:

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

הוחלף ב-1 כדי לציין שהבקשה להצעת מחיר היא ממכשיר נייד, או ב-0 אחרת. ההגדרה הזו מבוססת על הערך של BidRequest.device.devicetype, שבו מכשירים ניידים מסומנים בערך HIGHEND_PHONE (4) או Tablet (5).
%%HAS_VIDEO%%

מוחלף ב-1 כדי לציין שבבקשה להצעת מחיר יש מלאי שטחי פרסום למודעות וידאו, או ב-0 במקרים אחרים. ההחלטה אם להציג את המודעה מבוססת על הערך של BidRequest.imp.video בבקשה להצעת מחיר.
%%IS_CTV%%

הוחלף ב-1 כדי לציין שהבקשה להצעת מחיר מגיעה ממכשיר CTV, או ב-0 אם לא. החישוב מבוסס על הערך של BidRequest.device.devicetype. ב-Protobuf, מכשירי CTV הם CONNECTED_TV, CONNECTED_DEVICE או SET_TOP_BOX, שתואמים לערכי המספרים השלמים 3, 6 או 7 ב-JSON.
%%HOSTED_MATCH_DATA%%

הוחלף בערך שמבוסס על BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

הוחלף ב-1 כדי לציין שהבקשה להצעת מחיר מיועדת למלאי שטחי פרסום באפליקציה לנייד, או ב-0 אחרת. ההחלטה אם להציג את הנתון הזה מתבססת על כך שהשדה BidRequest.app מאוכלס.

איך מוצאים את מזהה האפליקציה לנייד מכתובת ה-URL של העסקה

עסקאות באפליקציות לנייד ידווחו על כתובות URL שנראות כך:

mbappgewtimrzgyytanjyg4888888.com

משתמשים במפענח base-32 כדי לפענח את החלק המודגש במחרוזת (gewtimrzgyytanjyg4888888).

אפשר להשתמש במפענח אונליין, אבל צריך להשתמש באותיות רישיות ולהחליף את התווים 8 בסוף בערכים של =.

אז פענוח הערך הזה:

‫
GEWTIMRZGYYTANJYG4======
 התוצאה: 
1-429610587
 המחרוזת 429610587 היא מזהה האפליקציה של האפליקציה ל-iOS‏ iFunny.

הנה דוגמה נוספת. כתובת ה-URL שדווחה היא: 

mbappgewtgmjug4ytmmrtgm888888.com
 פענוח הערך הזה: 
GEWTGMJUG4YTMMRTGM======
 תוצאה: 
1-314716233
 התוצאה 314716233 היא מזהה האפליקציה של האפליקציה ל-iOS‏ TextNow.

חיפוש שם של אפליקציה לנייד מכתובת URL של עסקה

הנה דוגמה לאחזור שם האפליקציה. כתובת ה-URL שדווחה היא: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 פענוח הערך הזה: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 תוצאה: 
air.com.hypah.io.slither
 התוצאה שווה לאפליקציה ל-Android‏ slither.io.

שדות של Open Bidding

בקשות להצעות מחיר שנשלחות למגישי הצעות מחיר בבורסות ובמערכות פרסום שמשתתפים ב-Open Bidding דומות לבקשות שנשלחות ל-Authorized Buyers שמשתתפים בבידינג בזמן אמת רגיל. לקוחות Open Bidding יקבלו מספר קטן של שדות נוספים, ויכול להיות שחלק מהשדות הקיימים ישמשו למטרות אחרות. למשל:

OpenRTB פרטים
BidRequest.imp.ext.dfp_ad_unit_code

מכיל את קוד הרשת של רשת Ad Manager, ואחריו את ההיררכיה של יחידות המודעות, כשהם מופרדים בלוכסנים.

לדוגמה, הפורמט של הכתובת ייראה כך: /1234/cruises/mars.
BidRequest.user.data.segment

צמדים חוזרים של מפתח/ערך שנשלחים מבעל האפליקציה למגיש הצעת המחיר ב-Exchange.

אפשר לקבוע שהערכים הם צמדי מפתח/ערך שנשלחים על ידי בעל האפליקציה כשהערך של BidRequest.user.data.name מוגדר כ-“Publisher Passed”.

הצהרה על ספקים מורשים

ספקי טכנולוגיה שמספקים שירותים כמו מחקר, רימרקטינג והצגת מודעות עשויים למלא תפקיד באינטראקציה בין קונים למוכרים. מותרים רק ספקים ש-Google בדקה את ההתאמה שלהם להשתתפות באינטראקציות של Authorized Buyers.

כדי להבין את BidRequest וליצור את BidResponse, חשוב להכיר את שתי האפשרויות השונות להצהרה על ספקי טכנולוגיה:

  1. יש ספקים שלא צריך להצהיר עליהם. הספקים האלה מפורטים בספקים חיצוניים מוסמכים ל-Ad Manager.
  2. ספקים אחרים יכולים להשתתף רק אם הם מוצהרים בתג BidRequest:
    • בשדה BidRequest.imp.ext.allowed_vendor_type בקובץ BidRequest מצוין אילו ספקים מורשים על ידי אתר המכירה. הספקים שיישלחו ב-allowed_vendor_type מפורטים בקובץ המילון vendors.txt.

דוגמה לבקשה להצעת מחיר

בדוגמאות הבאות מוצגות בקשות בפורמט Protobuf ובפורמט JSON, שקל לקרוא אותן.

OpenRTB Protobuf

OpenRTB JSON

כדי להמיר את בקשת הצעת המחיר לצורה בינארית, כמו זו שתקבלו מהמטען הייעודי (payload) של POST בבקשה אמיתית, אתם יכולים לבצע את הפעולות הבאות (ב-C++‎). עם זאת, שימו לב שזה לא רלוונטי ל-OpenRTB JSON.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

משוב בזמן אמת

המשוב בזמן אמת זמין ל-Authorized Buyers, וגם לבורסות ולרשתות שמשתמשות ב-Open Bidding.

המשוב בזמן אמת מאכלס את BidRequest.ext.bid_feedback על סמך התוצאה של הצעת מחיר אחת או יותר שהגשתם קודם, ואפשר להשתמש בו כדי למצוא פרטים כמו אם הצעת המחיר זכתה במכרז, או הצעת המחיר המינימלית שנדרשת כדי לזכות במכרז. כדי להפעיל את המשוב בזמן אמת, פנו למנהל החשבון.

בנוסף לשדות ברירת המחדל שנשלחים במשוב על תגובות לבקשות להצעת מחיר, אפשר לשלוח גם נתונים מותאמים אישית בתגובה לבקשה להצעת מחיר באמצעות השדה BidResponse.seatbid.bid.ext.event_notification_token. הערך event_notification_token הוא נתונים שרירותיים שמוכרים רק למגיש ההצעה, שיכולים לעזור בניפוי באגים. לדוגמה: מזהה טירגוט חדש או מזהה הגשת הצעת מחיר שמייצג טקטיקה חדשה, או מטא-נתונים שמשויכים לנכס הקריאייטיב ומוכרים רק למגיש ההצעה. פרטים נוספים זמינים בקובץ מאגר האחסון לפרוטוקולים של תוספי OpenRTB.

כשמערכת Authorized Buyers שולחת בקשה להצעת מחיר למגיש הצעות מחיר, הוא משיב עם BidResponse. אם למגיש הצעת המחיר מופעל משוב בזמן אמת, אז בבקשה הבאה להצעת מחיר, Authorized Buyers שולח משוב על התגובה בהודעה BidFeedback:

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in your account
  // currency. If your bid won the auction, this is the second highest bid
  // that was not filtered (including the floor price). If your bid didn't win
  // the auction, this is the winning candidate's bid. This field will only be
  // populated if your bid participated in a first-price auction, and will not
  // be populated if your bid was filtered prior to the auction.
  optional double minimum_bid_to_win = 6;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 13 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;
}

השדה הראשון שצריך לבדוק בהודעה הזו הוא bid_feedback.creative_status_code. אפשר למצוא את משמעות הקוד בקובץ creative-status-codes.txt. שימו לב שאם הצעת המחיר שלכם תזכה, תוכלו לבטל את ההסכמה לקבלת משוב על המחיר. איך מבטלים את ההסכמה?

המשוב בזמן אמת כולל את מזהה הבקשה להצעת מחיר ואחד מהבאים:

תוצאת המכרז משוב בזמן אמת
הקונה לא הגיש הצעת מחיר. שום דבר.
הקונה הגיש הצעת מחיר שסוננה לפני שהגיעה למכרז. קוד הסטטוס של הקריאייטיב (creative-status-codes.txt).
הקונה הגיש הצעת מחיר אבל הפסיד במכרז. קוד סטטוס הקריאייטיב 79 (הצעת מחיר נמוכה יותר במכרז).
הקונה שלח הצעת מחיר שזכתה במכרז. מחיר הסגירה וקוד הסטטוס של הקריאייטיב 1.

אם מדובר בחשיפה של אפליקציה וקוד הסטטוס של הקריאייטיב הוא 83, יכול להיות שבעל האפליקציה השתמש ברשימת רשתות בתהליך בחירת רשת, ולכן הצעת המחיר הזוכה התחרתה בביקוש אחר בשרשרת של רשימת הרשתות בתהליך בחירת הרשת של בעל האפליקציה. איך משתמשים ב-sampled_mediation_cpm_ahead_of_auction_winner בבידינג

דוגמה

לפניכם דוגמה למשוב בזמן אמת כפי שהוא מוצג בפרוטוקולים נתמכים:

OpenRTB Protobuf

OpenRTB JSON

בניית מודל בידינג למכרזי מחיר ראשון

אחרי שמגישים הצעת מחיר במכרז מחיר ראשון, מקבלים משוב בזמן אמת שכולל את השדות minimum_bid_to_win ו-sampled_mediation_cpm_ahead_of_auction_winner אם הצעת המחיר לא סוננה מהמכרז. האותות האלה יכולים לעזור לכם להבין עד כמה הצעת המחיר שלכם הייתה יכולה להיות גבוהה או נמוכה יותר כדי לזכות בחשיפה.

  • minimum_bid_to_win: הצעת המחיר המינימלית שהיה אפשר להגיש כדי לזכות במכרז של הבידינג בזמן אמת. אם זכיתם במכרז, זו תהיה הצעת המחיר הנמוכה ביותר שיכולתם להגיש ועדיין לזכות. אם הפסדתם במכרז, זה יהיה המחיר של הצעת המחיר הזוכה.
  • ‫sampled_mediation_cpm_ahead_of_auction_winner: אם יש רשתות אחרות בשרשרת לבחירת רשת, הערך של השדה הזה הוא מחיר שמייצג הצעת מחיר לדוגמה מאחת מהרשתות הכשירות לבחירת רשת שהיו גבוהות יותר מהזוכה במכרז, משוקלל לפי שיעור המילוי הצפוי. הערך הזה יהיה 0 אם לא צפוי שאף אחת מהרשתות בשרשרת לבחירת רשת תמלא את הבקשה, או אם בעל האפליקציה לא משתמש ב-SDK לבחירת רשת.

איך זה עובד

כדי לתאר את החישובים שמשמשים לקביעת הערכים האפשריים של minimum_bid_to_win ושל sampled_mediation_cpm_ahead_of_auction_winner, צריך קודם להגדיר את המשתנים הבאים:

  • הנתונים הבאים מייצגים את העלויות לאלף חשיפות בשרשרת לבחירת רשת בסדר יורד:
    \[C_1, C_2, …, C_n\]
  • אלה שיעורי המילוי שתואמים לעלויות לאלף חשיפות בשרשרת לבחירת רשת:
    \[f_1, f_2, …, f_n\]
  • הפונקציה הבאה משמשת לקביעת ה-CPM הצפוי וההסתברות שלו מרכיב \(i\)בשרשרת לבחירת רשת, על סמך שיעור המילוי הנתון:
    ‫\(X_i = \{C_i\) עם הסתברות \(f_i\); \(0\) עם הסתברות \(1 - f_i\}\)
  • השרשרת הזוכה הסופית לבחירת רשת תהיה:
    \[\{C_1, C_2, …, C_K, W\}\]
    כאשר \(W\) היא הצעת המחיר הזוכה, ו \(C_K > W >= C_{K+1}\)
  • המחיר המינימלי מסומן כ- \(F\).
  • ההצעה השנייה בגובהה מסומנת בסימן \(R\).
חישובים של הזוכה במכרז
שדה החישוב
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) עם הסתברות \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
עבור \(1 <= i <= K\).
חישובים למפסיד במכרז
שדה החישוב
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

דוגמה עם שרשרת בחירת רשת פשוטה

נניח שבעל תוכן דיגיטלי משתמש גם בבידינג בזמן אמת וגם בשרשרת בחירת רשת (Mediation) מבוססת SDK באופן הבא:

שרשרת לבחירת רשת (Mediation) ב-SDK עלות צפויה לאלף חשיפות (eCPM) קצב מילוי
רשת 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
רשת 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
רשת 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
רשת 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

נניח שאלה התוצאות של מכרז ה-RTB:

מכרז RTB עלות לאלף חשיפות (CPM)
הזוכה במכרז (W) 4 ש"ח
ההצעה השנייה בגובהה במכרז (R) $‎0.05
מחיר מינימום (F) 0$
הצעת המחיר שזכתה במכרז

בדוגמה הבאה מוסבר איך הערכים וההסתברויות של minimum_bid_to_win ו-sampled_mediation_cpm_ahead_of_auction_winner מחושבים להצעת מחיר שזכתה.

minimum_bid_to_win Probability
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probability
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
הצעות מחיר שהפסידו במכרז

בדוגמה הבאה אפשר לראות איך מחושבים הערכים וההסתברויות של minimum_bid_to_win ושל sampled_mediation_cpm_ahead_of_auction_winner עבור הצעות מחיר שלא זכו.

minimum_bid_to_win Probability
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probability
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

פיצול הצעת מחיר

המונח 'פיצול הצעת מחיר' מתאר את העיבוד של BidRequest מורכבת אחת לכמה בקשות להצעות מחיר שנשלחות לאפליקציה שלכם. כשבקשה להצעת מחיר משוטחת, אפשר לדעת אילו בקשות להצעת מחיר היו חלק מהבקשה המקורית כי יהיה להן ערך זהה בשדה BidRequest.ext.google_query_id.

התכונה "פיצול הצעת מחיר" מופעלת כברירת מחדל, אבל אתם יכולים לפנות למנהל החשבון שלכם אם אתם מעדיפים להשבית אותה.

פורמטים של מודעות

בחלק מההזדמנויות להצגת מודעות אפשר להשתמש בכמה פורמטים. כשמשתמשים בפיצול הצעת מחיר, כל פורמט נשלח בבקשה נפרדת להצעת מחיר, שבה מאפיינים כמו מספרי לקוח לחיוב כשירים רלוונטיים לפורמט שצוין בבקשה.

בקשות להצעות מחיר שכוללות את הפורמטים הבאים יפוצלו לבקשות נפרדות:

  • מודעת באנר
  • וידאו
  • אודיו
  • מותאמת

דוגמה להשטחה של פורמט מודעה

בדוגמה הבאה מוצגת בקשה פשוטה להצעת מחיר בפורמט JSON של OpenRTB ללא שיטוח של פורמט המודעה, בהשוואה לקבוצה מקבילה של בקשות שטוחות:

השטחה מראש

אחרי השטחה

מבצעים

הזדמנות להצגת מודעה למגיש הצעת מחיר מסוים יכולה להיות רלוונטית לסוגים שונים של עסקאות, בנוסף למכרז הפתוח. כשמפעילים פיצול הצעות מחיר לעסקאות, נשלחת בקשה אחת להצעת מחיר למכרז הפתוח, ובקשה אחת לכל סוג של עסקה במחיר קבוע. בפועל, ההגבלות על המודעות יכולות להיות שונות בין מכרזים לבין סוגי עסקאות במחיר קבוע. לדוגמה, בהזדמנות נתונה להצגת מודעת וידאו שזמינה גם למכרז הפתוח וגם לעסקה במחיר קבוע, מגיש הצעת המחיר יקבל בקשות נפרדות להצעות מחיר לכל אחת מהן, וההגבלות כמו משך המודעה המקסימלי והאפשרות להציג מודעות שניתן לדלג עליהן יכולות להיות שונות. כתוצאה מכך, ההשטחה שחלה על הזדמנות להצגת מודעה מאפשרת לכם להבחין בקלות רבה יותר באילוצים של המודעה במכרז הפתוח ובעסקה במחיר קבוע.

אפשרות דילוג ומשך נכס הווידאו

במפרט של OpenRTB אין שדות נפרדים לציון משך נכס הווידאו המקסימלי של מודעות וידאו שניתן לדלג עליהן ומודעות וידאו שלא ניתן לדלג עליהן. ההטמעה של Google משתמשת בפיצול הצעת מחיר כדי להבחין בין השדות הקיימים BidRequest.video.maxduration ו-BidRequest.video.skip.

הדוגמה הבאה ממחישה איך מלאי שטחי הפרסום למודעות וידאו עובר שיטוח כשהאורך המקסימלי של מודעה שלא ניתן לדלג עליה הוא 15 והאורך המקסימלי של מודעה שניתן לדלג עליה הוא 60.

דוגמה max_ad_duration skip (true OR false)
הבקשה המקורית ללא שיטוח 15 true
בקשה שטוחה מס' 1: מודעה שלא ניתן לדלג עליה 15 false
בקשה שטוחה מס' 2: ניתנת לדילוג 60 true

ההשטחה של בקשות להצעות מחיר לפי משך נכס הווידאו שניתן לדלג עליו תתבצע רק אם התנאים הבאים יתקיימו:

  • הבקשה מאפשרת וידאו.
  • אפשר להשתמש גם בסרטונים שניתן לדלג עליהם וגם בסרטונים שלא ניתן לדלג עליהם, והערכים של משך הזמן המקסימלי של שני הסוגים שונים.
  • הבקשה הזו עומדת בדרישות להשתתפות במכרז פרטי או במכרז פתוח.

כדי לבטל את ההצטרפות לסוג הזה של שיטוח, פנו למנהל החשבונות הטכני שלכם. כשההגדרה מושבתת, ובעל האפליקציה מאפשר גם מודעות וידאו שניתן לדלג עליהן וגם מודעות וידאו שלא ניתן לדלג עליהן, עם משכי זמן מקסימליים שונים בהתאם לאפשרות הדילוג, הערך של skip יוגדר כ-true והערך של maxduration יוגדר כמשך הזמן הקצר יותר מבין המגבלות של מודעות שניתן לדלג עליהן ומודעות שלא ניתן לדלג עליהן.

בלוקים של מודעות וידאו

בקשות להצעות מחיר לרצף מודעות וידאו עם כמה הזדמנויות להצגת מודעות עוברות תהליך של שיטוח, כך שכל בקשה להצעת מחיר מיועדת להזדמנות ספציפית להצגת מודעה מתוך הרצף הזה. כך תוכלו להגיש הצעות מחיר על כמה הזדמנויות להצגת מודעות ברצף מודעות נתון.

Open Measurement

התכונה Open Measurement מאפשרת לכם לציין ספקים חיצוניים שמספקים שירותי מדידה ואימות עצמאיים למודעות שמוצגות בסביבות של אפליקציות לנייד.

כדי לקבוע אם בעל תוכן דיגיטלי תומך ב-Open Measurement בבקשה להצעת מחיר, אתם יכולים לבדוק אם ההזדמנות להצגת מודעה מחריגה את המאפיין OmsdkType: OMSDK 1.0 שנמצא במאפייני קריאייטיב שבעלי תוכן דיגיטלי יכולים להחריג. הערך הזה מופיע במאפיין battr של באנר או סרטון, בהתאם לפורמט.

מידע נוסף על האופן שבו אפשר לפרש בקשות להצעות מחיר שמכילות אותות של Open Measurement זמין במאמר במרכז העזרה בנושא Open Measurement SDK.

דוגמאות לבקשות להצעות מחיר

בקטעים הבאים מוצגות בקשות לדוגמה להצעות מחיר לסוגי מודעות שונים.

באנר של האפליקציה

OpenRTB Protobuf

‫JSON של OpenRTB

מודעת מעברון באפליקציה

OpenRTB Protobuf

OpenRTB JSON

מודעת וידאו מעברון באפליקציה

OpenRTB Protobuf

‫JSON של OpenRTB

מודעה מותאמת באפליקציה

OpenRTB Protobuf

OpenRTB JSON

סרטונים באינטרנט

OpenRTB Protobuf

‫JSON של OpenRTB

מודעת באנר לאינטרנט לנייד למגיש הצעת מחיר בבורסת מודעות

OpenRTB Protobuf

‫JSON של OpenRTB

מודעות וידאו ומודעות מותאמות במגוון פורמטים

OpenRTB Protobuf

‫JSON של OpenRTB