Protected Audience API (לשעבר FLEDGE)

כחלק מארגז החול לפרטיות, הצענו ב-Chrome את Protected Audience API – ממשק API בדפדפן שמאפשר למפרסמים ולחברות טכנולוגיות פרסום להציג מודעות שמטרגטות קבוצות אינטרס בלי להסתמך על קובצי Cookie של צד שלישי, ובו-זמנית להגן על המשתמשים מפני מעקב באתרים שונים.

ב-Chrome מתבצע ניסוי של גרסת מקור ל-Protected Audience API. קונים מורשים יכולים להשתתף בבדיקות של Protected Audience API במלאי שטחי הפרסום של בעלי תוכן דיגיטלי ב-Ad Manager. המשתתפים במכרז יכולים להשיג את היתרונות הבאים באמצעות בדיקה של Protected Audience API:

  • מבצעים איטרציות ולומדים על היעילות של תהליכי העבודה של Protected Audience API.
  • לפרסם משוב בפורומים ציבוריים על שיפורים אפשריים ב-API – לדוגמה, ב-GitHub.
  • הכנות לתמיכה בפרסום בהתאמה אישית דרך ה-API בלי להסתמך על קובצי Cookie של צד שלישי.

קונים ב-Authorized Buyers שמעוניינים לבצע בדיקות יכולים לעיין בפרטים בקטע בנושא צירוף.

סיכום תהליך הצגת המודעות

לפניכם סיכום של תהליך הצגת המודעות ב-Protected Audience API לשותפים ב-Authorized Buyers:

תרשים זרימה

  1. מגיש הצעת מחיר עובד עם המפרסמים שלו כדי לשמור על קבוצות של נושאים שמעניינים כל מפרסם. לעתים קרובות, מפרסמים מוסיפים תג של משתתף במכרז לדף של המפרסם כדי להוסיף דפדפן לקבוצות של תחומי עניין.
  2. משתמש קצה מבקר בדף של מפרסם. יכול להיות שהדף מכיל את תג הצעת המחיר של הקונה.
  3. תג הבידינג מפעיל את Protected Audience API joinAdInterestGroup(). הקריאה הזו מבקשת מהדפדפן להוסיף את המשתמש לקבוצת אינטרס.
  4. משתמש הקצה מבקר בדף אינטרנט של בעל תוכן דיגיטלי. הדפדפן של המשתמש שולח בקשה לתג המודעה של בעל התוכן הדיגיטלי של Google.
  5. תג המודעה של בעל התוכן הדיגיטלי ב-Google שולח בקשה להצגת מודעה לפי הקשר לשרת של Google.
  6. ‫Google שולחת בקשות להצעות מחיר לפי הקשר למגישי הצעות המחיר המשתתפים. מידע נוסף זמין בקטע שינויים בבקשות להצעות מחיר.
  7. המשתתף בבידינג מחזיר תגובה לבקשה להצעת מחיר שכוללת את ההודעה InterestGroupBidding שנדרשת כדי להשתתף במכרז של קבוצת המתעניינים. ב-OpenRTB, השדה הזה מצוין באמצעות BidResponse.ext.igbid, ובפרוטוקול RTB של Google שהוצא משימוש, השדה הזה מצוין באמצעות BidResponse.interest_group_bidding. אם מגיש הצעת המחיר לא מציין את המידע הזה, Google לא כוללת את המקור של מגיש הצעת המחיר ב-interestGroupBuyers בהגדרות המכרז. ‫InterestGroupBidding יכול להכיל גם אותות אופציונליים שספציפיים לקונה, שיועברו לפונקציית הבידינג של המגיש במהלך המכרז בדפדפן. ב-OpenRTB זה מצוין בשדה BidResponse.ext.igbid.igbuyer.buyerdata, ובפרוטוקול Google RTB שיצא משימוש זה מצוין בשדה BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. מידע נוסף זמין בקטע שינויים בתשובות לבקשות בידינג.
  8. ‫Google מריצה את המכרז בצד השרת ומחזירה תגובה להצעת המחיר לדפדפן. במכרז בצד השרת נלקחים בחשבון הצעות מחיר מסורתיות בצד השרת. תגובת הצעת המחיר יכולה להכיל מידע על הצעת מחיר מנצחת בהקשר (אם יש כזו).
  9. התגובה לבקשת הצעת המחיר מכילה הגדרת מכרז למכרז בדפדפן. האותות האלה יכולים לכלול אותות הקשריים מכל קונה משתתף (שנשלחו קודם דרך buyerdata של OpenRTB או דרך per_buyer_signals של פרוטוקול Google RTB שיצא משימוש), מידע על המודעה הזוכה בהקשר והגדרות של עמידה בדרישות להגשת הצעת מחיר.
  10. תג בעל האתר של Google מפעיל את Protected Audience API runAdAuction() כדי ליזום את המכרז של קבוצת האינטרס במכשיר. ‫Google כוללת רק קונים שנכללו כ-InterestGroupBuyer ב-InterestGroupBidding במהלך הגדרת המכרז.
  11. ‫Google מעבירה את האותות האופציונליים הספציפיים לקונים של כל משתתף במכרז שעומד בדרישות אל הגדרת המכרז של Protected Audience.
  12. אם קבוצות האינטרס של מגיש הצעת מחיר מסוים ציינו את trustedBiddingSignalsUrl, הדפדפן שולח בקשה לכל trustedBiddingSignalsUrl של קבוצה כדי לאחזר אותות בזמן אמת לכל קבוצה. פרטים נוספים זמינים במפרט של Protected Audience API.
  13. הדפדפן מפעיל את generateBid() של מגיש הצעת המחיר לכל קבוצה של תחומי עניין שהצטרפה ועומדת בדרישות להשתתפות במכרז בדפדפן. בשלב הזה המערכת מחשבת את הצעת המחיר ובוחרת קריאייטיב. ל-generateBid() יש גישה לאותות הקונים האופציונליים שסופקו על ידי מגיש הצעות המחיר ולאותות הבידינג המהימנים עבור קבוצת האינטרסים הנתונה.
  14. הדפדפן מפעיל את scoreAd() של המוכר (במקרה הזה, Google) כדי להקצות דירוג לכל הצעת מחיר במכרז המודעות של קבוצת תחומי העניין. הצעות המחיר מדורגות ומסוננות על סמך אמצעי ההגנה של בעלי התוכן הדיגיטלי, מדיניות המודעות ומגבלות אחרות.
  15. הדפדפן מפעיל מכרז עם הצעות המחיר הרלוונטיות של קבוצות תחומי העניין. הצעת המחיר ההקשרית עם הדירוג הכי גבוה משתתפת במכרז בדפדפן.
  16. אחרי המכרז, אם יש מודעה מנצחת שמבוססת על קבוצה של תחומי עניין, הדפדפן מפעיל את reportResult() של המוכר ואת reportWin() של המגיש כדי להודיע לכל צד על המודעה המנצחת במכרז בדפדפן.
  17. אם מודעה של קבוצת עניין זוכה, תג בעל התוכן הדיגיטלי של Google מעבד את המודעה ב-iframe.

