מדריך FLEDGE API למפתחים

למי המאמר הזה מיועד?

הפוסט הזה הוא מסמך עזרה טכני לגרסה הנוכחית של Protected Audience API הניסיוני.

מהו Protected Audience?

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

Protected Audience הוא הניסוי הראשון שייושם ב-Chromium מתוך משפחת ההצעות של TURTLEDOVE.

בתרשים הבא מוצגת סקירה כללית של מחזור החיים של FLEDGE:

איור שמספק סקירה כללית של כל שלב במחזור החיים של FLEDGE
מחזור החיים של FLEDGE.

איך אפשר לנסות את Protected Audience?

הדגמה של Protected Audience

הדרכה מפורטת על פריסה בסיסית של 'קהלים מוגנים' באתרים של מפרסמים ובאתרים של בעלי תוכן דיגיטלי זמינה בכתובת protected-audience-demo.web.app.

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

השתתפות בגרסת המקור לניסיון של Protected Audience

גרסת המקור לניסיון של ארגז החול לפרטיות למדידה ורלוונטיות זמינה ב-Chrome Beta בגרסה 101.0.4951.26 ואילך במחשב, עבור ממשקי ה-API Protected Audience‏, Topics ו-Attribution Reporting.

כדי להשתתף, צריך להירשם לאסימון לניסיון במקור.

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

הדגמה של Protected Audience מספקת דוגמה בסיסית לפריסה מקצה לקצה של Protected Audience.

מספקים אסימון ניסיון לכל דף שבו רוצים להריץ קוד של Protected Audience API:

  • כמטא תג ב-<head>:

    <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">

  • ככותרת HTTP:

    Origin-Trial: TOKEN_GOES_HERE

  • על ידי מתן טוקן באופן פרוגרמטי:

    const otMeta = document.createElement('meta');
otMeta.httpEquiv = 'origin-trial';
otMeta.content = 'TOKEN_GOES_HERE';
document.head.append(otMeta);

iframe שבו פועל קוד של Protected Audience API – למשל קריאה ל-navigator.joinAdInterestGroup() על ידי הבעלים של קבוצת האינטרס – יצטרך לספק אסימון שתואם למקור שלו.

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

בדיקת ה-API

אפשר לבדוק את Protected Audience למשתמש יחיד בגרסה 101.0.4951.26 ואילך של Chrome Beta במחשב:

  • על ידי הפעלת כל ממשקי ה-API לשמירה על הפרטיות בקטע chrome://settings/adPrivacy
  • על ידי הגדרת דגלים משורת הפקודה.

עיבוד מודעות ב-iframe או במסגרות בלי שיתוף נתונים

המודעות יכולות להיות מוצגות ב-<iframe> או ב-<fencedframe>, בהתאם לדגלים שהוגדרו.

כדי להשתמש ב-<fencedframe> לצורך עיבוד מודעות:

--enable-features=InterestGroupStorage,AdInterestGroupAPI,Fledge,FencedFrames

כדי להשתמש ב-<iframe> לצורך עיבוד מודעות:

--enable-features=InterestGroupStorage,AdInterestGroupAPI,Fledge,AllowURNsInIframes --disable-features=FencedFrames

מוסיפים את הדגל BiddingAndScoringDebugReportingAPI כדי להפעיל את שיטות הדיווח הזמניות על הפסדים/ניצחונות בניפוי הבאגים.

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

אילו תכונות נתמכות בגרסה האחרונה של Chrome?

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

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

במאמר ההסבר על ה-API מפורט מידע נוסף על התמיכה בתכונות ועל האילוצים.

הרשאות בקבוצות אינטרס

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

שירות Key/Value

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

קוד השירות של מפתח/ערך של קהל מוגן זמין עכשיו במאגר של ארגז החול לפרטיות ב-GitHub. מפתחים של Chrome ו-Android יכולים להשתמש בשירות הזה. בפוסט הזה בבלוג אפשר לקרוא את עדכון הסטטוס. מידע נוסף על השירות 'מפתח/ערך של קהל מוגן' זמין במאמר ההסבר על ה-API ובמאמר ההסבר על מודל האמון.

בבדיקה הראשונית נעשה שימוש במודל Bring Your Own Server (BYOS). בטווח הארוך, חברות טכנולוגיות פרסום יצטרכו להשתמש בשירותי מפתח/ערך של Protected Audience בקוד פתוח שפועלים בסביבות מחשוב מהימנות כדי לאחזר נתונים בזמן אמת.

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

זיהוי תמיכה בתכונות

