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

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

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

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

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

מה זה Protected Audience?

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

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

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

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

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

הדגמה של Protected Audience API

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

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

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

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

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

בדיקת ה-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 API:

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

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

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

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

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

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

קוד השירות של 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 מפעיל או משבית את הפונקציונליות להפעלת מכרז במכשיר

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

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

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

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

צילום מסך של
כלי פיתוח ב-Chrome Canary, שמדגישים את החלונית Threads בחלונית 'מקורות', שבה מוצג המצב הנוכחי
סקריפט 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. משתמש מבקר באתר של מפרסם

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

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

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

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

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

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

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

הערה: המקור של ההקשר של הקריאה עבור joinAdInterestGroup() חייב להיות זהה לקבוצת האינטרס המקור של הבעלים, לכן צריך לקרוא ל-joinAdInterestGroup() מ-iframe (עבור לדוגמה, מ-DSP) אלא אם המקור של הבעלים של קבוצת האינטרס תואם למקור של מסמך (לדוגמה, אתר עם קבוצות אינטרס משלו). לאפליקציה runAdAuction אין אותן דרישות, לכן צריך לקרוא ל-runAdAuction() <script> סביר להניח שהביצועים של התג הרבה יותר טובים מ-iframe ממקורות שונים.

לאפליקציה joinAdInterestGroup() נדרשת הרשאה מ:

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

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

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

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

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

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

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

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

נקודה חשובה: כל כתובות ה-URL שמשמשות כפרמטרים בשיטות של Protected Audience API חייבות להגיע ממקורות מאובטחים: כל המשאבים חייבים יוצגו בכתובות URL מסוג HTTPS. איך משתמשים ב-HTTPS לפיתוח מקומי מסביר איך לעשות זאת כשמריצים את Protected Audience באופן מקומי. בנוסף, biddingLogicUrl, decisionLogicUrl ו-trustedBiddingSignals מחייבים כותרת תגובת HTTP X-Allow-FLEDGE: true.

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

נכס	חובה	דוגמה	תפקיד
`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().

הערה: המאפיין biddingWasmHelperUrl הוא אופציונלי, אבל הוא מאפשר למגיש הצעות המחיר לספק תת-רגילים יקרים ב-WebAssembly, ולא ב-JavaScript, להגיע מפונקציית JavaScript שסופקה על ידי biddingLogicUrl. אם המיקום הוא חייב להפנות לקובץ בינארי של WebAssembly, שיישלח באמצעות application/wasm mimetype. WebAssembly.Module תואם הופך לזמין על ידי הדפדפן בפונקציה generateBid().

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

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

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

interestGroup
האובייקט הועבר אל joinAdInterestGroup() על ידי קונה המודעה. (קבוצת האינטרס ייתכן שיעודכן דרך dailyUpdateUrl.)
auctionSignals
מאפיין של הארגומנט config 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. המשתמש מבקר באתר שמוכר שטח להצגת מודעות

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

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

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

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

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

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

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

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

הערה: כמו שהוסבר קודם, המקור של ההקשר של הקריאה עבור joinAdInterestGroup() חייב להיות זהה לזה של הבעלים של קבוצת תחומי העניין מקור, כך שצריך לקרוא ל-joinAdInterestGroup() מ-iframe (לדוגמה, מ-DSP) אלא אם המקור של הבעלים של קבוצת האינטרס תואם למקור של מסמך (לדוגמה, אתר עם קבוצות אינטרס משלו). לאפליקציה runAdAuction אין אותן דרישות, לכן צריך לקרוא ל-runAdAuction() <script> סביר להניח שהביצועים של התג הרבה יותר טובים מ-iframe ממקורות שונים.

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

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

6. המודעה שתזכה במכרז תוצג.

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

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

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

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

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

הערה: התוכנית לטווח ארוך היא לאפשר לדפדפן לדווח על תוצאות מכרזים עבור בית העסק והקונים באמצעות צבירת ממשקי API לדיווח. כמנגנון דיווח זמני ברמת האירוע, הקוד שמיישם את reportResult() עבור המפיץ, ו-reportWin() עבור מגיש הצעות המחיר שזכה, יכולים לקרוא לפונקציה sendReportTo(). הפעולה הזו לוקחת ארגומנט יחיד: מחרוזת שמייצגת כתובת URL שמאוחזרת לאחר שהמכרז הסתיים, מקודד מידע ברמת האירוע שידווח.

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

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

קוד ה-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) {
  ...
}

הערה: במסגרת ההטמעה הנוכחית של Protected Audience ב-Chrome, תוצג אזהרה אם לא מגדירים את reportWin().

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

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. נשלח דיווח על קליק על מודעה

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

המערכת מדווחת על קליק על מודעה שהוצגה במסגרת מגודרת. כדי להבין איך זה עובד, ראו דיווח על מודעות 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, לחיפוש נתונים בזמן אמת ודיווח מצטבר.
TERN ו-Magnite של NextRoll PARRROT (PARRROT) בהצעות תוארו התפקידים השונים שהיו לקונים ולמוכרים במכרז במכשיר. תהליך הבידינג או תהליך הציון של Protected Audience מבוסס על העבודה הזו.
המבוססת על תוצאות של בית ה-RTB ברמת המוצר TURTLEDOVE ושפרו את מודל האנונימיות ואת יכולות ההתאמה האישית של המכרזים במכשיר
PARAKEET הוא הצעה של Microsoft לשירות מודעות דמוי-TURTLEDOVE שמסתמך על שרת proxy שפועל בסביבת TEE בין הדפדפן לבין ספקי טכנולוגיות הפרסום, כדי לבצע אנונימיזציה של בקשות להצגת מודעות ולאכוף פרטיות נכסים. Protected Audience לא אימץ את מודל שרת ה-Proxy הזה. אנחנו מביאים את ממשקי ה-API של JavaScript עבור PARAKEET ו-Protected Audience API בהתאמה אישית, כדי לתמוך במחקרים עתידיים במטרה לשלב בתכונות של שתי ההצעות.

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

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

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

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

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

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

GitHub: קראו את ההצעה, אפשר להעלות שאלות ולעקוב אחרי הדיון.
W3C: לדון בתרחישים לדוגמה בתחום במאמר שיפור עסקי הפרסום באינטרנט קבוצה.
תמיכה למפתחים: אפשר לשאול שאלות ולהצטרף לדיונים מאגר התמיכה למפתחים של ארגז החול לפרטיות
רשימת תפוצה של FLEDGE: fledge-api-announce שמספק הודעות ועדכונים לגבי ה-API.
הצטרפות לשיחות המתוזמנות עבור Protected Audience (כל בשבוע השני). כולם מוזמנים להצטרף — כדי להשתתף, עליך להקפיד להצטרף WICG. אתם יכולים להשתתף באופן פעיל או רק להאזין לו!
שימוש בטופס המשוב לגבי ארגז החול לפרטיות כדי לשתף משוב באופן פרטי עם הצוות של Chrome מחוץ לפורומים ציבוריים.

קבלת תמיכה

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

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

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

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

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

למידע נוסף

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

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