עיבוד הבקשה

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

בקשת ניתוח

‫Google שולחת בקשה להצעת מחיר שעברה סריאליזציה בפורמט OpenRTB JSON או Protobuf, שמצורפת כמטען ייעודי (payload) של בקשת 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.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

איך קובעים קטגוריות חסומות

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

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

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

טקסונומיית התוכן של IAB בגרסה 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

קבצים של מילון

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

פקודות מאקרו של כתובות URL של משתתפי מכרז

אפשר להשתמש בפקודות מאקרו כדי להוסיף לכתובות ה-URL של נקודות הקצה לבידינג מידע מסוים מBidRequest. אם מגדירים כתובת 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

משתמשים במפענח base-32 כדי לפענח את החלק המודגש במחרוזת (gewtimrzgyytanjyg4888888).

אפשר להשתמש במפענח באינטרנט, אבל תצטרכו להשתמש באותיות רישיות ולהחליף את הערכים 8 בסוף בערכים =.

לכן, פענוח הערך הזה: 

GEWTIMRZGYYTANJYG4======
 תוצאות:
‫
1-429610587
 המחרוזת 429610587 היא מזהה האפליקציה iFunny ל-iOS.

דוגמה נוספת: כתובת ה-URL שדווחה היא:

‫
mbappgewtgmjug4ytmmrtgm888888.com
 פענוח הערך הזה: 
GEWTGMJUG4YTMMRTGM======
 תוצאות: 
1-314716233
 התוצאה 314716233 היא מזהה האפליקציה של אפליקציית iOS‏ TextNow.

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

הנה דוגמה לאחזור שם האפליקציה. כתובת ה-URL שדווחה היא:

‫
mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 פענוח הערך הזה: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 תוצאות: 
air.com.hypah.io.slither
 התוצאה שווה לאפליקציית Android‏ slither.io.

שדות Open Bidding

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

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

‫JSON של OpenRTB

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];
}

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

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

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

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

דוגמה

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

OpenRTB Protobuf

‫JSON של OpenRTB

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

אחרי שמגישים הצעת מחיר במכרז במודל 'מחיר ראשון', מקבלים משוב בזמן אמת, כולל השדות 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\]
  • הנתונים הבאים מייצגים את שיעורי מילוי הבקשות התואמים לעלויות לאלף חשיפות בשרשרת של תהליך בחירת הרשת (Mediation):
    \[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\}\)

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

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

בלוקים של מודעות וידאו

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

מדידה פתוחה

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

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

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

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

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

באנר לקידום אפליקציה

OpenRTB Protobuf

‫JSON של OpenRTB

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

OpenRTB Protobuf

‫JSON של OpenRTB

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

OpenRTB Protobuf

‫JSON של OpenRTB

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

OpenRTB Protobuf

‫JSON של OpenRTB

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

OpenRTB Protobuf

‫JSON של OpenRTB

מודעת באנר באתרים לנייד עבור משתתף במכרז בבורסת פרסום

OpenRTB Protobuf

‫JSON של OpenRTB

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

OpenRTB Protobuf

‫JSON של OpenRTB