עיבוד הבקשה

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

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 של מגישי הצעות מחיר

אופציונלי: אפשר להשתמש בפקודות מאקרו כדי להוסיף חלק מהמידע מ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 מאוכלס בבקשה להצעת מחיר.
%%IS_CTV%%

הערך מוחלף ב-1 כדי לציין שהבקשה להצעת מחיר מגיעה ממכשיר CTV, או ב-0 אם לא. החישוב מבוסס על הערך של BidRequest.device.devicetype. ב-Protobuf, מכשירי CTV הם CONNECTED_TV,‏ CONNECTED_DEVICE או SET_TOP_BOX, שמתאימים לערכים שלמים 3,‏ 6 או 7 ב-JSON.
%%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 בבידינג רגיל בזמן אמת. לקוחות שמשתמשים ב-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

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

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

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

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

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

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

  • הנתונים הבאים מייצגים את ה-CPM בשרשרת לבחירת רשת בסדר יורד:
    \[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 באופן הבא:

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