עיבוד הבקשה

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

ניתוח בקשת Protobuf

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

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

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

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

אפשר לקבוע שהערכים הם צמדי מפתח/ערך שנשלחים על ידי בעל אפליקציה כאשר 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

קובץ JSON של OpenRTB

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 או פרוטוקול Google RTB.

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

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

  // The minimum bid value necessary to have 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 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 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

קובץ JSON של OpenRTB

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

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

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

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

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

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

OpenRTB Protobuf

קובץ JSON של OpenRTB

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

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

OpenRTB Protobuf

קובץ JSON של OpenRTB

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

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

OpenRTB Protobuf

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

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

OpenRTB Protobuf

קובץ JSON של OpenRTB

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

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

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

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

OpenRTB Protobuf