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

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

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

הגבלת השילוב לבעלי תוכן דיגיטלי נבחרים

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

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

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

הטמעת Google OpenRTB

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

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

מבנה BidRequest של Open Bidding זהה לזה של Authorized Buyers, אבל חלק מהשדות נשלחים באופן בלעדי למשתתפים ב-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 Display & Video 360 (DV360) משלמת.

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

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

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

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

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

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

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

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

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

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

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

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

<!-- 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 מחזירה מעורפל (obfuscation) בתגובה להצעת המחיר שהוגדרה על ידי פלטפורמת ה-Exchange ולא מופיע מילה במילה בתשובה להצעת המחיר. קוד HTML שסופק על ידי Google עשוי לעבור רינדור באמצעות wrapper בדפדפן שסופק.

<!-- 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 כפי שהוא, עם הרחבות מאקרו ספציפיות ל-Exchange שחלות בדרך כלל.
2. מערכת DV360 יכולה לאכלס את השדה nurl בכתובת URL של מסמך VAST בתגובה להצעות מחיר לפלטפורמת Exchange. לאחר מכן, הבורסה יכולה להעביר את הערך של nurl ש-Google (DV360) מגיבה באמצעותו בתג VASTTagURI, ופקודות מאקרו ספציפיות ל-Exchange מתרחבות כרגיל לפי הצורך.

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

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

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

<!-- 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: התאמה של קונה או Exchange ביוזמת Exchange למידע נוסף.
• התאמה ל-Pixel: התאמה ביוזמת Google למידע נוסף.
• Cookie Match Assist: התאמה ביוזמת Exchange למגישי הצעות המחיר שלהם למידע נוסף.

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

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

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

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

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

רכיבי מאקרו לקליק

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

ממשקי API

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

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

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

משאבים נוספים

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

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

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