לפני שמשתמשים ב-API, צריך לבדוק אם הדפדפן תומך בו והאם הוא זמין במסמך:

'joinAdInterestGroup' in navigator &&
  document.featurePolicy.allowsFeature('join-ad-interest-group') &&
  document.featurePolicy.allowsFeature('run-ad-auction') ?
  console.log('navigator.joinAdInterestGroup() is supported on this page') :
  console.log('navigator.joinAdInterestGroup() is not supported on this page');

איך אפשר לבטל את ההשתתפות ב-Protected Audience API?

בעלי אתרים או משתמשים פרטיים יכולים לחסום את הגישה ל-Protected Audience API.

איך אתרים יכולים לשלוט בגישה?

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

יש שני כללי מדיניות של הרשאות Protected Audience שאפשר להגדיר בנפרד:

  • join-ad-interest-group מפעיל/השבית את הפונקציונליות של הוספת דפדפן לקבוצות אינטרס
  • run-ad-auction מפעיל/השבית את הפונקציונליות להפעלת מכרז במכשיר

כדי להשבית לחלוטין את הגישה לממשקי Protected Audience API בהקשרים של צד ראשון, צריך לציין את מדיניות ההרשאות הבאה בכותרת התגובה של ה-HTTP:

Permissions-Policy: join-ad-interest-group=(), run-ad-auction=()

כדי להשבית את השימוש בממשקי ה-API ב-iframe, מוסיפים את המאפיין allow הבא לרכיב iframe:

<iframe src="https://example.com" allow="join-ad-interest-group 'none'; run-ad-auction 'none'"></iframe>

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

סירוב מצד המשתמש

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

  • משביתים את התכונות הניסיוניות של ארגז החול לפרטיות בהגדרות של Chrome: הגדרות > אבטחה ופרטיות > ארגז חול לפרטיות. אפשר גם לגשת אליו בכתובת chrome://settings/adPrivacy.
  • משביתים קובצי Cookie של צד שלישי בהגדרות של Chrome: הגדרות > אבטחה ופרטיות.
  • מגדירים את האפשרות קובצי cookie ונתונים אחרים מאתרים ל'חסימת קובצי cookie של צד שלישי' או ל'חסימת כל קובצי ה-cookie' מ-chrome://settings/cookies.
  • להשתמש במצב פרטי.

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

ניפוי באגים ב-worklets של Protected Audience

החל מגרסה 98.0.4718.0 של Chrome Canary, אפשר לנפות באגים ב-worklets של Protected Audience ב-Chrome DevTools.

השלב הראשון הוא להגדיר נקודות עצירה באמצעות קטגוריה חדשה בחלונית Event Listener Breakpoints בחלונית Sources.

צילום מסך של DevTools ב-Chrome Canary, שבו מודגשת חלונית נקודות העצירה של Event Listener בחלונית Sources. האפשרות &#39;תחילת שלב הגשת הצעות המחיר של מגיש הצעות המחיר&#39; נבחרת בקטע &#39;מכרז של מודעות Worklet&#39;.

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

סקריפטים של ווירטואליות פונקציונלית שפועלים יופיעו גם בחלונית 'שרשראות'.

צילום מסך של DevTools ב-Chrome Canary, שבו מודגשת חלונית השרשור בחלונית המקורות, שמוצג בה סקריפט ה-worklet הנוכחי שהושהה.

מאחר שחלק מה-worklets עשויים לפעול במקביל, יכול להיות שחלק מהשרשראות יהיו במצב 'מושהות'. תוכלו להשתמש ברשימת השרשאות כדי לעבור בין השרשאות, ולהמשיך אותן או לבדוק אותן לעומק לפי הצורך.

מעקב אחרי אירועים של Protected Audience

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

אם נכנסים לאתר הדגמה של שופינג עם Protected Audience בדפדפן שבו Protected Audience מופעל, ב-DevTools יוצג מידע על האירוע join.

חלונית האפליקציה של DevTools ב-Chrome Canary, שבה מוצג מידע על אירוע הצטרפות לקבוצת תחומי עניין של Protected Audience.

עכשיו, אם נכנסים לאתר הדגמה של Protected Audience לבעלי תוכן דיגיטלי בדפדפן שבו Protected Audience מופעל, ב-DevTools מוצג מידע על האירועים bid ו-win.

חלונית האפליקציה של DevTools ב-Chrome Canary, שבה מוצג מידע על הצעות מחיר ואירועי זכייה במכרזים של Protected Audience.

איך עובד Protected Audience API

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

1. משתמש מבקר באתר של מפרסם

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

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

2. הדפדפן של המשתמש מתבקש להוסיף קבוצת תחומי עניין

איור שבו מוצג אדם שצופה באתר בדפדפן במחשב הנייד שלו. קוד ה-JavaScript joinAdInterestGroup()‎ פועל בדפדפן.

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

הפלטפורמה למפרסמים (DSP) (או המפרסם עצמו) מבצעת קריאה ל-navigator.joinAdInterestGroup() כדי לבקש מהדפדפן להוסיף קבוצת תחומי עניין לרשימת הקבוצות שהדפדפן חבר בהן. בדוגמה הזו, השם של הקבוצה הוא custom-bikes והבעלים הוא dsp.example. הבעלים של קבוצת האינטרסים (במקרה הזה, פלטפורמת ה-DSP) יהיה קונה במכרז המודעות שמתואר בשלב 4. אם המשתמש חבר בקבוצת אינטרס, הפרט הזה שמור בדפדפן שמותקן במכשיר שלו, ולא משותף עם הספק של הדפדפן או כל גורם אחר.

כדי להשתמש ב-joinAdInterestGroup() נדרשת הרשאה מהגורמים הבאים:

  • האתר שבו מתבצע הביקור
  • הבעלים של קבוצת האינטרסים

לדוגמה: אסור ש-malicious.example יוכל לקרוא ל-joinAdInterestGroup() עם dsp.example כבעלים בלי רשות של dsp.example.

הרשאה מהאתר שבו מבקרים

מאותו מקור: כברירת מחדל, המערכת מעניקה הרשאה מרומזת לשיחות joinAdInterestGroup() מאותו מקור כמו האתר שבו מבקרים, כלומר מאותו מקור כמו המסגרת ברמה העליונה של הדף הנוכחי. אתרים יכולים להשתמש בהוראה join-ad-interest-group של כותרת מדיניות ההרשאות של Protected Audience כדי להשבית את הקריאות ל-joinAdInterestGroup().

ממקורות שונים: קריאה ל-joinAdInterestGroup() ממקורות שונים מהדף הנוכחי יכולה להצליח רק אם באתר שבו מבקרים מוגדרת מדיניות הרשאות שמאפשרת קריאות ל-joinAdInterestGroup() מ-iframe ממקורות שונים.

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

הרשאת הבעלים של קבוצת העניין ניתנת באופן משתמע על ידי קריאה ל-joinAdInterestGroup() מ-iframe עם אותו מקור כמו זה של הבעלים של קבוצת העניין. לדוגמה, iframe של dsp.example יכול להפעיל את joinAdInterestGroup() עבור קבוצות של תחומי עניין שבבעלות dsp.example.

ההצעה היא ש-joinAdInterestGroup() יוכל לפעול בדף או ב-iframe בדומיין של הבעלים, או להעביר גישה לדומיינים אחרים באמצעות רשימה בכתובת ה-URL .well-known.

שימוש ב-navigator.joinAdInterestGroup()‎

דוגמה לשימוש ב-API:

const interestGroup = {
  owner: 'https://dsp.example',
  name: 'custom-bikes',
  biddingLogicUrl: ...,
  biddingWasmHelperUrl: ...,
  dailyUpdateUrl: ...,
  trustedBiddingSignalsUrl: ...,
  trustedBiddingSignalsKeys: ['key1', 'key2'],
  userBiddingSignals: {...},
  ads: [bikeAd1, bikeAd2, bikeAd3],
  adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};

navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);

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

מאפייני קבוצות אינטרס

נכס חובה דוגמה תפקיד
owner חובה 'https://dsp.example' המקור של הבעלים של קבוצת האינטרסים.
name חובה 'custom-bikes' השם של קבוצת העניין.
biddingLogicUrl** אופציונלי* 'https://dsp.example/bid/custom-bikes/bid.js' כתובת ה-URL של קובץ ה-JavaScript לבידינג שפועל ב-worklet.
biddingWasmHelperUrl** אופציונלי* 'https://dsp.example/bid/custom-bikes/bid.wasm' כתובת ה-URL של קוד WebAssembly שמופעל מ-biddingLogicUrl.
dailyUpdateUrl** אופציונלי 'https://dsp.example/bid/custom-bikes/update' כתובת URL שמחזירה JSON לעדכון המאפיינים של קבוצות העניין. (לעדכון קבוצת האינטרסים)
trustedBiddingSignalsUrl** אופציונלי 'https://dsp.example/trusted/bidding-signals' כתובת ה-URL הבסיסית לבקשות של מפתח/ערך לשרת המהימן של המגיש.
trustedBiddingSignalsKeys אופציונלי ['key1', 'key2' ...] מפתחות לבקשות לשרת מהימן של מפתח/ערך.
userBiddingSignals אופציונלי {...} מטא-נתונים נוספים שהבעלים יכול להשתמש בהם במהלך הבידינג.
ads אופציונלי* [bikeAd1, bikeAd2, bikeAd3] מודעות שעשויות להופיע לקבוצת האינטרסים הזו.
adComponents אופציונלי [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2] רכיבים למודעות שמכילות כמה חלקים.

