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

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

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

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

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

מהו 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך פועל Protected Audience API?

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

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

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

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

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

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

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

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

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

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

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

נכס	חובה	דוגמה	תפקיד
`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. הדפדפן מאפשר לפונקציה generateBid() לגשת ל-WebAssembly.Module התואם.

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

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

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

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

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

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

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

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

נקודת מפתח: בשלב הניסיוני הראשוני הנוכחי לבדיקה של 'קהל מוגן', למאפיין trustedBiddingSignalsUrl צריך להיות אותו מקור כמו לבעלים של קבוצת העניין: ראו מאפייני קבוצות עניין וBring Your Own Server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבלת תמיכה

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

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

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

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

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

למידע נוסף

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

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

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

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

מהו Protected Audience?

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

הדגמה של Protected Audience

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

בדיקת ה-API

עיבוד מודעות ב-iframe או במסגרות מגודר

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

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

שירות Key/Value

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

איך אפשר לבטל את ההשתתפות בתוכנית Protected Audience?

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

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

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

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

איך פועל Protected Audience API?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

auctionConfig מלונות

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

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

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

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

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

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

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

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

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

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

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

קבלת תמיכה

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

למידע נוסף

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

`auctionConfig` מלונות