עיבוד הבקשה

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

ניתוח בקשת Protobuf

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

צריך לנתח את הבקשה הזו למופע של ההודעה BidRequest. בהתאם לפרוטוקול שבחרתם, השדה BidRequest מוגדר ב-openrtb.proto או ב-realtime-bidding.proto שהוצא משימוש, ואפשר לקבל אותו מהדף נתוני עזר. אפשר לנתח את ההודעה באמצעות השיטה ParseFromString() בכיתה שנוצרה עבור BidRequest. לדוגמה, הקוד הבא ב-C++ מנתח בקשה שמקבלת עומס נתונים של 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 של הצעת מחיר בפרוטוקול RTB של Google

אפשר גם להוסיף חלק מהשדות של 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

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

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

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

אפשר לקבל משוב על תגובות לבידינג בבקשת הבידינג הבאה גם ב-OpenRTB וגם בפרוטוקול Google RTB שהוצא משימוש. ב-OpenRTB, הוא נשלח ב-BidRequest.ext.bid_feedback.

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

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

Google (הוצא משימוש)

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

אחרי שליחת הצעת מחיר במכרז במודל 'מחיר ראשון', תקבלו משוב בזמן אמת, כולל השדות 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 ללא שטחת פורמט מודעה, בהשוואה לקבוצה מקבילה של בקשות שטוחות:

יישור מראש

לאחר יישור

מבצעים

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

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

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

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

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

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

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

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

רצפי סרטונים

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

Open Measurement

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

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

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

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

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

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

Google (הוצא משימוש)