עיבוד הבקשה

אינטראקציה של בידינג בזמן אמת מתחילה כש-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 מזהה, שפה או מיקום גיאוגרפי לא תמיד זמינים. אם יש לך קבוצות מודעות שמטורגטות מראש שנעשה בהן שימוש במידע שאינו ידוע לגבי קבוצת מודעות מסוימת החשיפה, קבוצות המודעות האלה לא יתאימו. במקרים שבהם חסרה המידע אינו משנה עבור התנאים למיקוד מראש, בקשות להצעות מחיר נשלח כשהמידע הושמט.

מידע על קבוצת מודעות שמטרגטת מראש זמין קבוצה אחת (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 לא ידוע, המחרוזת הריקה תוחלף בתו תוצאה דומה ל-

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

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

בקשות להצעות מחיר שנשלחו למגישי הצעות מחיר ב-Exchange וברשתות שמשתתפים בתוכנית Open הבידינג דומה לשיטות הבידינג של 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[]

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

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

המאקרו %%ADVERTISING_IDENTIFIER%% מאפשר לקונים לקבל IDFA ב-iOS או מזהה הפרסום של Android בזמן רינדור החשיפה. הוא מחזיר מאגר נתונים מוצפן של Proto 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, הפרמטר יכול להיות שבעלי האפליקציה השתמשו ברשימת רשתות בתהליך בחירת רשת, ולכן היא הייתה מתחרה מול ביקוש אחר שרשרת מפל נשכחת. איך משתמשים 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 אם אף אחת מהרשתות שרשרת לבחירת רשת צפויה להתמלא, או אם בעל האפליקציה לא משתמש ב-SDK בתהליך בחירת הרשת.

איך זה עובד

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

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

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

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

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

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

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

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

שטוחה מראש

שטוחה

מבצעים

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

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

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

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

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

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

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

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

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

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

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

רצף סרטונים

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

פתיחת המדידה

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

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

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

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

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

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

Google

OpenRTB Protobuf

מותאמת של אפליקציה

Google

קובץ JSON של OpenRTB

OpenRTB Protobuf

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

Google

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

OpenRTB Protobuf