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

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

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

הגבלת השילוב לבעלי אפליקציות נבחרים

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

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

מומלץ להשתמש בהטמעת OpenRTB של Google. פרוטוקול RTB של Google הוצא משימוש. מידע נוסף

הטמעת Google OpenRTB

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

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

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

הוספת תגובה עם הצעת מחיר

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

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

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

• מודעות מעברון
• מודעות וידאו
• מודעות וידאו מסוג OpenRTB
• מודעות מותאמות
• מודעות וידאו מותאמות
• מודעות SDK של קונים

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

מומלץ מאוד להשתמש במאפיין האופציונלי impression_tracking_url שדה לאחזור נתונים ברמת החשיפה לגבי המועד שבו Google מתעדת נתונים לחיוב אירועים שבהם תחויבו. עבור OpenRTB המזהה הזה חשוף כ-BidResponse.seatbid[].bid[].ext.impression_tracking_url, ובתור BidResponse.ad[].impression_tracking_url ב-Google של Google.

יישוב פערים בביקוש ב-Google (בטא)

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

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

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

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

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

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

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

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

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

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

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

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

בדוגמה הזו, קוד ה-HTML של הקריאייטיב ב-Google (DV360) הוא קוד ה-HTML של הקריאייטיב מהתגובה להצעת מחיר מועבר מילה במילה, מופיע בתחילתו ומצורף לו קוד 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 מעורפל (obfuscated) בתגובה להצעת המחיר שסופקה על ידי בורסת הפרסום ולא מופיעה מילה במילה התגובה לבקשת הצעת המחיר. קוד HTML ש-Google סיפק עשוי להיות מעובד wrapper במסגרת 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

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

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

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

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

בדוגמה זו, Google (DV360) מזהה VAST URI מהתגובה של הצעת המחיר מועבר מילה במילה, ובפלטפורמת הבורסה מוסיפים את אירוע ה-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 לא מופיע מילה במילה, ובמקום זאת נעשה שימוש ב-VAST wrapper שספציפי לבורסה. ניתן לטעון קוד VAST ש-Google סיפקה על ידי wrapper של 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. יש לציין את מזהה העסקה ואת סוג העסקה באופן הבא:

שדה	תיאור
פרוטוקול OpenRTB: BidResponse.seatbid[].bid[].dealid הפרוטוקול של Google: BidResponse.ad[].adslot[].exchange_deal_id	מזהה העסקה ממרחב השמות של הבורסה המשויך להצעת המחיר, ומדווח לבעלי האתרים. מדובר בטקסט UTF8 שרירותי ובגודל של עד 64 בייטים.
פרוטוקול OpenRTB: BidResponse.seatbid[].bid[].ext.exchange_deal_type הפרוטוקול של Google: BidResponse.ad[].adslot[].exchange_deal_type	'טיפוסים בני מנייה (enum)' שמציין את סוג העסקה. הדיווחים האלה מועברים לבעלי התוכן הדיגיטלי ומשפיעים על אופן העסקה. שיטופלו במכרז. הערכים האפשריים הם: OPEN_AUCTION = 0; PRIVATE_AUCTION = 1; PREFERRED_DEAL = 2; EXCHANGE_AUCTION_PACKAGE = 3;

בהמשך מוצגת דוגמה לתגובה לפי הצעת מחיר מסוג OpenRTB עבור PD/PA.

בדוגמה הבאה נעשה שימוש בשדות OpenRTB ל-PD/PA (dealid, exchange_deal_type); אם משתמשים בפרוטוקול Authorized Buyers, שדות התגובה להצעות מחיר עבור PD/PA יהיו exchange_deal_id ו exchange_deal_type.

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 Match Assist: התאמה ביוזמת Exchange למגישי הצעות המחיר שלהם מידע נוסף מפורט כאן.

הערה: משתתפים ב-Open Bidding לא יכולים ליצור, לאכלס או לטרגט רשימות משתמשים בשלב הזה.

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

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

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

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

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

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

ממשקי API

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

• v1.4 דוח ביצועים
• פתרון בעיות שקשורות לבידינג בזמן אמת (RTB) בגרסה v2beta1

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

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

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

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

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