דף זה תורגם על ידי Cloud Translation API.

Protected Audience API (לשעבר FLEDGE)

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

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

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

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

סיכום תהליך ההצגה

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

תרשים זרימה

מגיש הצעות מחיר עובד עם המפרסמים שלו כדי לתחזק קבוצות של תחומי עניין עבור כל מפרסם. לעיתים קרובות מפרסמים מוסיפים תג של מגיש הצעות מחיר של המפרסם כדי להוסיף דפדפן לקבוצות תחומי עניין.
משתמש קצה מבקר בדף של מפרסם. הדף עשוי להכיל את הפרטים של מגיש הצעות המחיר. התיוג.
התג של מגיש הצעות המחיר מפעיל את Protected Audience API joinAdInterestGroup(). הקריאה הזו מבקשת מהדפדפן להוסיף את המשתמש לקבוצה של תחומי עניין.
משתמש הקצה מבקר בדף אינטרנט של בעל תוכן דיגיטלי. בקשות הדפדפן של המשתמש תג המודעה של Google לבעלי תוכן דיגיטלי.
תג המודעה של Google לבעלי תוכן דיגיטלי שולח בקשת מודעה לפי הקשר לשרת של Google.
Google שולחת בקשות להצעות מחיר לפי הקשר אל מגישי הצעות המחיר שמשתתפים בתוכנית. לצפייה הקטע 'שינויים בבקשות להצעות מחיר'.
מגיש הצעות המחיר מחזיר BidResponse עם השדה interest_group_bidding. אם מגיש הצעות המחיר לא מציין את הערך interest_group_bidding, Google לא לכלול את מקור מגיש הצעות המחיר בinterestGroupBuyers במכרז הגדרות אישיות. התגובה של הצעת המחיר יכולה להכיל גםinterest_group_bidding.per_buyer_signals. per_buyer_signals יועבר לפונקציית הבידינג של מגיש הצעות המחיר במהלך למכירה פומבית בדפדפן. הצגת שינויים בתגובה להצעות מחיר למידע נוסף.
Google מפעילה את המכרז בצד השרת ומחזירה תגובה להצעת מחיר אל בדפדפן. המכרז בצד השרת מתייחס להצעות מחיר מסורתיות בצד השרת. התגובה להצעת מחיר יכולה להכיל מידע על הצעת המחיר הזוכה לפי הקשר (אם כלשהו).
תגובת הצעת המחיר מכילה הגדרת מכרז עבור הדפדפן במכרז. המידע הזה יכול לכלול אותות לפי הקשר מכל קונה משתתף (שנשלחו דרך interest_group_bidding.per_buyer_signals), מידע על מנצח לפי הקשר והגדרות לכשירות של הצעת מחיר.
תג בעל התוכן הדיגיטלי של Google מפעיל את Protected Audience API runAdAuction() כדי ליזום מכרז של קבוצת תחומי עניין במכשיר. Google כוללת רק קונים שהחזירו בעבר את interest_group_bidding בתור interestGroupBuyers בהגדרת המכרז.
Google מעבירה את per_buyer_signals של כל מגיש הצעות מחיר שעומד בדרישות אל Protected הגדרת מכרז הקהל.
אם קבוצות האינטרס של מגיש הצעות מחיר נתון ציינו את trustedBiddingSignalsUrl, הדפדפן שולח בקשה לכל קבוצה trustedBiddingSignalsUrl כדי לאחזר אותות בזמן אמת לכל קבוצה. צפייה פרטים ב-Protected Audience API .
הדפדפן מפעיל את generateBid() של מגיש הצעות המחיר לכל קבוצה של תחומי עניין שהסכימו להשתתף במכרז, ושהם כשירים להשתתף בו. הזה מחשב את הצעת המחיר ובוחר קריאייטיב. ל-generateBid() יש גישה אל per_buyer_signals שסופקו על ידי מגיש הצעות המחיר ושיטת הבידינג המהימנה אותות לקבוצת האינטרס הנתונה.
הדפדפן מפעיל את חשבון המפיץ (במקרה הזה, של Google) scoreAd() אל להקצות דירוג לכל הצעת מחיר במכרז המודעות של קבוצת תחומי עניין. הצעות המחיר מדורגות ומסוננים על סמך אמצעי הגנה על בעלי תוכן דיגיטלי, מדיניות מודעות ועוד מגבלות בפועל.
הדפדפן מפעיל מכרז עם הצעות המחיר לקבוצות של תחומי עניין שעומדות בדרישות. הצעת המחיר לפי הקשר המדורגת בדירוג הגבוה ביותר משתתפת במכרז שמוצג בדפדפן.
לאחר המכרז, אם יש מנצחת של קבוצת תחומי עניין, הדפדפן יופעל reportResult() של בית העסק ושל מגיש הצעות המחיר reportWin() כדי להודיע לכל אחד מהם על הזוכה במכרז שמוצג בדפדפן.
אם מודעה בקבוצת תחומי עניין מצליחה, תג בעל האתר של Google מעבד את המודעה iframe.

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

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

ביקורת על קריאייטיב

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

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

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

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

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

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

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

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

מכרז בצד השרת

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

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

קישור מוקדם בפרוטוקול RTB של Google
קישור מוקדם של OpenRTB

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

בבקשות להצעת מחיר יש שדה חדש, auction_environment.

פרוטוקול RTB של Google: BidRequest.adslot.auction_environment
OpenRTB: BidRequest.imp.ext.auction_environment

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

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

ציון גודל מיקום המודעה של 'קהל מוגן'

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

פרוטוקול RTB של Google:
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
OpenRTB:
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.interest_group_auction.height

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

הגודל הזה יכול להיות שונה מהגדלים של הבקשה לפי הקשר (Adslot.widthו-Adslot.height, או ב-OpenRTB: BidRequest.imp.banner.format).

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

ציון יכולת רינדור המודעות של Protected Audience API

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

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

צמצום ההסתמכות על מזהי משתמשים

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

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

בדיקות הוצאה משימוש של קובצי cookie של צד שלישי בסיוע Chrome

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

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

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

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

פרוטוקול RTB של Google: BidRequest.device.cookie_deprecation_label
OpenRTB: BidRequest.device.ext.cdep

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

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

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

פרוטוקול RTB של Google: BidResponse.interest_group_bidding
OpenRTB: BidResponse.ext.igbid

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

הפצת אותות לפי הקשר של הקונה (perBuyerSignals)

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

RTB ב-Google: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

הפצת אותות רינדור לפי הקשר של הקונה

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

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

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

RTB ב-Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

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

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

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

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

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

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

פרוטוקול RTB של Google: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (מבוטאת במיקרו עלות לאלף חשיפות)
OpenRTB: BidResponse.igbid.igbuyer.maxbid(מבוטא ביחידות מטבע של עלות לאלף חשיפות)

שיוך חשיפות למספר חשבונות

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

פרוטוקול RTB של Google: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
OpenRTB: BidResponse.igbid.igbuyer.billing_id

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

פרוטוקול RTB של Google: BidRequest.adslot.matching_ad_data.billing_id
OpenRTB: BidRequest.imp.ext.billing_id

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

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

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

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

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

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

יש להשתמש בכלי 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};
}

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

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

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

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

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

לדוגמה:

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

בפרוטוקול RTB של Google, משתמשים בשדה 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.dsa.dsa_support ו-BidRequest.dsa.publisher_rendering_support לפרוטוקול Google Authorized Buyers ול-BidRequest.regs.dsa.required ו-BidRequest.dsa.pubrender לפרוטוקול OpenRTB.

כשמגיש הצעות מחיר רוצה להשתתף במכרזי Protected Audience API מקבל אות בבקשה להצעת מחיר שלפיו יש להציג מודעות שקיפות בהתאם ל-DSA מודעות שמוצגות דרך Protected Audience API, צריך לבדוק אם הם יכולים להציג כראוי את המידע הנדרש ולציין באמצעות הגדרה BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render לפרוטוקול Google Authorized Buyers או BidResponse.ext.igbid.igbuyer.dsaadrenderלפרוטוקול OpenRTB. אחרת, הקונה לא ייכלל במכרז של 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 שרשום ברשימת הספקים הגלובלית של IAB ספק. אם מחרוזת נתוני השקיפות וההסכמה ריקה או לא חוקית, המאקרו לא יורחב. קריאייטיבים עם המאקרו `${GDPR_CONSENT_XXXX}` יכולים להפוך המערכת תיחסם אם הספק שרשום ברשימת הספקים הגלובלית של 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 API מכירות פומביות בדפדפן עשויות להיות שונות מהאירוע שמשמש לספירה חשיפות אצל שותפי הקונה ב-RTB, מספרי החשיפות עשויים להיות שונים.

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

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

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