פרטים על תהליך הצגת המודעות

לפני הצגת המודעות

בדיקת קריאייטיב

‫Google צריכה לבדוק ולאשר את הקריאייטיבים לפני שניתן יהיה להציג אותם במכרזים בדפדפן של Protected Audience. אפשר לשלוח קריאייטיבים לבדיקה באמצעות Real-time Bidding API או באמצעות סריקה אוטומטית של קריאייטיבים. קריאייטיבים למכרזי מודעות של קבוצות עם תחומי עניין בדפדפן במסגרת Protected Audience חייבים לכלול את התג renderUrls לצורך בדיקה.

הדרישות לגבי renderUrls:

  • הערך של renderUrl שמועבר דרך ה-API צריך להיות זהה לערך של renderUrl שמשמש במכרז על מודעות לקבוצת המתעניינים.
  • כל תג renderUrl יכול לייצג רק מפרסם אחד או קמפיין פרסום אחד. לא ניתן להשתמש בתג renderUrl כדי להציג מודעות בשם כמה מפרסמים. כל renderUrl צריך להיות ממופה לקריאייטיב יחיד.
  • ‫renderUrl צריך להיות נגיש למערכות של Google לבדיקת קריאייטיב אופליין, וניתן לאחזור על ידי המערכות האלה למשך עד 7 ימים אחרי שהוגשה הצעה אחרונה להצגת המודעה.
Real-time Bidding API

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

סריקה אוטומטית של קריאייטיבים

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

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

כדי להפעיל סריקה אוטומטית של קריאייטיבים:

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

  • מוסיפים את כותרות ה-HTTP המותאמות אישית הבאות לתגובת ה-HTTP של הקריאייטיב:

    Authorized-Buyers-Creative-ID

    מחרוזת

    מזהה קריאייטיב ספציפי לקונה. האורך המקסימלי של מזהה הקריאייטיב הוא 128 בייטים.
    Authorized-Buyers-Click-Through-URLs

    מחרוזת

    קבוצת כתובות היעד המוצהרות של הקריאייטיב, מקודדות לפי RFC2396.

דוגמה:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
תפוגת תוקף של קריאייטיב

האישור של נכסי הקריאייטיב תקף ל-15 יום. אם אתם שולחים קריאייטיבים באמצעות Real-time Bidding API, תצטרכו לשלוח מחדש את הקריאייטיב אחרי 15 ימים. אם אתם מסתמכים על סריקה אוטומטית של קריאייטיבים, תהליך הסריקה יסרוק אותם מחדש באופן אוטומטי.

