Protected Audience API (לשעבר FLEDGE)

כחלק מארגז החול לפרטיות, Chrome הציע את קהל מוגן 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, ובשדה שהוצאה משימוש פרוטוקול RTB של Google שמצוין בו BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals השדה הזה. אפשר לעיין בקטע שינויים בתגובה להצעות מחיר כדי לקבל מידע נוסף. מידע נוסף.
  8. Google מפעילה את המכרז בצד השרת ומחזירה תגובה להצעת מחיר בדפדפן. המכרז בצד השרת מתייחס להצעות מחיר מסורתיות בצד השרת. תגובת הצעת המחיר עשויה לכלול מידע על הצעת המחיר הזוכה לפי הקשר (אם יש כזו).
  9. תגובת הצעת המחיר מכילה הגדרת מכרז למכרז בדפדפן. המידע הזה יכול לכלול אותות לפי הקשר מכל קונה משתתף (שנשלחו דרך buyerdata של OpenRTB או דרך RTB של Google שהוצאה משימוש את ה-per_buyer_signals של הפרוטוקול מוקדם יותר), נתוני מנצחת לפי הקשר, וגם הגדרות ההתאמה של הצעת המחיר.
  10. תג בעל התוכן הדיגיטלי של Google מפעיל את Protected Audience API‏ runAdAuction() כדי להתחיל את המכרז של קבוצות האינטרס במכשיר. Google כוללת רק קונים שצוינו כ-InterestGroupBuyer ב-InterestGroupBidding במהלך הגדרת המכרז.
  11. Google מעבירה את האותות האופציונליים הספציפיים לקונה של כל מגיש הצעות מחיר שעומד בדרישות אל הגדרת המכרז של Protected Audience API.
  12. אם קבוצות האינטרס של מגיש הצעות מחיר נתון ציינו את trustedBiddingSignalsUrl, הדפדפן שולח בקשה לכל קבוצה trustedBiddingSignalsUrl כדי לאחזר אותות בזמן אמת לכל קבוצה. צפייה פרטים ב-Protected Audience API .
  13. הדפדפן מפעיל את generateBid() של המגיש עבור כל קבוצת תחומי עניין שהביעה הסכמה ועומדת בדרישות להשתתפות במכרז בדפדפן. בשלב הזה מחושב הצעת המחיר ובוחרים קריאייטיב. ל-generateBid() יש גישה לאותות האופציונליים של הקונה שסופקו על ידי מגיש הצעות המחיר, ולאותות הבידינג המהימנים של קבוצת האינטרסים הנתונה.
  14. הדפדפן מפעיל את חשבון המפיץ (במקרה הזה, של Google) scoreAd() אל להקצות דירוג לכל הצעת מחיר במכרז המודעות של קבוצת תחומי עניין. הצעות המחיר מדורגות ומסוננות על סמך אמצעי ההגנה של בעלי התוכן הדיגיטלי, מדיניות הפרסום והגבלות אחרות.
  15. הדפדפן יפעיל מכרז עם הצעות המחיר לקבוצות של תחומי עניין שעומדות בדרישות. הצעת המחיר לפי הקשר המדורגת בדירוג הגבוה ביותר משתתפת במכרז שמוצג בדפדפן.
  16. אחרי המכרז, אם יש זוכה בקבוצת תחומי העניין, הדפדפן מפעיל את reportResult() של המוכר ואת reportWin() של המגיש כדי להודיע לכל צד על הזוכה במכרז בדפדפן.
  17. אם מודעה בקבוצת תחומי עניין מצליחה, תג בעל האתר של Google מעבד את המודעה iframe.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Authorized-Buyers-Creative-ID

    string

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

    string

    הקבוצה של כתובות היעד המוצהרות עבור הקריאייטיב שמקודד בהתאם ל-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 API.

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

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

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

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

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

  • 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 API בפיקסלים.

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

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

סימון היכולת להציג מודעות לקהלים מוגנים

ייתכן שמודעות של 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
  • RTB של Google (הוצא משימוש): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

