הגדרת שילוב של Open Bidding

Open Bidding מאפשר לבורסות ולקונים אחרים להשתמש בתשתית הבידינג בזמן אמת של Google כדי להגיש הצעות מחיר על מלאי שטחי הפרסום של Google Ad Manager ושל AdMob.

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

הגבלת השילוב למוציאים לאור נבחרים

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

פרוטוקולים וקידודים נתמכים

אפשר להשתמש ב-OpenRTB בפורמט JSON או בפורמט Protobuf. מידע נוסף

הטמעה של Google OpenRTB

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

טיפול בבקשות נכנסות להצעות מחיר

ב-Open Bidding נעשה שימוש באותו מבנה BidRequest כמו בתוכנית 'קונים מורשים', אבל חלק מהשדות נשלחים רק למשתתפים ב-Open Bidding. במדריך לבקשות תוכלו לקרוא מידע נוסף על שדות ספציפיים ל-Open Bidding שנשלחים בבקשת הצעת המחיר.

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

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

הערה: בקשות להצעות מחיר שנשלחות למשתתפים ב-Open Bidding אמורות לקבל תשובה תוך 300 עד 1,000 אלפיות השנייה, בהתאם לפורמט של מלאי שטחי הפרסום. כדי לבדוק מהן הדרישות הספציפיות לבקשה מסוימת, בודקים את השדה BidRequest.tmax.

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

• מודעות מעברון
• מודעות וידאו
• מודעות וידאו ב-OpenRTB
• מודעות מותאמות
• מודעות וידאו מותאמות
• מודעות של SDK של קונה

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

מומלץ מאוד להשתמש בשדה האופציונלי BidResponse.seatbid.bid.ext.impression_tracking_url כדי לאחזר נתונים ברמת החשיפות לגבי הזמנים שבהם Google מתעדת אירועים לחיוב שעבורם תחויבו.

פתרון סתירות בביקוש ב-Google (בטא)

המטרה של התכונה הזו היא לוודא שמספר החשיפות שעבורן מתבצע חיוב על המרות תואם למספר החשיפות שעבורן Google Display & Video 360 (DV360) משלמת.

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

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

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

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

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

העברת ה-markup של נכסי הקריאייטיב של Google כפי שהוא בתגובות לבקשות להצעת מחיר

כדי לוודא שהפתרון של אי ההתאמה חל על הצעות מחיר מתוך הביקוש של Google, פלטפורמת ה-Exchange צריכה להפיץ את ה-markup של נכסי הקריאייטיב של Google ללא עטיפות (תגי סקריפט, iframe או עטיפות VAST). כתוצאה מהפתרון של אי ההתאמה, Google עשויה לבטל את החשיפות במכרזים פתוחים שלא נספרות על ידי פלטפורמות הביקוש של Google, ולא לשלוח עליהן חשבונית. Google תבדוק מדי פעם את ה-markup של הקריאייטיב כדי לוודא שהצעות המחיר עם הערך third_party_buyer_token נשלחו בשם הביקוש של Google, ולא בשם קונה אחר.

נכסי קריאייטיב מסוג HTML5

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

Google לא יכולה ליישם פתרון של אי-התאמה אם פלטפורמת ה-Exchange עוטפת קריאייטיב של Google HTML בתג (script,‏ iframe או שיטות אחרות) שמטעין או מעבד לאחר מכן את קוד ה-HTML של Google.

עומד בדרישות הטכניות

בדוגמה הזו, קוד ה-HTML של הקריאייטיב מ-Google‏ (DV360) מהתגובה לבידינג מועבר כפי שהוא, עם קוד HTML ספציפי לזירת המסחר שמצורף בתחילת הקוד ובסופו.

<!-- START exchange-specific HTML header -->
<iframe src="https://exchange.example.com/impression?…" width="0" height="0" frameborder="0" scrolling="no" style="display:none;" marginheight="0" marginwidth="0"></iframe>
<!-- END exchange-specific HTML header -->
<!-- START HTML code as returned by Google in the bid response -->
<DIV STYLE="position: absolute; left: 0px; top: 0px; visibility: hidden;"><IMG SRC="https://pagead2.googlesyndication.com/pagead/gen_204?id=xbid&dbm_b=…" BORDER=0 WIDTH=1 HEIGHT=1 ALT="" STYLE="display:none"></DIV><iframe title="Blank" src="https://googleads.g.doubleclick.net/xbbe/pixel?d=…" style="display:none" aria-hidden="true"></iframe><div><div style="position:relative; display:inline-block;"><div class="GoogleActiveViewClass" id="DfaVisibilityIdentifier_…"><script>var url = 'https://googleads.g.doubleclick.net/dbm/ad?…';document.write('<script src="' + (window.rfl ? window.rfl(url) : url) + '"></s' + 'cript>');</script>…
<!-- END HTML code as returned by Google in the bid response -->
<!-- START exchange-specific HTML footer -->
<img src='https://exchange.example.com/track?…' width='0' height='0' style='display:none;'>
<!-- END exchange-specific HTML footer -->