מזהה דיווח של קונה

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

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

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

המאפיין buyer_reporting_id יופיע כמאפיין חדש בכלי הדיווח של הקונה המורשה, בשם מאפיין מזהה הדיווח של הקונה.

מכרז בצד השרת

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

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

ציון תמיכה במכרזים של קבוצות אינטרס

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

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • פרוטוקול RTB של Google (הוצא משימוש):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

אפשר להשתמש בשדה הזה כדי להבחין בין הזדמנויות להצגת מודעות שתומכות במכרז של קבוצות של תחומי עניין בדפדפן באמצעות Protected Audience, לבין הזדמנויות שתומכות רק במכרז המסורתי בבורסת פרסום בצד השרת. ‫Enum‏ AuctionEnvironment יכול לכלול את הערכים הבאים:

  • ‫SERVER_SIDE_AUCTION (OpenRTB JSON: 0): המכרז שקובע את המודעה הזוכה מתבצע בשרתים של הבורסה.
  • ‫ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): בקשות עם תמיכה ב-Protected Audience, שבהן מתנהל מכרז הקשרי בשרתים של הבורסה, והגשת הצעות מחיר לקבוצות של תחומי עניין והמכרז הסופי מתנהלים בדפדפן.
  • ‫SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): המכרז ההקשרי מתבצע בשרתים של הבורסה, והלוגיקה של הבידינג להצעות מחיר לקבוצות של נושאים משותפים והלוגיקה של הניקוד לקביעת המודעה הזוכה הסופית מופעלות בשרתים של בידינג ומכרזים.
ציון הגודל של מיקום המודעה ב-Protected Audience

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

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • פרוטוקול RTB של Google (הוצא משימוש):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

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

הגודל הזה עשוי להיות שונה מהגודל שמופיע בבקשה ההקשרית, כמו הגודל שמופיע בשדות BidRequest.imp.banner.format.w ו-BidRequest.imp.banner.format.h של OpenRTB או בשדות BidRequest.adslot.width ו-BidRequest.adslot.height של פרוטוקול RTB של Google שיצא משימוש.

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

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

יכול להיות שמודעות Protected Audience יוצגו או לא יוצגו, בהתאם לשלב הנוכחי של השילוב (ראו ניסוי ללא הצגה). השדה render_interest_group_ads בבקשה להצעת מחיר מציין אם המודעה המנצחת של Protected Audience תוצג.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • פרוטוקול RTB של Google (הוצא משימוש): BidRequest.adslot.interest_group_auction.render_interest_group_ads
צמצום ההסתמכות על מזהי משתמשים

בקשות להצעות מחיר לפי הקשר שנכללות בבדיקות של Protected Audience API יכולות להמשיך לשאת מזהים מסורתיים שמבוססים על קובצי Cookie, אם הם זמינים מהדפדפן, כמו השדות BidRequest.user.id ו-BidRequest.user.buyerid, או BidRequest.google_user_id ו-BidRequest.hosted_match_data בפרוטוקול Google RTB שהוצא משימוש. השימוש במזהים כאלה בבקשות להצעות מחיר כפוף למדיניות הפרטיות הקיימת. כדי להתכונן בצורה טובה יותר לקנייה יעילה כשקובצי Cookie של צד שלישי לא יהיו זמינים יותר, מומלץ לא להסתמך על מזהים מבוססי-Cookie למטרות טירגוט ובידינג במהלך הבדיקה.

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

כדי להתכונן להוצאה משימוש של קובצי Cookie של צד שלישי (3PCD) בשנת 2024, Chrome מציע עכשיו בדיקות שמתבצעות באמצעות Chrome.

אתרים וספקים יכולים להשתמש בבדיקות שמתבצעות באמצעות Chrome כדי לבדוק את המערכות שלהם במסגרת 3PCD. בבדיקה, דפדפני Chrome משויכים לקבוצת ניסוי של 3PCD, במצב א' או במצב ב'. לכל דפדפן מוקצית תווית עקבית שמתאימה לקבוצת ניסוי ספציפית של 3PCD שאפשר לגשת אליה דרך Chrome API בדפדפן.

‫Google מעבירה את התווית ללא שינוי מ-Chrome API בבקשה להצעת מחיר ב-RTB. בגלל חלקי התנועה הקטנים של תווית מסוימת, Google לא תמיד כוללת את התווית בהקשרים עם הגבלות על פרטיות.

אלה השדות שבהם אפשר לראות את התווית:

  • OpenRTB: BidRequest.device.ext.cdep
  • פרוטוקול RTB של Google (הוצא משימוש): BidRequest.device.cookie_deprecation_label

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

ציון השתתפות במכרז של קבוצת אינטרס

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

  • OpenRTB: ‏ BidResponse.ext.igbid
  • פרוטוקול RTB של Google (הוצא משימוש): BidResponse.interest_group_bidding