קונה של קבוצת האינטרס תידחה ולא תשתתף בתוכנית Protected מכרז של קהלים, אם האותות לא מתאימים לכתובות 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 (במיקרו-CPM)
שיוך חשיפות לכמה חשבונות

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

  • 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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה:

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

הסבר על הפונקציה generateBid() זמין בקטע בידינג במכשיר במפרט של 'קהל מוגן'.

המטבע של הצעת המחיר

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

יש לציין את מטבע הצעת המחיר גם בתגובת הצעת המחיר לפי הקשר וגם הערך המוחזר של 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 (חוק השירותים הדיגיטליים)

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

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

מידע נוסף על שקיפות הפרסום בכפוף ל-Digital Services Act זמין במאמר הזה במרכז העזרה: תמיכה ב-Digital Services Act.

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

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

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

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

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

  • auctionSignals
  • sellerSignals

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

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

פקודות מאקרו

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

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

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

נכסי קריאייטיב עם המאקרו ${GDPR_CONSENT_XXXX} עשויים להיחסם אם לספק שרשום ברשימת הספקים הגלובליים של IAB שמשויך למזהה הספק ברשימת הספקים הגלובליים של 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 API. תקרת התקציב היומי מגבילה את הסיכון בסביבת המכרז בתוך הדפדפן. אחרי שמגיעים למגבלת התקציב היומית, החשבון לא מקבל יותר בקשות להצעות מחיר שעומדות בדרישות של 'קהל מוגן'.

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

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

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

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

אפשר לקרוא את מסמכי התיעוד של הפרוטוקול עבור בידינג בזמן אמת (RTB) של Authorized Buyers ותוספי OpenRTB לשמות השדות הספציפיים.

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

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

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

  • %%GOOGLE_QUERY_ID%%: המאקרו הזה מוחלף במזהה השאילתה של Google שנשלח בבקשה להצעת מחיר לפי הקשר עם התכונה 'קהל מוגן'. בפרוטוקול OpenRTB הדבר מצוין באמצעות BidRequest.ext.google_query_id, ואילו בפרוטוקול Google RTB שהוצא משימוש נעשה שימוש ב-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%%

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

TURTLEDOVE ברמת המוצר

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

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

כך בודקים את Protected Audience API:

שלבים

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

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

כדי להגיש הצעות מחיר עם מודעות ברמת המוצר (מודעות שמורכבות מכמה חלקים) במכרזים של 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 בדיקה.
  • יש לשלוח קריאייטיבים לבדיקה ולאישור דרך נכסי קריאייטיב API.
  • (אופציונלי) מגדירים את נקודות הקצה של אותות הבידינג המהימנים.
  • (אופציונלי) מגדירים דף מפרסם לבדיקה שמאפשר למהנדסים של Google להוסיף בדפדפן שלהם לקבוצות האינטרס בבעלות הקונה של קבוצת תחומי העניין המקור. כך אנחנו יכולים להפעיל באופן ידני מכרזים של Protected Audience.
  • (אופציונלי) מפעילים משוב בזמן אמת על החשבון כדי לקבל משוב קונים של קבוצות אינטרס שביקשו להיכלל ב-Protected Audience במכרז.
  • (אופציונלי) אפשר לפנות למנהל החשבון כדי להגדיר כתובת URL סטטית לקבל התראה משרת לשרת שמספקת הצעת מחיר מסוג Protected Audience משוב לגבי הסטטוס של הצעת מחיר מקהל מוגן במכשיר במכרז כדי לעזור בניפוי באגים בבעיות בלתי צפויות. ראה משוב על הצעות מחיר למידע נוסף.

שלבי הבדיקה

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

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

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

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

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

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

  6. מוודאים את הפרטים הבאים:

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

שלב 2: (אופציונלי) ניסוי ללא רינדור

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

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

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

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

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

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

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

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

טעינה במקביל

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

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

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

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

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

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

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

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

  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 של המכרז המקביל) שלגביהם המגיש הצעת המחיר לא מציין כוונה להשתתף בתגובה להצעת המחיר, עשויים לקבל קריאה לשרת מהימן של קונה, אבל לא ישתתפו במכרז המקביל.