* כל המאפיינים הם אופציונליים, מלבד owner ו-name. המאפיינים biddingLogicUrl ו-ads הם אופציונליים, אבל נדרשים כדי להשתתף במכרז. יכול להיות שיהיו תרחישים לדוגמה שבהם כדאי ליצור קבוצת תחומי עניין בלי המאפיינים האלה: לדוגמה, יכול להיות שבעל קבוצת תחומי עניין ירצה להוסיף דפדפן לקבוצת תחומי עניין לקמפיין שעדיין לא פועל, או לשימוש עתידי אחר, או שהוא נגמר לו זמנית תקציב הפרסום.

** כתובות ה-URL biddingLogicUrl, ‏ biddingWasmHelperUrl, ‏ dailyUpdateUrl ו-trustedBiddingSignalsUrl חייבות להיות מאותו מקור כמו הבעלים. אין אילוץ כזה על כתובות ה-URL ads ו-adComponents.

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

dailyUpdateUrl מציין שרת אינטרנט שמחזיר JSON שמגדיר את המאפיינים של קבוצת העניין, בהתאם לאובייקט של קבוצת העניין שהוענק ל-navigator.joinAdInterestGroup(). כך הבעלים של הקבוצה יכול לעדכן מדי פעם את המאפיינים של קבוצת העניין. בהטמעה הנוכחית, אפשר לשנות את המאפיינים הבאים:

  • biddingLogicUrl
  • biddingWasmHelperUrl
  • trustedBiddingSignalsUrl
  • trustedBiddingSignalsKeys
  • ads
  • priority

שדות שלא צוינו ב-JSON לא יימחקו – רק שדות שצוינו ב-JSON יתעדכנו. לעומת זאת, קריאה ל-navigator.joinAdInterestGroup() תמחק כל קבוצת תחומי עניין קיימת.

אנחנו עושים כמיטב יכולתנו כדי לבצע את העדכונים, אבל הם עשויים להיכשל בתנאים הבאים:

  • זמן הקצוב לתפוגה של בקשת רשת (כרגע 30 שניות).
  • תקלה אחרת ברשת.
  • ניתוח JSON נכשל.

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

עדכונים ידניים

אפשר להפעיל עדכונים לקבוצות העניין שבבעלות המקור של המסגרת הנוכחית באופן ידני באמצעות navigator.updateAdInterestGroups(). הגבלת הקצב מונעת עדכונים בתדירות גבוהה מדי: קריאות חוזרות ל-navigator.updateAdInterestGroups() לא מבצעות שום פעולה עד לסיום תקופת הגבלת הקצב (כרגע יום אחד). המגבלה על קצב הקריאות מתאפסת אם navigator.joinAdInterestGroup() נקראת שוב לאותו קבוצת תחומי עניין owner ו-name.

עדכונים אוטומטיים

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

ציון מודעות לקבוצת תחומי עניין

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

{
  renderUrl: 'https://cdn.example/.../bikeAd1.html',
  metadata: bikeAd1metadata // optional
}

איך קונים שולחים הצעות מחיר?

הסקריפט בכתובת biddingLogicUrl שסופק על ידי הבעלים של קבוצת העניין חייב לכלול פונקציית generateBid(). כשמוכר שטחי פרסום קורא לפונקציה navigator.runAdAuction(), הפונקציה generatedBid() נקראת פעם אחת לכל אחת מקבוצות האינטרס שהדפדפן חבר בהן, אם הבעלים של קבוצת האינטרס הוזמן להגיש הצעת מחיר. במילים אחרות, הפונקציה generateBid() נקראת פעם אחת לכל מודעת 'מועמדת'. המוכר מספק מאפיין decisionLogicUrl בפרמטר ההגדרה של המכרז שמוענק ל-navigator.runAdAuction(). הקוד בכתובת ה-URL הזו חייב לכלול פונקציית scoreAd(), שפועלת לכל מציע במכרז כדי לתת ניקוד לכל אחת מהצעות המחיר שמוחזרות על ידי generateBid().

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

generateBid(interestGroup, auctionSignals, perBuyerSignals,
    trustedBiddingSignals, browserSignals) {
  ...
  return {
    ad: adObject,
    bid: bidValue,
    render: renderUrl,
    adComponents: [adComponentRenderUrl1, ...]
   };
}

הפונקציה generateBid() מקבלת את הארגומנטים הבאים:

  • interestGroup
    האובייקט שהוענק ל-joinAdInterestGroup() על ידי רוכש המודעה. (אפשר לעדכן את קבוצת העניין דרך dailyUpdateUrl).

  • auctionSignals
    מאפיין של הארגומנט auction config שמוענק ל-navigator.runAdAuction() על ידי המוכר של שטח הפרסום. המידע הזה מספק מידע על הקשר הדף (כמו גודל המודעה ומזהה בעל התוכן הדיגיטלי), סוג המכרז (מחיר ראשון או מחיר שני) ומטא-נתונים אחרים.

  • perBuyerSignals
    בדומה ל-auctionSignals, מאפיין של הארגומנט הגדרת המכרז שעבר ל-navigator.runAdAuction() על ידי המוכר. כך אפשר לקבל אותות לפי הקשר מהשרת של הקונה לגבי הדף, אם המוכר הוא SSP שמבצע קריאה לבידינג בזמן אמת לשרתים של הקונה ומעביר את התגובה בחזרה, או אם הדף של בעל התוכן הדיגיטלי יוצר קשר ישירות עם השרת של הקונה. במקרה כזה, הקונה יכול לבדוק חתימה קריפטוגרפית של האותות האלה בתוך generateBid()‎ כהגנה מפני פגיעה.

  • trustedBiddingSignals
    אובייקט שהמפתחות שלו הם trustedBiddingSignalsKeys של קבוצת העניין, והערכים שלו מוחזרים בבקשה trustedBiddingSignals.

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

לאובייקט browserSignals יש את המאפיינים הבאים:

{
  topWindowHostname: 'publisher.example',
  seller: 'https://ssp.example',
  joinCount: 3,
  bidCount: 17,
  prevWins: [[time1,ad1],[time2,ad2],...],
  wasmHelper: ... /* WebAssembly.Module object based on interest group's biddingWasmHelperUrl. */
  dataVersion: 1, /* Data-Version value from the buyer's Key/Value service response(s). */
}

כדי לחשב ערך של bid, הקוד ב-generateBid() יכול להשתמש במאפיינים של הפרמטרים של הפונקציה. לדוגמה:

function generateBid(interestGroup, auctionSignals, perBuyerSignals,
    trustedBiddingSignals, browserSignals) {
  return {
    ...
    bid: auctionSignals.is_above_the_fold ? perBuyerSignals.atf_value : perBuyerSignals.btf_value,
    ...
  }
}