חובה לספק תגובה להצעת מחיר בהקשר. התשובה לא צריכה לכלול הצעת מחיר בהקשר. אובייקט InterestGroupBidding צריך להכיל את origin של כל InterestGroupBuyer, שצריך להיות זהה לאחד מהמקורות שהוגדרו על ידי המגיש להצעת המחיר בחשבון שלו. התג origin נוסף לinterestGroupBuyers של הגדרת המכרז כש-Google Publisher Tag קורא ל-runAdAuction().

הפצה של אותות בהקשר של הקונה

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

  • OpenRTB: ‏ BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (הוצא משימוש): BidResponse.interest_group_bidding.per_buyer_signals
הפצה של אותות הקשר של הקונים לגבי עיבוד

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

אתם יכולים לכלול בתגובה להצעת המחיר ההקשרית אותות עיבוד של הקונה שסודרו בפורמט סדרתי כמחרוזת בטוחה לשימוש בכתובת URL. Google תחליף את המחרוזת הזו בכתובת ה-URL של העיבוד של קבוצת המתעניינים הזוכה, על ידי יצירת מאקרו ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

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

  • OpenRTB: ‏ BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (הוצא משימוש): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

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

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

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

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

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

  • ‫OpenRTB: ‏ BidResponse.igbid.igbuyer.maxbid(מוצג ביחידות מטבע של עלות לאלף חשיפות)
  • פרוטוקול RTB של Google (יצא משימוש): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (מוצג במיקרו-עלות לאלף חשיפות)
שיוך חשיפות לכמה חשבונות

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

  • OpenRTB: ‏ BidResponse.igbid.igbuyer.billing_id
  • פרוטוקול RTB של Google (הוצא משימוש): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

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

  • OpenRTB: ‏ BidRequest.imp.ext.billing_id
  • פרוטוקול RTB של Google (הוצא משימוש): BidRequest.adslot.matching_ad_data.billing_id

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

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

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

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

במהלך מכרז בדפדפן

יצירת הצעות מחיר בדפדפן

משתמשים ב-generateBid() כדי ליצור הצעות מחיר בדפדפן.

‫Google מספקת את הפרמטרים הבאים:

  • auctionSignals: ריק
  • ‫perBuyerSignals: אובייקט JavaScript של אותם אותות שסופקו על ידי הצעת המחיר בתגובה ההקשרית

הפרמטרים הבאים מוחזרים:

  • ‫ad: Google מתעלמת מהשדה הזה.
  • ‫bid: הצעת מחיר מספרית שמשתתפת במכרז. הערך צריך להיות ביחידות של עלות לאלף חשיפות (CPM) (ולא במיקרו).
  • ‫render: כתובת ה-URL שמוצגת כדי להציג את הקריאייטיב אם ההצעה זוכה במכרז. ‫Google צריכה לבדוק ולאשר את כתובת ה-URL הזו, אחרת היא תסונן מהמכרז.
  • allowComponentAuction: הערך צריך להיות true. נכון לעכשיו, Google תומכת בבדיקה של מכרזים עם כמה מוכרים.

לדוגמה:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

הסבר על הפונקציה generateBid() מופיע בקטע On-Device Bidding במפרט של Protected Audience.

מטבע הבידינג

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

צריך לציין את המטבע של הצעת המחיר גם בתגובה להצעת המחיר בהקשר וגם בערך ההחזרה של generateBid. המטבע צריך להיות קוד אלפא תקף לפי תקן ISO 4217, כמו USD,‏ EUR או JPY.

ב-OpenRTB, משתמשים בשדה cur החדש באובייקט InterestGroupBuyer בתוסף של Google לתגובות להצעות מחיר.

לדוגמה:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

בפרוטוקול Google RTB, משתמשים בשדה currency החדש בהודעה InterestGroupBuyer בתשובת הבידינג.

לדוגמה:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

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

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

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

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

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

תמיכה בנושא Digital Services Act (חוק השירותים הדיגיטליים, DSA)

בהתאם לסעיף 26 של Digital Services Act (חוק השירותים הדיגיטליים), בעלי תוכן דיגיטלי עשויים לדרוש מקונים להציג גילוי נאות לגבי שקיפות במודעות. כשבעל התוכן הדיגיטלי מפעיל את אמצעי הבקרה 'אני רוצה שהקונים יציגו באתר או באפליקציה שלי רק מודעות שכוללות מידע בנושא שקיפות בהתאם ל-DSA למשתמשים שנמצאים ב-EEA', קונים של קבוצות אינטרסים יכולים לקבוע באילו הזדמנויות הם יידרשו להציג מידע למתן שקיפות בהתאם ל-DSA. לשם כך הם צריכים לשים לב לערכים של BidRequest.regs.dsa.required ושל BidRequest.dsa.pubrender בבקשה להצעת מחיר (BidRequest.dsa.dsa_support ו-BidRequest.dsa.publisher_rendering_support בהתאמה בפרוטוקול Google RTB שיצא משימוש).

כשמגיש הצעת מחיר שרוצה להשתתף במכרזים של Protected Audience API מקבל אות בבקשה להצעת מחיר, שלפיו צריך להציג במודעות שמוצגות דרך Protected Audience API מידע למתן שקיפות בהתאם ל-DSA, עליו לבדוק אם הוא יכול להציג את המידע הנדרש בצורה הולמת. כדי לציין את זה, הוא צריך להגדיר את BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render בפרוטוקול Google RTB שהוצא משימוש). אחרת, הקונה לא ייכלל במכרז של Protected Audience API.

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

סינון הצעות מחיר

‫Google אוכפת אמצעי בקרה של בעלי האתרים ומדיניות בנושא מודעות במהלך המכרז במכשיר.

אחרי מכרז בדפדפן

דיווח על תוצאת המכרז לקונה: reportWin()‎

‫Google לא מאכלסת את הארגומנטים הבאים:

  • auctionSignals
  • sellerSignals

משתמשים ב-reportWin() כדי לדווח לקונה על תוצאת המכרז.

מידע נוסף זמין בקטע דיווח של הקונים על אירועי רנדור ומודעות במאמר שמסביר על Protected Audience API.

פקודות מאקרו

התג renderUrl שמפנה לנכס קריאייטיב של Protected Audience API יכול לכלול placeholder אחד או יותר, שנקראים פקודות מאקרו. אחרי שמכרז קבוצת האינטרס מסתיים, אבל לפני העיבוד, המאקרואים מוחלפים בערכים המתאימים. renderUrl שמשמש במכרז במכשיר יכול לכלול את פקודות המאקרו הבאות:

${GDPR} הערך הוא 0 אם תקנות ה-GDPR לא חלות, או 1 אם הן חלות. לצפייה במסמכי התיעוד
${GDPR_CONSENT_XXXX} הפרטים מתרחבים ומוצגת מחרוזת נתוני השקיפות וההסכמה (TC) שמשויכת לבקשה. אם מחרוזת נתוני השקיפות וההסכמה (TC) ריקה או לא תקינה, פקודת המאקרו הזו לא תורחב.

משתמשים במאקרו הזה כדי להעביר את המחרוזת בנושא שקיפות והסכמה לספק שרשום ברשימת הספקים הגלובלית (GVL) של IAB בכתובת URL. מחליפים את XXXX במזהה GVL של IAB של הספק שרשום ב-GVL של IAB. אם מחרוזת נתוני השקיפות וההסכמה ריקה או לא תקינה, פקודת המאקרו הזו לא תורחב.

יכול להיות שנכסי קריאייטיב עם פקודת המאקרו ${GDPR_CONSENT_XXXX} ייחסמו אם לספק שרשום ב-GVL של IAB, שמשויך למזהה ה-GVL של IAB שהוספתם, אין הסכמת משתמש.

מאקרו ${GDPR_CONSENT_XXXX} צריך להופיע רק פעם אחת בתוך renderUrl.
${ADDL_CONSENT} הפרמטר הזה מתרחב למחרוזת נתוני ההסכמה הנוספים (AC) שמשויכת לבקשה.
${AD_WIDTH}, ${AD_HEIGHT) פקודות המאקרו האלה מוסיפות את הרוחב והגובה של מיקום המודעה.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

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

מחליפים את placeholder‏ buyer.origin.example במקור של הקונה של קבוצת העניין, שצריך להתאים ל-interest_group_buyers.origin בתגובה להצעת המחיר. אפשר לכלול _OPTIONAL_SUFFIX כדי לספק עד שלושה ערכים שונים של אותות עיבוד.

ספירת חשיפות

במהלך הבדיקות של Protected Audience API עם שותפי RTB, ‏ Google תספור חשיפות כשהדפדפן יקרא לפונקציה reportResult() שלו ואחר כך יאחזר את כתובת ה-URL של הדיווח של Google בקריאה ל-sendReportTo().

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

אחת מהמטרות של Google בבדיקת Protected Audience API היא לזהות את אי ההתאמות האלה ולצמצם אותן.

שיוך של חשיפות שניתנות לחיוב

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

תקציב יומי מקסימלי

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

