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

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

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

מה זה Protected Audience?

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

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

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

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

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

הדגמה של Protected Audience API

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

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

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

גרסת המקור לניסיון של רלוונטיות ומדידה בארגז החול לפרטיות זמינה בגרסת בטא 101.0.4951.26 ומעלה של Chrome במחשב, בממשקי ה-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, כמו קריאה ל-navigator.joinAdInterestGroup() מבעלי קבוצת תחומי עניין – צריך לספק אסימון שתואם למקור שלו.

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

בדיקת ה-API הזה

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

  • הפעלת כל ממשקי ה-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?

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

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

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

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

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

שירות למפתחות/ערך

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צפייה באירועים של Protected Audience API

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

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

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

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

חלונית האפליקציה של כלי הפיתוח ב-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() מאותו המקור שבו הגיע האתר, כלומר מאותו המקור של המסגרת ברמה העליונה של הדף הנוכחי. אתרים יכולים להשתמש בכותרת מדיניות ההרשאות של Protected Audience join-ad-interest-group כדי להשבית קריאות ל-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 יום. קריאות עוקבות מבטלות ערכים שאוחסנו בעבר.

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

מאפיין (property) חובה דוגמה תפקיד
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 יש את המאפיינים (properties) הבאים:

{
  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
    מטא-נתונים שרירותיים לגבי המודעה, כמו מידע שהמוכר מצפה לקבל לגבי הצעת המחיר או הקריאייטיב של המודעה. אתר המכירה](/privacy-sandbox/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 מלונות

מ��פיין (property) חובה דוגמה תפקיד
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 בהטמעה הנוכחית של Protected Audience API. למידע נוסף, תוכלו לקרוא את הקטע Auction-Participants (משתתפים במכרז) בהודעת ההסבר על Protected Audience API.

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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



מעורבות ושיתוף משוב

פנייה לתמיכה

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

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

קבלת עדכונים

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

פרטים נוספים

תמונה מאת ריי הנסי ב-Un אימייל.