עיבוד הבקשה

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

ניתוח הבקשה

Google שולחת בקשה להצעת מחיר בתור מאגר נתונים זמני של פרוטוקול בסדרה, שמצורף כמטען ייעודי (payload) הבינארי של בקשת HTTP POST. הערך של Content-Type מוגדר ל-application/octet-stream. כדי לראות דוגמה, אפשר לעיין בקטע בקשה להצעת מחיר לדוגמה.

צריך לנתח את הבקשה במופע של ההודעה BidRequest. BidRequest מוגדר ב-realtime-bidding.proto, שניתן להשיג בדף נתוני הפניה. אפשר לנתח את ההודעה באמצעות השיטה ParseFromString() במחלקה שנוצרה עבור 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++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

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

מידע על קבוצת המודעות של הטירגוט מראש זמין בקבוצה MatchingAdData לכל AdSlot. הוא מכיל את המזהה של קבוצת המודעות התואמת הראשונה של קבוצת המודעות שמטורגטת מראש, וגרם ל-Google לשלוח את הבקשה להצעת מחיר. כלומר, קבוצת המודעות והקמפיין שמחויבים אם התגובה שלכם זוכה במכרז על החשיפה. בנסיבות מסוימות צריך לציין במפורש את השדה billing_id לשיוך ב-BidResponse.AdSlot, למשל, אם ל-BidRequest.AdSlot יש יותר מmatching_ad_data אחד. למידע נוסף על המגבלות על התוכן של הצעת המחיר, קראו את realtime-bidding.proto.

קובצי מילון

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

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

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

Macroתיאור
%%GOOGLE_USER_ID%%

יוחלף ב-google_user_id מתוך BidRequest. לדוגמה, כתובת ה-URL של מגיש הצעות המחיר 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
תוחלף בערך כמו 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
בזמן הבקשה.

אם ה-Google User ID לא ידוע, המחרוזת הריקה תוחלף והתוצאה תהיה דומה

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

הוחלף ב-1 או ב-0 כשמתקשרים ל-has_mobile() של BidRequest.
%%HAS_VIDEO%%

מוחלפת ב-1 (true) או ב-0 (false) כשקוראים ל-has_video() של BidRequest.
%%HOSTED_MATCH_DATA%%

יוחלף בערך של השדה hosted_match_data מה-BidRequest.
%%MOBILE_IS_APP%%

הוחלף ב-1 (true) או ב-0 (false) מהשדה mobile.is_app של BidRequest.

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

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

mbappgewtimrzgyytanjyg4888888.com

צריך להשתמש במפענח לפי בסיס 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

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

OpenRTB Authorized buyers פרטים
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

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

לדוגמה, העיצוב אמור להיראות כך: /1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

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

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

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

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

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

  1. אין צורך להצהיר על ספקים מסוימים. הספקים האלה מפורטים בעזרה של Authorized Buyers.
  2. ספקים אחרים יוכלו להשתתף רק אם הצהרתם עליהם גם ב-BidRequest וגם ב-BidResponse:
    • בשדה BidRequest, השדה allowed_vendor_type מציין אילו ספקים מורשים אתר המכירה. הספקים שיישלחו בשדה allowed_vendor_type של BidRequest יופיעו בקובץ המילון Vendors.txt.
    • בשדה BidResponse, השדה vendor_type מציין באילו מהספקים המורשים שהקונה מתכוון להשתמש בהם.

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

בדוגמאות הבאות מוצגות דגימות קריאות לאנשים של בקשות Protobuf ו-JSON.

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