החשבון יכול להמשיך להשתתף במכרזים קונטקסטואליים בצד השרת אחרי שהוא מגיע למכסת השימוש ב-Protected Audience API. לדוגמה, חשבון של מגיש הצעות מחיר שהגיע למכסת השימוש ב-Protected Audience API עשוי לקבל בקשה להצעת מחיר עם הערך auction_environment = SERVER_SIDE_AUCTION (ב-JSON של OpenRTB: 0), גם אם הבקשה להצעת מחיר עומדת בדרישות להשתתפות במכרז של Protected Audience API.

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

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

  • סוג המשוב של אובייקט המשוב יהיה INTEREST_GROUP_BUYER_FEEDBACK.
  • מקור הקונה של קבוצת האינטרס.
  • הצעת המחיר המינימלית לזכייה של הקונה בקבוצת הנושאים כדי לזכות במכרז הכולל.
  • הצעת המחיר המינימלית לזכייה של הקונה בקבוצת העניין, כדי להתחרות בהצעת המחיר עם הדירוג הכי גבוה מרכיב הצד של השרת במכרז הכולל.
  • קוד הסטטוס של הקונה בקבוצת בעלי העניין. קודי הסטטוס האפשריים מוגדרים בקובץ interest-group-buyer-status-codes.txt.

שמות השדות הספציפיים מפורטים במסמכי התיעוד של הפרוטוקול בנושא RTB ב-Authorized Buyers והרחבות OpenRTB.

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

‫Chrome מספק API זמני לניפוי באגים עבור Protected Audience API, שמאפשר ל-Ad Manager לשלוח בזמן אמת התראות ניפוי באגים משרת לשרת שמכילות משוב על בידינג בקהל מוגן. ההתראה הזו תכלול את הסיבות לכך שאולי הצעות מחיר סוננו במכרז Protected Audience בדפדפן, בנוסף למידע אחר על הצעת מחיר שמתואר בהמשך.

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

  • ‫%%GOOGLE_QUERY_ID%%: המאקרו הזה מוחלף במזהה השאילתה של Google שנשלח בבקשה להצעת מחיר בהקשר שהופעלה בו התכונה 'קהלים מוגנים'. בפרוטוקול OpenRTB, הערך הזה מצוין באמצעות BidRequest.ext.google_query_id, ואילו בפרוטוקול RTB של Google שהוצא משימוש, הערך הזה מצוין באמצעות BidRequest.google_query_id.
  • ‫%%INTEREST_GROUP_OWNER%%: המקור של הבעלים של קבוצת העניין.
  • ‫%%BID_CPM%%: מחיר הצעת המחיר בשיטת העלות לאלף חשיפות שצוין על ידי הקונה בפונקציה generateBid().
  • ‫%%RENDER_URL%%: כתובת ה-URL של הקריאייטיב שמוצג.
  • ‫%%STATUS%%: קוד סטטוס אם הצעת המחיר נדחתה בתוך scoreAd(). הערכים הם קודי סטטוס של קריאייטיב.

הנה דוגמה לכתובת URL סטטית שמשתתף במכרז עשוי לספק למנהל החשבון שלו:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

ההתראה על משוב לגבי הצעות מחיר היא תכונה זמנית שתלויה ב-API הזמני ForDebuggingOnly של Chrome.

TURTLEDOVE ברמת המוצר

‫Ads Composed of Multiple Pieces או Product-level TURTLEDOVE (PLTD) נתמך אצל שותפי RTB של Google במהלך הבדיקה של Protected Audience API. אם אתם מתכננים לבדוק את PLTD, חשוב לעדכן את מנהל תיק הלקוחות שלכם במהלך השילוב, כי נדרשים משאבים נוספים והגדרה מיוחדת.

הדרכה למשתמשים חדשים

כך אפשר לבדוק את Protected Audience API:

שלבים

  1. ממלאים את טופס הבקשה כדי להצטרף לניסוי של Protected Audience API.
  2. אחרי ששולחים את טופס הבקשה, צריך לפנות אל מנהל החשבון או לשלוח כרטיס תמיכה באמצעות מרכז העזרה של Authorized Buyer.
  3. אחרי שמגדירים את החשבון, גם Google וגם השותף יכולים לאמת את השילוב באמצעות השלבים שמפורטים בקטע שלבי הבדיקה.

Creative Review

כדי להגיש הצעות מחיר על מודעות ברמת המוצר (מודעות שמורכבות מכמה חלקים) במכרזים של Protected Audience API, צריך לעמוד בדרישות הבאות:

  • כדי להבחין בין renderUrls ברמה העליונה במהלך בדיקת הקריאייטיב, צריך לכלול את פרמטר השאילתה &pltd=True ב-renderUrl של הקונטיינר של מודעת הרכיב (שנקרא גם renderUrl ברמה העליונה).
  • להציג קריאייטיב מייצג כשמאחזרים את מאגר הרכיבים של המודעה לצורך בדיקת קריאייטיב על ידי Google. כדי להבין מתי צריך להחזיר עיבוד של מודעה מייצגת, אפשר לעיין בפרמטר השאילתה validation=True שהוגדר על ידי מערכת בדיקת הקריאייטיב של Google.

רשימת משימות לשילוב

  • מגדירים נקודת קצה (endpoint) של בקשה להצעת מחיר שתאכלס שדות שקשורים ל-Protected Audience API בתגובה להצעת מחיר קונטקסטואלית – לדוגמה, interest_group_bidding.
  • מטמיעים תיוג בדפים של המפרסם כדי להוסיף את הדפדפן של המשתמש לקבוצת האינטרס.
  • הטמעה של generateBid() ושל reportWin().
  • בוחרים את המקורות של הבעלים של קבוצות הנושאים ומוסיפים אותם לחשבון הקונה המורשה.
    • המקורות של הבעלים של קבוצות נושאים צריכים להיות זהים למקורות שבהם מתארחות הפונקציות של generateBid().
    • כדי להשלים את השלב הזה, אפשר לפנות למנהל החשבון או לשלוח כרטיס תמיכה באמצעות מרכז העזרה של תוכנית הקונים המורשים.
  • הגדרה של טירגוט מקדים למלאי שטחים פרסומיים שרלוונטי לבדיקות של Protected Audience API.
  • שליחת קריאייטיבים לבדיקה ולאישור באמצעות Creatives API.
  • (אופציונלי) מגדירים את נקודות הקצה של אותות הבידינג המהימנים.
  • (אופציונלי) מגדירים דף בדיקה למפרסם שמאפשר למהנדסי Google להוסיף את הדפדפן שלהם לקבוצות של תחומי עניין שנמצאות בבעלות המקור של הקונה של קבוצת תחומי העניין. כך אנחנו יכולים להפעיל מכרזים בשילוב עם Protected Audience API באופן ידני.
  • (אופציונלי) מפעילים משוב בזמן אמת בחשבון כדי לקבל משוב על קונים של קבוצות אינטרסים שביקשו להיכלל במכרז של קהלים מוגנים.
  • (אופציונלי) אפשר לפנות אל מנהל החשבון כדי להגדיר כתובת URL סטטית לקבלת התראה משרת לשרת שמספקת משוב על הצעת מחיר של Protected Audience לגבי הסטטוס של הצעת מחיר ממכרז Protected Audience במכשיר, כדי לעזור באיתור באגים בבעיות לא צפויות. פרטים נוספים זמינים במאמר בנושא התראות על משוב בנוגע להצעות מחיר.

שלבי הבדיקה

שלב 1: בדיקה ידנית

כך מפעילים באופן ידני מכרז של Protected Audience, מוודאים שאפשר להציג את המודעה ומתעדים את החשיפה:

  1. להשתמש ב-Chrome מגרסה 101 ואילך.
  2. מפעילים את Privacy Sandbox API ואת Fenced Frame באמצעות chrome://flags/#privacy-sandbox-ads-apis ו-chrome://flags/#enable-fenced-frames. מידע נוסף זמין במאמר בדיקת ארגז החול לפרטיות.
  3. שולחים נכס קריאייטיב לאישור באמצעות Real-time Bidding API.
  4. משתמשים בדף המפרסם שסופק על ידי מגיש הצעת המחיר כדי להוסיף דפדפן לקבוצת העניין שבבעלות מגיש הצעת המחיר.

  5. כדי להפעיל מכרז של קהל מוגן, אפשר להשתמש בדף הבא של בעל תוכן דיגיטלי לבדיקה שסופק על ידי Google:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

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

  6. עליך לוודא את הפרטים הבאים:

    1. המערכת תציג את המודעה שצפויה לזכות במכרז.
    2. תוצאת המכרז נשלחת בצד השרת – כלומר, המציע הזוכה מקבל פינג חזרה מ-reportWin().
    3. במסוף של דף הבדיקה של בעל האתר מתועדת הודעת ניפוי באגים לכל הצעת מחיר, עם הפרטים הבאים:
      • ‫renderUrl: כתובת ה-URL של הצעת המחיר שמוצגת.
      • ‫interestGroupOwner: הבעלים של קבוצת נושאי העניין שהגיש את הצעת המחיר.
      • ‫accepted: הערך בשדה הזה הוא true אם הצעת המחיר התקבלה, ו-false אם הצעת המחיר נדחתה על ידי scoreAd().
      • ‫externalBidStatus: קוד סטטוס אם הצעת המחיר נדחתה בתוך scoreAd(). הערכים הם קודי סטטוס של קריאייטיב.

שלב 2: (אופציונלי) ניסוי שלא מוצג

אחרי ש-Google והשותף מאמתים באופן ידני שהשותף יכול להשתתף במכרז של Protected Audience, ‏ Google מאפשרת לשותף לעבור לשלב הבא של הבדיקה.

‫Google מקצה כמות קטנה של תנועה פעילה להפעלת מכרזי Protected Audience. לאחר מכן, Google והשותף לא צריכים יותר להפעיל ידנית מכרז של קהלים מוגנים. התוצאה של המכרז בשילוב עם Protected Audience API לא מוצגת. כך נוכל לבדוק את השילוב בהיקף גדול.