לא עומד בדרישות הטכניות

בדוגמה הזו, קוד ה-HTML של הקריאייטיב שהוחזר על ידי Google עבר ערפול בתשובה להצעת המחיר שסופקה על ידי פלטפורמת ה-Exchange, ולא מופיע במלואו בתשובה להצעת המחיר. קוד HTML ש-Google מספקת עשוי לעבור עיבוד על ידי מעטפת שספק פלטפורמת ה-Exchange מספק בדפדפן.

<!-- START exchange ad tag that encodes / renders Google creative in the browser -->
<!-- Google creatives markup from the bid response (adm) is not present verbatim -->
<span class="ad"><script type='text/javascript' src='https://exchange.example.com/ad?p=%%WINNING_PRICE%%&m=n_ybbRoVpsLlXSo8gVHRn-W0tynBt-Hoe8t8m0qwKhLFiaF-0gB0U4w-5pjeB8IMIkg7PcRri5iCIjBMMKDqg
…'></script></span>
<!-- END exchange ad tag that encodes / renders Google creative in the browser -->

קריאייטיבים של מודעות וידאו בפורמט VAST

כדי לעמוד בדרישות לפתרון אי ההתאמה, פלטפורמת ה-Exchange צריכה להשתמש באחת מהגישות הבאות כדי לאכלס את השדה VASTTagURI בתגובות VAST בפורמט XML:

1. פלטפורמת ה-exchange יכולה לשמור את הערך של הרכיב VASTTagURI כחלק ממסמך ה-XML של VAST שמוחזרים על ידי Google בשדה BidResponse.seatbid.bid.adm כפי שהוא, עם הרחבות המאקרו הספציפיות לפלטפורמת ה-exchange שחלות בדרך כלל.
2. מערכת DV360 יכולה לאכלס את השדה BidResponse.seatbid.bid.adm.nurl בכתובת URL של מסמך VAST בתגובות לבקשות להצעות מחיר בזירת מסחר. לאחר מכן, פלטפורמת ה-Exchange יכולה להעביר את הערך הזה באמצעות התג VASTTagURI, כאשר המאקרו הספציפי לפלטפורמת ה-Exchange יתרחב באופן רגיל לפי הצורך.

אם יש צורך, פלטפורמת ה-Exchange יכולה לציין בתוך מסמך ה-XML של ה-VAST שירותי מעקב נוספים אחרי אירועים ושגיאות ב-VAST.

עומד בדרישות הטכניות

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

<!-- START exchange VAST tag referencing Google creative -->

<?xml version="1.0" encoding="UTF-8"?><VAST version="2.0"><Ad id="123456789"><Wrapper>