על מנת להמיר את הבקשה להצעת מחיר לטופס בינארי, כמו שהייתם מקבלים מהמטען הייעודי (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 מעביר מזהה פרסום בנייד בבקשות להצעות מחיר מאפליקציה לנייד. מזהה הפרסום בנייד יכול להיות IDFA של iOS או מזהה הפרסום של Android, שנשלח באמצעות פקודת המאקרו %%EXTRA_TAG_DATA%% בתג JavaScript שמנוהל על ידי Authorized Buyers.

המאקרו %%ADVERTISING_IDENTIFIER%% מאפשר לקונים לקבל IDFA של iOS או את מזהה הפרסום של Android בעיבוד החשיפה. הוא מחזיר מאגר נתונים זמני של פרוטוגרפיה מוצפן MobileAdvertisingId כמו %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

השדה user_id_type הוא אחד מהערכים שמוגדרים ב-enum AdxMobileIdType:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

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

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

משוב בזמן אמת

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

תהיה תמיכה במשוב על תגובות להצעת מחיר בתגובה לבקשה הבאה להצעת מחיר, גם לפרוטוקול AdX וגם ל-OpenRTB. ב-OpenRTB, הוא נשלח ב-BidRequestExt.

בנוסף לשדות ברירת המחדל שנשלחים במשוב לתשובה על הצעת מחיר, ניתן גם לשלוח נתונים מותאמים אישית בתגובה להצעת המחיר (ב-AdX Proto או ב-OpenRTB) באמצעות event_notification_token שמוחזר בBidResponse. event_notification_token הם נתונים שרירותיים שידועים רק למגיש הצעות המחיר שיכולים לעזור בניפוי באגים. לדוגמה: מזהה טירגוט או מזהה בידינג חדשים שמייצגים טקטיקה חדשה, או מטא-נתונים המשויכים לקריאייטיב שידוע רק למגיש הצעות המחיר. לפרטים, קראו את המאמר מאגר פרוטוקול תוספים OpenRTB עבור RTB ו-AdX Proto עבור AdX.

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

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

  // 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 = 3;

  // 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 int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // 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 did not 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 int64 minimum_bid_to_win = 7;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM micros of the buyer account currency.
  // The minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // 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 = 15 [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 micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidResponseFeedback message. Google will send separate
  // BidResponseFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedback_type = 17;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyer_origin = 18;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 interest_group_buyer_status_code = 19;
}

בהודעה הזו, השדה הראשון שצריך לבדוק הוא bid_response_feedback.creative_status_code; המשמעות של הקוד היא creative-status-codes.txt. שימו לב שאם זכיתם בהצעת המחיר, תוכלו לבטל את ההסכמה במשוב על המחיר. למידע נוסף, ראו כיצד לבטל את ההסכמה.

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

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

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

דוגמה

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

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

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

איך זה עובד

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

  • הערכים הבאים מייצגים את העלויות לאלף חשיפות בשרשרת של תהליך בחירת הרשת בסדר יורד:
    \[C_1, C_2, …, C_n\]
  • הערכים הבאים מייצגים את קצבי המילוי התואמים לעלויות לאלף חשיפות בשרשרת לבחירת הרשת:
    \[f_1, f_2, …, f_n\]
  • הפונקציה משמשת לקביעת העלות הצפויה לאלף חשיפות וההסתברות שלה מרכיב של שרשרת תהליך בחירת הרשת \(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\}\)

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

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

שרשרת לבחירת רשת (Mediation) ב-SDK עלות צפויה לאלף חשיפות קצב מילוי
רשת 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.google_query_id בפרוטוקול RTB של Authorized Buyers או BidRequestExt.google_query_id בפרוטוקול OpenRTB), אפשר לקבוע אילו בקשות להצעות מחיר יש קורלציה לאחר השטוח.

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

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

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

  • כרזה
  • וידאו
  • אודיו
  • מותאם

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

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

שטוחה מראש

פוסט שטוח

מבצעים

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

משך מקסימלי של סרטון שניתן לדלג עליו

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

משך הקורס משך זמן שניתן לדלג עליו דילוג
פרוטוקול Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration לא רלוונטי skip

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

לפני פיצול הצעת המחיר, הערך maxduration של OpenRTB היה מוגדר לערך הנמוך מבין השדות max_ad_duration ו-skippable_max_ad_duration של פרוטוקול Google. אופן הפעולה הזה השתנה ל שליחה של שתי בקשות נפרדות להצעת מחיר כשהערכים האלה שונים: האחת מייצגת את maxduration עבור מודעות שניתן לדלג עליהן והשנייה עבור הזדמנויות שלא ניתן לדלג עליהן.

הדוגמאות הבאות מראות איך בקשה בפרוטוקול Google מתורגמת ל-OpenRTB לפני ואחרי פיצול הצעת המחיר. בבקשה המקבילה לפרוטוקול Google יש max_ad_duration של 15 ו-skippable_max_ad_duration של 60.

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

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

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

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

רצף סרטונים

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

פתיחת המדידה

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

כדי לקבוע אם בעל האפליקציה תומך ב'מדידה פתוחה' בבקשת הצעת המחיר, אפשר לבדוק אם ההזדמנות להצגת מודעה מחריגה את המאפיין OmsdkType: OMSDK 1.0 שנמצא במאפייני הקריאייטיב שאינם ניתנים להחרגה של בעל התוכן הדיגיטלי. לגבי פרוטוקול Authorized Buyers, המדיניות הזו נמצאת במסגרת BidRequest.adslot[].excluded_attribute. עבור פרוטוקול OpenRTB, המאפיין נמצא במאפיין battr של באנר או וידאו, בהתאם לפורמט.

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

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

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

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

סרטון מעברון של אפליקציה

Google

OpenRTB Protobuf

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

Google

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

OpenRTB Protobuf