הפונקציה generateBid() מחזירה אובייקט עם ארבעה מאפיינים:

  • ad
    מטא-נתונים שרירותיים לגבי המודעה, כמו מידע שהמוכר מצפה לקבל לגבי הצעת המחיר הזו או לגבי נכס הקריאייטיב של המודעה. המידע הזה משמש את המוכר (/resources/glossary#ssp) במכרז ובהחלטות לגבי נכסי הקריאייטיב של המודעות. המוכר משתמש במידע הזה במכרז ובלוגיקה של קבלת ההחלטות שלו.

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

  • render
    כתובת URL או רשימה של כתובות URL שישמשו לעיבוד הקריאייטיב אם הצעת המחיר הזו תנצח במכרז. (מידע נוסף זמין בקטע מודעות המורכבות מכמה חלקים במאמר ההסבר על ה-API). הערך צריך להתאים ל-renderUrl של אחת מהמודעות שהוגדרו לקבוצת האינטרסים.

  • adComponents
    רשימה אופציונלית של עד 20 רכיבים למודעות המורכבות מכמה חלקים, שנלקחת מהמאפיין adComponents של הארגומנט של קבוצת העניין שמועברת אל navigator.joinAdInterestGroup().

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

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

navigator.leaveAdInterestGroup({
  owner: 'https://dsp.example',
  name: 'custom-bikes'
});

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

3. המשתמש מבקר באתר שמוכר שטחי פרסום

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

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

4. מכרז של מודעות מתבצע בדפדפן

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

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

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

המוכר של שטח הפרסום שולח בקשה לדפדפן של המשתמש להתחיל מכרז של מודעות באמצעות קריאה ל-navigator.runAdAuction().

לדוגמה:

const auctionConfig = {
  seller: 'https://ssp.example',
  decisionLogicUrl: ...,
  trustedScoringSignalsUrl: ...,
  interestGroupBuyers: ['https://dsp.example', 'https://buyer2.example', ...],
  auctionSignals: {...},
  sellerSignals: {...},
  sellerTimeout: 100,
  perBuyerSignals: {
    'https://dsp.example': {...},
    'https://another-buyer.example': {...},
    ...
  },
  perBuyerTimeouts: {
    'https://dsp.example': 50,
    'https://another-buyer.example': 200,
    '*': 150,
    ...
  },
  componentAuctions: [
    {
      'seller': 'https://some-other-ssp.example',
      'decisionLogicUrl': ...,
      ...
    },
    ...
  ]
};

const auctionResultPromise = navigator.runAdAuction(auctionConfig);

הפונקציה runAdAuction() מחזירה הבטחה שמתקבלת ממנה URN (urn:uuid:<something>) שמייצג את התוצאה של מכרז המודעות. הדפדפן יכול לפענח את המידע הזה רק כשהוא מועבר למסגרת מוקפת לצורך רינדור: דף בעל התוכן הדיגיטלי לא יכול לבדוק את המודעה הזוכה.

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

auctionConfig מלונות

נכס חובה דוגמה תפקיד
seller חובה 'https://ssp.example' מקור המוכר.
decisionLogicUrl חובה 'https://ssp.example/auction-decision-logic.js' כתובת ה-URL של קובץ ה-JavaScript של ה-Worklet של המכרז.
trustedScoringSignalsUrl אופציונלי 'https://ssp.example/scoring-signals' כתובת ה-URL של השרת המהימן של המוכר.
interestGroupBuyers* חובה ['https://dsp.example', 'https://buyer2.example', ...] מקורות של כל בעלי קבוצות העניין שנדרשו להגיש הצעת מחיר במכרז.
auctionSignals אופציונלי {...} מידע מהמוכר על הקשר הדף, סוג המכרז וכו'.
sellerSignals אופציונלי {...} מידע שמבוסס על הגדרות של בעלי תוכן דיגיטלי, שליחת בקשה להצגת מודעה לפי הקשר וכו'.
sellerTimeout אופציונלי 100 זמן הריצה המקסימלי (אלפיות שנייה) של סקריפט scoreAd() של המוכר.
perBuyerSignals אופציונלי {'https://dsp.example': {...},
  'https://another-buyer.example': {...},
...}		 אותות לפי הקשר לגבי הדף לכל קונה ספציפי, מהשרת שלו.
perBuyerTimeouts אופציונלי 50 זמן הריצה המקסימלי (במילי-שניות) של סקריפטים generateBid() של קונה מסוים.
componentAuctions אופציונלי [{'seller': 'https://www.some-other-ssp.com',
  'decisionLogicUrl': ..., ...},
  ...]		 הגדרות נוספות למכרזים של רכיבים.

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

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

איך נבחרות המודעות?

הקוד ב-decisionLogicUrl (מאפיין של אובייקט הגדרות המכרז שמוענק ל-runAdAuction()) חייב לכלול פונקציית scoreAd(). התהליך הזה פועל פעם אחת לכל מודעה כדי לקבוע את מידת הרצון של המשתמשים לראות אותה.

scoreAd(adMetadata, bid, auctionConfig, trustedScoringSignals, browserSignals) {
  ...
  return desirabilityScoreForThisAd;
}

הפונקציה scoreAd() מקבלת את הארגומנטים הבאים:

  • adMetadata
    מטא-נתונים שרירותיים שסופקו על ידי הקונה.
  • bid
    ערך מספרי של הצעת המחיר.
  • auctionConfig
    אובייקט ההגדרות של המכרז שהועברו אל navigator.runAdAuction().
  • trustedScoringSignals
    ערכים שאוחזרו בזמן המכרז מהשרת המהימן של המוכר, שמייצגים את דעת המוכר על המודעה.
  • browserSignals
    אובייקט שנוצר על ידי הדפדפן, כולל מידע שהדפדפן יודע וייתכן שסקריפט המכרז של המוכר ירצה לאמת:
{
  topWindowHostname: 'publisher.example',
  interestGroupOwner: 'https://dsp.example',
  renderUrl: 'https://cdn.example/render',
  adComponents: ['https://cdn.com/ad-component-1', ...],
  biddingDurationMsec: 12,
  dataVersion: 1 /* Data-Version value from the seller's Key/Value service response. */
}

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

5. המוכר והקונים המשתתפים מקבלים נתונים בזמן אמת מהשירות Key/Value

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

סעיף הסבר: אחזור נתונים בזמן אמת מהשירות של מפתח/ערך של קהל מוגן.

במהלך מכרז מודעות, המוכר של שטחי הפרסום יכול לקבל נתונים בזמן אמת על נכסי קריאייטיב ספציפיים של מודעות. לשם כך, הוא שולח בקשה לשירות של מפתח/ערך באמצעות המאפיין trustedScoringSignalsUrl של הארגומנט הגדרת המכרז שמועברים אל navigator.runAdAuction(), יחד עם המפתחות מהמאפיינים renderUrl של כל הרשומות בשדות ads ו-adComponents של כל קבוצות העניין במכרז.

באופן דומה, קונה של שטחי פרסום יכול לבקש נתונים בזמן אמת מהשירות של מפתח/ערך באמצעות המאפיינים trustedBiddingSignalsUrl ו-trustedBiddingSignalsKeys של הארגומנט של קבוצת העניין שמועברים אל navigator.joinAdInterestGroup().

כשמתבצעת קריאה ל-runAdAuction(), הדפדפן שולח בקשה לכל שרת מהימן של רוכש מודעות. כתובת ה-URL של הבקשה עשויה להיראות כך:

https://kv-service.example/getvalues?hostname=publisher.example&keys=key1,key2
  • כתובת ה-URL הבסיסית מגיעה מ-trustedBiddingSignalsUrl.
  • השדה hostname מסופק על ידי הדפדפן.
  • הערך של keys נלקח מ-trustedBiddingSignalsKeys.

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

6. המודעה הזו מוצגת

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

קטע הסבר: הדפדפנים מייצרים את המודעה הזוכה

כפי שמתואר למעלה: ההבטחה שמוחזרת על ידי runAdAuction() מתקבלת כ-URN, שמועברת למסגרת מוקפת לצורך עיבוד, והמודעה הזו מוצגת באתר.

7. דיווח על תוצאת המכרז

קטע הסבר: דיווח ברמת האירוע (בינתיים)

בית העסק מדווח על התוצאה

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

קוד ה-JavaScript של המוכר שסופק בכתובת decisionLogicUrl (שגם סיפק את scoreAd()) יכול לכלול פונקציית reportResult(), כדי לדווח על תוצאת המכרז.

reportResult(auctionConfig, browserSignals) {
  ...
  return signalsForWinner;
}

הארגומנטים המועברים לפונקציה הזו הם:

  • auctionConfig
    אובייקט ההגדרות של המכרז שהועברו אל navigator.runAdAuction().

  • browserSignals
    אובייקט שנוצר על ידי הדפדפן ומספק מידע על המכרז. לדוגמה:

    {
  'topWindowHostname': 'publisher.example',
  'interestGroupOwner': 'https://dsp.example',
  'renderUrl': 'https://cdn.example/url-of-winning-creative.wbn',
  'bid:' <bidValue>,
  'desirability': <winningAdScore>
}

הערך המוחזר של הפונקציה הזו משמש כארגומנט sellerSignals של פונקציית reportWin() של המגיש המנצח.

הזוכה במכרז מדווח על התוצאה

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

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

reportWin(auctionSignals, perBuyerSignals, sellerSignals, browserSignals) {
  ...
}

הארגומנטים המועברים לפונקציה הזו הם:

  • auctionSignals ו-perBuyerSignals
    הערכים זהים שהועברו אל generateBid() עבור המגיש המנצח.
  • sellerSignals
    ערך ההחזרה של reportResult(), שמאפשר למוכר להעביר מידע לקונה.

  • browserSignals
    אובייקט שנוצר על ידי הדפדפן ומספק מידע על המכרז. לדוגמה:

    {
  'topWindowHostname': 'publisher.example',
  'seller': 'https://ssp.example',
  'interestGroupOwner': 'https://dsp.example',
  'interestGroupName': 'custom-bikes',
  'renderUrl': 'https://cdn.example/winning-creative.wbn',
  'bid:' <bidValue>
}

הטמעה זמנית של דיווח על הפסדים/רווחים

יש שתי שיטות זמינות באופן זמני ב-Chrome לדיווח על מכרזים:

  • forDebuggingOnly.reportAdAuctionLoss()
  • forDebuggingOnly.reportAdAuctionWin()

כל אחת מהשיטות האלה מקבלת ארגומנט אחד: כתובת URL לאחזור אחרי שהמכרז יושלם. אפשר להפעיל אותם כמה פעמים, גם ב-scoreAd() וגם ב-generateBid(), עם ארגומנטים שונים של כתובות URL.

דוחות על הפסדים/רווחים בניפוי באגים נשלחים מ-Chrome רק כשהמכרז מסתיים. אם מכרז מבוטל (לדוגמה, בגלל ניווט חדש), לא יופקו דוחות.

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

‫8. דיווח על קליק על מודעה

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

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


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

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


מה ההבדל בין Protected Audience לבין TURTLEDOVE?

Protected Audience הוא הניסוי הראשון שייושם ב-Chromium מתוך משפחת ההצעות של TURTLEDOVE.

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

מטרת המאמץ של TURTLEDOVE היא להציע ממשק API חדש שיטפל בתרחיש השימוש הזה, תוך מתן כמה שיפורים מרכזיים בנושא פרטיות:

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

Protected Audience פותח על סמך TURTLEDOVE ועל סמך אוסף של הצעות קשורות לשינויים, שנועדו לשפר את השירות למפתחים שישתמשו ב-API:

  • ב-SPARROW: Criteo הציעה להוסיף מודל שירות ('שומרת') שפועל בסביבת מחשוב אמינה (TEE). התכונה Protected Audience כוללת שימוש מוגבל יותר בסביבות TEE, לצורך חיפוש נתונים בזמן אמת ולצורך דיווח מצטבר.
  • בבקשות של NextRoll‏ (TERN) ושל Magnite‏ (PARRROT) מתוארים התפקידים השונים של הקונים והמוכרים במכרז במכשיר. תהליך הבידינג או הניקוד של מודעות ב-Protected Audience מבוסס על העבודה הזו.
  • השינויים של RTB House ב-TURTLEDOVE לפי תוצאות וברמת המוצר שיפרו את מודל הפרטיות ואת יכולות ההתאמה האישית של המכרז במכשיר
  • PARAKEET היא הצעה של Microsoft לשירות פרסום שדומה ל-TURTLEDOVE, שמבוסס על שרת proxy שפועל בסביבת TEE בין הדפדפן לבין ספקי טכנולוגיות הפרסום, כדי להפוך בקשות להצגת מודעות לאנונימיות ולאכוף מאפייני פרטיות. מודל שרת ה-proxy לא אומץ ב-Protected Audience. אנחנו מביאים את ממשקי ה-JavaScript API של PARAKEET ו-Protected Audience לקו אחד, כדי לתמוך בעבודה עתידית שתשלב את התכונות הטובות ביותר של שתי ההצעות.

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

אילו הגדרות דפדפן זמינות?

המשתמשים יכולים לשנות את ההשתתפות שלהם בגרסת המקור לניסיון של ארגז החול לפרטיות ב-Chrome על ידי הפעלה או השבתה של ההגדרה ברמת העליונה בקטע chrome://settings/adPrivacy. במהלך הבדיקה הראשונית, אנשים יוכלו להשתמש בהגדרה ברמה גבוהה הזו של ארגז החול לפרטיות כדי לבטל את ההסכמה לשימוש ב-Protected Audience. אנחנו מתכננים לאפשר למשתמשים ב-Chrome לראות ולנהל את רשימת קבוצות האינטרס שהם נוספו אליהן באתרים השונים שבהם הם ביקרו. בדומה לטכנולוגיות של ארגז החול לפרטיות עצמן, הגדרות המשתמשים עשויות להתפתח בהתאם למשוב ממשתמשים, מרשויות רגולטוריות ומגורמים אחרים.

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

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



שיתוף משוב ויצירת אינטראקציה

קבלת תמיכה

כדי לשאול שאלה לגבי ההטמעה, הדמו או המסמכים:

אם נתקלתם באגים ובבעיות בהטמעה של Protected Audience API ב-Chrome: * כאן תוכלו לראות את הבעיות הקיימות שדווחו לגבי ה-API. * דיווח על בעיה חדשה בכתובת crbug.com/new.

שלחו לי עדכונים

  • כדי לקבל התראות על שינויים בסטטוס של ה-API, אפשר להצטרף לרשימת התפוצה למפתחים.
  • כדי לעקוב מקרוב אחרי כל הדיונים המתמשכים בנושא ה-API, לוחצים על הלחצן Watch (צפייה) בדף ההצעה ב-GitHub. לשם כך, צריך ליצור חשבון GitHub.
  • כדי לקבל עדכונים כלליים על ארגז החול לפרטיות, אפשר להירשם לפיד ה-RSS [Progress in the Privacy Sandbox].

למידע נוסף

תמונה של Ray Hennessy ב-Unsplash.