<!-- Google VAST URI from the bid response is present verbatim -->
<AdSystem>XBid</AdSystem><VASTAdTagURI><![CDATA[https://bid.g.doubleclick.net/dbm/vast?…]]></VASTAdTagURI>

<!-- START Exchange-specific event trackers -->

<Error><![CDATA[https://video.exchange.example.com/vast_error?error=[ERRORCODE]&…]]></Error><Impression><![CDATA[https://video.exchange.example.com/impression?price=%%WINNING_PRICE%%&…]]></Impression><Creatives><Creative id="1234567890" sequence="1"><Linear><TrackingEvents><Tracking event="creativeView"><![CDATA[https://video.exchange.example.com/track/view?…]]></Tracking><Tracking event="start"><![CDATA[https://video.exchange.example.com/track/start?…]]></Tracking><Tracking event="midpoint"><![CDATA[https://video.exchange.example.com/track/midpoint?…]]></Tracking></TrackingEvents><VideoClicks><ClickTracking><![CDATA[https://video.exchange.example.com/click?…]]></ClickTracking></VideoClicks>

<!-- END Exchange-specific event trackers -->

</Linear></Creative></Creatives></Wrapper></Ad></VAST>

<!-- END exchange VAST tag referencing Google creative -->

לא עומד בדרישות הטכניות

בדוגמה הזו, קוד ה-VAST או ה-URI של הקריאייטיב שהוחזרו על ידי Google לא מופיעים מילה במילה בתשובה לבידינג, ובמקום זאת נעשה שימוש ב-wrapper של VAST שספציפי ל-Exchange. קוד VAST ש-Google מספקת יכול להיות נטען על ידי מעטפת VAST שספק פלטפורמת ה-Exchange מספק (כפי שמוגדר ברכיב VASTAdTagURI, https://video.exchange.example.com/creative?…) כש-SDK טוען מודעה.

<!-- START exchange VAST tag that encodes or loads Google VAST creative subsequently -->
<!-- Google VAST URI or VAST document from the bid response is not present verbatim -->

<?xml version="1.0" encoding="UTF-8"?><VAST version="2.0"><Ad id="1234567890"><Wrapper><AdSystem version="0.1">VideoExchange</AdSystem><VASTAdTagURI><![CDATA[https://video.exchange.example.com/creative?…]]></VASTAdTagURI><Error><![CDATA[https://video.exchange.example.com/error?ec=[ERRORCODE]]]></Error><Impression><![CDATA[https://video.exchange.example.com/imp?…]]></Impression><Creatives><Creative></Creative></Creatives></Wrapper></Ad></VAST>
<!-- END exchange VAST tag that encodes or loads Google VAST creative subsequently -->

מבצעים

פלטפורמות שמשתתפות ב-Open Bidding יכולות להשתמש בדילים בלעדיים ללקוחות מועדפים (PD) ובמכרזים פרטיים (PA) עם Open Bidding. יש לציין את מזהה העסקה ואת הסוג שלה באופן הבא:

שדה	תיאור
BidResponse.seatbid.bid.dealid	מזהה העסקה ממרחב השמות של פלטפורמת ה-Exchange שמשויך לבידינג ודווח לבעלי האפליקציות. זהו טקסט UTF8 שרירותי, שאורכו לא יכול לחרוג מ-64 בייטים.
BidResponse.seatbid.bid.ext.exchange_deal_type	enum שמציין את סוג העסקה. הנתון הזה מדווח לבעלי האפליקציות ומשפיע על האופן שבו העסקה מטופלת במכרז. הערכים האפשריים הם: OPEN_AUCTION = 0; PRIVATE_AUCTION = 1; PREFERRED_DEAL = 2; EXCHANGE_AUCTION_PACKAGE = 3;

זוהי דוגמה לתגובה לבקשה להצעת מחיר ל-PD/PA.

id: "ECHO_BIDREQUEST_ID"
seatbid {
  bid {
    id: "BID_ID"
    impid: "1"
    price: 1.23
    adm: "AD_TAG"
    adomain: "DECLARED_LANDING_PAGE_URL"
    cid: "BILLING_ID"
    crid: "CREATIVE_ID"
    dealid: "DEAL_ID"
    w: 300
    h: 250
    [com.google.doubleclick.bid] {
      impression_tracking_url: "IMPRESSION_TRACKING_URL"
      exchange_deal_type: "DEAL_TYPE"
    }
  }
}

התאמות של קובצי Cookie

כדי לאכלס את טבלאות ההתאמה שמתארחות ב-Google, המשתתפים בתוכנית Open Bidding יכולים להשתמש בכל אחת מהאפשרויות הבאות שמתאימה לצרכים שלהם:

• התאמה לפי קובצי Cookie: התאמה שמבוססת על הקונה או על יזום של המשתמש באתר המסחר האלקטרוני מידע נוסף
• התאמת פיקסלים: התאמה ביוזמת Google מידע נוסף
• התאמה של קובצי Cookie: התאמה שמתחילה בזירת המסחר עם המגישים של הצעות המחיר שלה מידע נוסף

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

ניהול זמן האחזור

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

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

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

פקודות מאקרו לקליק

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

ממשקי API

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

• דוח ביצועים בגרסה 1.4
• פתרון בעיות ב-RTB בגרסה v2beta1

אתם יכולים לפנות למנהל החשבונות הטכני כדי להגדיר את החשבון לגישה לממשקי ה-API האלה, ולקבל את מזהה החשבון הנדרש לשליחת קריאות ל-API. כדי לקבל תמיכה טכנית בשימוש ב-API האלה, אפשר לפנות לכתובת האימייל החלופית לתמיכה: [e-mail].

מקורות מידע נוספים

• שיטות מומלצות לניהול חיבורים
• שימוש במאקרו של כתובת URL לבידינג
• פענוח של אישורי מחירים אם משתמשים במאקרו WINNING_PRICE
• המלצות ושיטות מומלצות לבדיקות

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

דוגמאות לבקשות ולתשובות לבידינג לכל הפרוטוקולים הנתמכים מפורטות במדריכים בנושא בקשה ותגובה.