עיבוד הבקשה

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

ניתוח הבקשה

Google שולחת בקשת הצעת מחיר בסריאליזציה בפורמטים של OpenRTB JSON או Protobuf, שמצורפת כמטען הייעודי של בקשת HTTP 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++‎, איטרציה על עסקאות ב-`BidRequest` של OpenRTB עשויה להיראות כך:

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.

קובצי מילון

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

מאקרו של כתובת 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 מאוכלס בבקשת הצעת המחיר.
%%HOSTED_MATCH_DATA%%

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

%%MOBILE_IS_APP%%

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

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

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

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

לדוגמה, הפורמט של השדה הזה יהיה דומה לזה: /1234/cruises/mars.
BidRequest.user.data.segment

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

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

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

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

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

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

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

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

OpenRTB Protobuf

OpenRTB JSON

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

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 Extensions Protocol Buffer.

כשמערכת 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;

  // 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 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 BidFeedback object.
  optional double sscminbidtowin = 14;

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

  // 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 BidFeedback message. Google will send separate
  // BidFeedback 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 feedbacktype = 15;

  // 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 buyerorigin = 16;

  // 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 igbuyerstatus = 17;
}

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

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

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

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

  • העלות לאלף חשיפות בשרשרת תהליך בחירת הרשת (Mediation) מוצגת בהמשך בסדר יורד:
    \[C_1, C_2, …, C_n\]
  • בטבלה הבאה מוצגים שיעורי המילוי התואמים של העלות לאלף חשיפות בשרשרת בחירת הרשת:
    \[f_1, f_2, …, f_n\]
  • זוהי פונקציה שמשמשת לקביעת העלות הצפויה לאלף חשיפות והסבירות שלה מרכיב שרשרת בחירת הרשת \(i\), על סמך שיעור המילוי שצוין:
    \(X_i = \{C_i\) with probability \(f_i\); \(0\) with probability \(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 באופן הבא:

שרשרת לבחירת רשת ב-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.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

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON