Protected Audience API (לשעבר FLEDGE)

כחלק מארגז החול לפרטיות, דפדפן Chrome הציע את Protected Audience 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:

תרשים זרימה

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

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

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

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

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

דרישות עבור renderUrls:

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

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

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

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

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

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

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

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

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

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

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

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

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

מכרז בצד השרת

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

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

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

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

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

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

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

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

  • פרוטוקול Google RTB:
    • 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.

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

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

ציון יכולת העיבוד של מודעות מסוג 'קהל מוגן'

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

  • פרוטוקול Google RTB: 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 של צד שלישי (3PCD) בשנת 2024, Chrome מציע עכשיו בדיקות שמתבצעת באמצעות Chrome.

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

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

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

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

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

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

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

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

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

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

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

  • הצעת מחיר בזמן אמת של Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
ציון מחיר מקסימלי של הצעת מחיר בדפדפן

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

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

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

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

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

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

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

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

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

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

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

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

במהלך מכירה פומבית בדפדפן

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

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

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

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

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

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

לדוגמה:

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

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

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

הצעות מחיר במכרזים בתוך הדפדפן ממוקמות ביחידות של עלות לאלף חשיפות (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 (חוק השירותים הדיגיטליים), בעלי תוכן דיגיטלי יכולים לדרוש מהקונים להציג גילוי נאות לגבי שקיפות במודעות. כשבעלי התוכן הדיגיטלי מפעילים את ההגדרה "שליחת בקשה לקונים להציג מודעות עם מידע שקיפות של DSA באתר או באפליקציה שלי באזור הכלכלי האירופי בלבד", הקונים בקבוצות תחומי עניין יכולים לקבוע מהן ההזדמנויות שלהם כדי לספק שקיפות לקונים. לשם כך, הם מציינים את השדות הבאים בבקשות להצעות מחיר שהתקבלו: BidRequest.dsa.dsa_support ו-BidRequest.dsa.publisher_rendering_support לפרוטוקול Google Authorized Buyers, ו-BidRequest.regs.dsa.required ו-BidRequest.dsa.pubrender לפרוטוקול OpenRTB.

כשמגיש הצעות מחיר שרוצה להשתתף במכרזים של Protected Audience API מקבל בבקשה להצעת מחיר את האות לכך שצריך להציג את השקיפות של מודעות דינמיות לרשת החיפוש במודעות שמוצגות דרך 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} הרחבת העמודה Transparency & Consent (TC) (מחרוזת השקיפות וההסכמה) שמשויכת לבקשה. אם מחרוזת השקיפות וההסכמה (TC) ריקה או לא תקינה, המאקרו הזה לא מתרחב.

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

ספירת חשיפות

במהלך הבדיקה של 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 API.

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

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

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

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

שמות השדות הספציפיים מופיעים במסמכי התיעוד בנושא Authorized Buyers RTB ותוספי OpenRTB.

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

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

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

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

אירועי קליק

מגישי הצעות מחיר יכולים לדווח ל-Google על אירועי קליקים על מודעות Protected Audience API באמצעות Fenced Frame Reporting API. מגישי הצעות המחיר צריכים להשתמש בסוג האירוע click כדי להודיע ל-Google על קליקים. לדוגמה:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE ברמת המוצר

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

תהליך קליטת שותף

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

שלבים

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

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

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

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

רשימת משימות להטמעה

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

שלבי הבדיקה

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

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

  1. השתמשו ב-Chrome מגרסה 101 ואילך.
  2. מפעילים את ה-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 באופן ידני. התוצאה של המכרז 'Protected Audience' לא מעובדת. כך אנחנו יכולים לבדוק את השילוב בקנה מידה נרחב.

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

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

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

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