תקרת תקציב יומי

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

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

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

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

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

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

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

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

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

%%GOOGLE_QUERY_ID%%: המאקרו הזה מוחלף במזהה השאילתה של Google (BidRequest.google_query_id בפרוטוקול Authorized Buyers, ובנוסף BidRequest.ext.google_query_id בפרוטוקול OpenRTB) שנשלח באמצעות בקשה להצעת מחיר לפי הקשר ב-Protected Audience API.
%%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:

שלבים

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

ביקורת קריאייטיב

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

צריך לכלול את פרמטר השאילתה &pltd=True ב-renderUrl בשביל המאגר של מודעת הרכיב (נקרא גם renderUrl ברמה העליונה) כדי להבדיל בין renderUrls ברמה עליונה במהלך בדיקת הקריאייטיב.
עיבוד קריאייטיב מייצג כאשר המאגר של מודעת הרכיב אוחזרו לצורך בדיקת קריאייטיב ש-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 כדי לוודא שהמודעה ומתעדים את החשיפה:

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

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

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

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

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

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

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

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

מקביל

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

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

סיכום תהליך ההצגה

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

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

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

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

אותות ממכרזים שלא נחוצים לבקשות שרת מהימנים של קונים כמו perBuyerSignals, אפשר להמשיך לציין אותן בתגובות להצעת מחיר ב-RTB בדיוק כמו במכרזים לא מקבילים. אחרי שההבטחות לגבי האותות האלה ייפתרו, שאר השלבים של המכרז במכשיר יסתיים באותו אופן כמו תהליך המכרז.
מכיוון שהטעינה המקבילה מסתמכת על שמירה במטמון של רשימת הקונים של קבוצות תחומי העניין, Google לא תמיד מפעילה מכרז מקביל, כי המטמון של ההמרות המקבילות ריקה או שהתוקף שלה פג. אם המטמון ריק או שהתוקף שלו פג, Google מפעילה מכרז רגיל ולא מקביל של Protected Audience API ומשתמש בכוונת הקונה כדי להשתתף במכרז הלא מקביל כדי לבנות את מטמון הקונים של קבוצות תחומי העניין.
אם לפחות קונה אחד של מגיש הצעות מחיר נשמר במטמון של בעל האפליקציה הנוכחי. Google תרוץ במקביל במכרז, שיציין בבקשה להצעת מחיר:
- פרוטוקול RTB של Google: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
כל מקור קונה רשום של קבוצת אינטרס של מגיש הצעות מחיר נתון שהיה שכלולים במכרז המקביל, יקבלו ערך ParallelAuctionBuyer:
- פרוטוקול RTB של Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
אם מופעל מכרז מקביל, אבל לא קיים מקור קונה ספציפי המטמון, אז אותו קונה לא יכול להתווסף לקובץ הנוכחי במכשיר במכרז. מצב זה מצוין על ידי בקשה עם parallelized=True שלא כוללת רשומת ParallelAuctionBuyer עבור מקור קונה נתון של קבוצת תחומי עניין. עם זאת, מגישי הצעות מחיר שמציינים את רמת העניין שלהם על ידי הכללת ערכים תקינים וכשירים InterestGroupBuyer בתגובה להצעת המחיר יכלול את הקונה התואם של קבוצת תחומי העניין מקורות שיתווספו למטמון, ומקורות אלה יהיו כשירים להופיע בקשות עתידיות מאותו דפדפן ומאותו דומיין. כוונה להשתתף במכרזים של קבוצות תחומי עניין ניתן לציין בשדות הבאים:
- פרוטוקול RTB של Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
מקורות קונים שמורים במטמון (הנכללים בתהליך המכרז המקביל interestGroupBuyers) שעבורו מגיש הצעות המחיר לא מציין כוונה להשתתף בתגובה להצעת מחיר, עשויים לקבל קריאת שרת מהימנות של קונה אבל לא ישתתפו במכרז המקביל.