כשאתם מוכנים, אתם יכולים לפנות למנהל החשבון שלכם או לשלוח כרטיס תמיכה דרך מרכז העזרה של Authorized Buyer. ‫Google תפעיל את החשבון בשלב הזה.

שלב 3: ניסוי הרינדור

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

כשאתם מוכנים, אתם יכולים לפנות למנהל החשבון שלכם או לשלוח כרטיס תמיכה דרך מרכז העזרה של Authorized Buyer. ‫Google תפעיל את החשבון בשלב הזה.

תכונות נוספות

התכונות הבאות הן הרחבות של פרוטוקול הליבה.

טעינה במקביל

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

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

סיכום תהליך הצגת המודעות

סיכום של תהליך המכרז המקביל: תרשים זרימה

הזכאות של קונים להשתתף בקבוצות עניין במכשיר

במכרזים מקבילים, הקריאה של navigator.runAdAuction מתרחשת לפני שהתגובה של המודעה ההקשרית מוחזרת. כדי ליזום קריאות מהשרת שמהימנות הקונה נבדקת בהן, navigator.runAdAuction מחייב להעביר את הפרמטר interestGroupBuyers כערך, בעוד ששאר הפרמטרים של המכרז מקבלים הבטחות (Promises) של JavaScript שאפשר לפתור אחרי תגובת המודעה ההקשרית. מכיוון שהערך של הפרמטר interestGroupBuyers מועבר לפני התשובה לגבי המודעה הקונטקסטואלית, אי אפשר להשתמש בתשובה לגבי המודעה הקונטקסטואלית (כולל תשובות לבידינג) כדי לבחור אילו קונים ישתתפו במכרז המקביל לבקשה הנתונה. במקום זאת, תג Google Publisher Tag שומר במטמון, בדפדפן של המשתמש, את הפרמטר interestGroupBuyersnavigator.runAdAuction מהפעלות קודמות באותו דומיין.

יש כמה שיקולים חשובים לגבי מקביליות:

  1. אותות מכרז שלא נדרשים לבקשות של שרתים מהימנים של קונים, כמו perBuyerSignals, יכולים להמשיך להיות מוגדרים בתגובות לבידינג ב-RTB באותו אופן כמו במכרזים לא מקבילים. אחרי שההבטחות לאותות האלה יתממשו, שאר השלבים במכרז במכשיר יושלמו באותו אופן כמו בתהליך המכרז הלא מקבילי.

  2. מכיוון שהמקביליות מסתמכת על שמירת רשימת הקונים של קבוצת האינטרס במטמון, Google לא תמיד מריצה מכרז מקביל, כי יכול להיות שהמטמון של המקביליות ריק או שתוקף השמירה שלו פג. אם המטמון ריק או שתוקפו פג, Google מפעילה מכרז רגיל של Protected Audience API שלא פועל במקביל, ומשתמשת בכוונת הקנייה כדי להשתתף במכרז שלא פועל במקביל ולבנות את מטמון הקונים של קבוצת העניין.

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

    • פרוטוקול RTB של Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: ‏ BidRequest.imp.ext.interest_group_auction.parallelized

  4. לכל קונה רשום של קבוצת נושאים במכרז מקביל מסוים שנכלל במכרז המקביל תהיה רשומה תואמת של ParallelAuctionBuyer:

    • פרוטוקול RTB של Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: ‏ BidRequest.imp.ext.interest_group_auction.pbuyer

  5. אם מתבצע מכרז מקביל, אבל מקור קונה ספציפי לא מופיע במטמון, אי אפשר להוסיף את הקונה הזה למכרז הנוכחי במכשיר. הדבר מצוין בבקשה עם parallelized=True שחסר בה ערך ParallelAuctionBuyer עבור מקור קונה של קבוצת עניין מסוימת. עם זאת, אם המשתתפים בבידינג יציינו עניין על ידי הכללת InterestGroupBuyer(ים) תקפים שעומדים בדרישות בתגובה שלהם לבידינג, המקורות המתאימים של הקונים בקבוצת האינטרס יתווספו למטמון, והמקורות האלה יעמדו בדרישות לבקשות מקבילות עתידיות מאותו דפדפן ומאותו דומיין. אפשר לציין כוונה להשתתף במכרזים של קבוצות עם תחומי עניין בשדות הבאים:

    • פרוטוקול RTB של Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: ‏ BidResponse.ext.igbid.igbuyer

  6. מקורות קונים במטמון (שכלולים בפרמטר interestGroupBuyers של המכרז המקביל) שבהם המשתתף לא מציין כוונה להשתתף בתגובה להצעת המחיר, עשויים לקבל קריאה לשרת מהימן של הקונה, אבל לא ישתתפו במכרז המקביל.