עדכונים לגבי הצעות לדיווח על שיוך (Attribution) בינואר 2022

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

יומן שינויים

למי הפוסט הזה מיועד?

הפוסט הזה מיועד לך:

  • אם אתם כבר מבינים את ה-API – לדוגמה, אם צפיתם ב-API או שמשתתפים בדיונים במאגר של WICG ורוצים להבין את שבוצעו בהצעה בינואר 2022.
  • אם אתם משתמשים ב-Attribution Reporting API בהדגמה (דמו) או בניסוי בסביבת הייצור.

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

העברה בהמשך

אחרי שהשינויים האלה מוטמעים ב-Chrome: אם אתם משתמשים בדוחות ברמת האירוע מ-Attribution Reporting API בהדגמה (דמו) או בניסוי בסביבת הייצור (גרסת המקור לניסיון), תצטרכו לערוך את הקוד כדי שה-API ימשיך לעבוד. כדאי גם להשתמש בתכונות החדשות.

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

שינויי שמות

דוחות סיכום ודוחות נצברים

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

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

שינויים במנגנון API

רישום מקור מבוסס-כותרת (דוחות ברמת האירוע)

מה משתנה ולמה?

כשהמשתמש צופה במודעה או לוחץ עליה, הדפדפן מקליט את האירוע הזה באופן מקומי במכשיר של המשתמש. לצד פרמטרים שהם ספציפיים לדיווח השיוך (Attribution), attributionsourceeventid, attributiondestination, attributionexpiry ופרמטרים אחרים). של הפרמטרים האלה מוגדרים על ידי ה-adtech.

האופן שבו הפרמטרים האלה מוגדרים משתנה.

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

בהצעה החדשה, הערך של הפרמטרים האלה מוגדר במקום זאת בשרת ה-AdTech.

תרשים של רישום מקור מבוסס-כותרת

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

איך פועל רישום המקור?

  1. עבור מודעה נתונה, טכנולוגיית הפרסום צריכה להגדיר עכשיו מאפיין ספציפי בצד הלקוח attributionsrc הערך של המאפיין הזה הוא כתובת ה-URL שאליה הדפדפן ישלח בקשה; הבקשה הזו תכלול כותרת HTTP חדשה Attribution-Reporting-Source-Info הערך navigation או event,מציין אם המקור היה קליק או צפייה, בהתאמה.
  2. לאחר קבלת הבקשה, שרת המעקב אחר קליקים/צפייה אמור להגיב באמצעות HTTP הכותרת Attribution-Reporting-Register-Source שמכילה את השיוך הרצוי .

  3. המקור שמחזיר את הכותרת הזו הוא עכשיו מקור הדיווח (בעבר מוגדר כ- attributionreportto).

    כותרת Attribution-Reporting-Register-Source של תגובת HTTP:

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

מידע נוסף זמין בהסבר הטכני

רישום מקורות שיוך

הצטרפות לדיון הציבורי

גיליון מס' 261

טריגר שיוך מבוסס-כותרת (דוחות ברמת האירוע)

מה משתנה ולמה?

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

בנוסף, בהצעה החדשה, המאפיין attributionsrc נדרש בדף ההמרות.

הנימוק הוא בהרשאות: בהצעה הקודמת, האתר בצד הטריגר – בדרך כלל לאתר מפרסם — הייתה לו שליטה כללית על התכונה באמצעות כותרת Permissions-Policy, אבל לא הייתה אפשרות בקרה מפורטת ברמת הרכיב כדי לקבוע אם הרכיב יכול לשלוח בקשה לצד שבסופו של דבר יובילו לשיוך. attributionsrc משנה את ההגדרה הזו: סמן החובה הזה שמעניק למפרסם את היכולת לעקוב אחר הרכיבים שיכולים להפעיל Attribution.

שימו לב: בצד המקור – בדרך כלל באתר של בעל תוכן דיגיטלי – אמצעי בקרה ברמת הדף באמצעות קיימים Permissions-Policy, וגם פקד ברמת הרכיב דרך attributionsrc.

איך פועל טריגר השיוך (Attribution)?

עם קבלת בקשה לפיקסל והחלטה שצריך לסווג אותו כהמרה, צריך להגיב עם HTTP
חדש כותרת Attribution-Reporting-Register-Event-Trigger.

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

כותרת Attribution-Reporting-Register-Event-Trigger של תגובת HTTP:

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

הפניה לכתובת אחרת (אופציונלי)

אופציונלי: שרת ה-adTech יכול לשלוח תגובה שמכילה את Attribution-Reporting-Register-Event-Trigger כתגובה להפניה אוטומטית. כך צדדים שלישיים יכולים לתעד את אירוע ההמרה ולהורות לדפדפן לשייך אותו.

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

פרטים נוספים זמינים בדיווח של צד שלישי.

מידע נוסף זמין בהסבר הטכני

הפעלת שיוך (Attribution)

הצטרפות לדיון הציבורי

גיליון מס' 91

אין worklet (דוחות נצברים)

מה משתנה ולמה?

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

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

ההצעה החדשה מציעה מספר יתרונות:

  • הטמעת דפדפן: העיצוב החדש, בשונה מהעיצוב של מודול העבודה, עדיין חשוב פשוט יותר, כי לא נדרשת סביבת הפעלה חדשה בדפדפנים.
  • חוויית הפיתוח: העיצוב החדש מסתמך על כותרות, שנמצאות בשימוש נפוץ שמוּכרים באופן נרחב על ידי מפתחים — בניגוד ל-worklets. הוא גם תואם ככל האפשר לפלטפורמת ה-API רישום מקור, כך שיהיה קל יותר ללמוד להשתמש ב-API ולהשתמש בו.
  • אימוץ: העיצוב החדש מאפשר למערכות מדידה קיימות יותר להשתמש בנתונים נצברים דוחות. הרבה פתרונות מדידה הם HTTP בלבד: הם מסתמכים על בקשות לתמונות – פיקסל בקשות שלא מחייבות גישה של JavaScript. אבל מכיוון שגישת ה-worklet חייבה לגשת ל-JavaScript, יכול להיות שהיה קשה לעבור ממערכות מדידה קיימות.
  • עמידות: העיצוב החדש עוזר לצמצם אובדן נתונים, כי קל יותר לשלב אותו. בסמנטיקה של keepalive, לדוגמה אם נרשמים קליק או צפייה כשמשתמש עוזב דף.

איך פועל המנגנון ללא worklet

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

הצטרפות לדיון הציבורי

גיליון מס' 194

רישום מקור מבוסס-כותרת (דוחות נצברים)

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

רק שם הכותרת שונה: Attribution-Reporting-Register-Aggregatable-Source.

מידע נוסף זמין בהסבר הטכני

רישום מקור השיוך

טריגר שיוך מבוסס-כותרת (דוחות נצברים)

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

רק שם הכותרת שונה: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

מידע נוסף זמין בהסבר הטכני

רישום טריגר לשיוך (Attribution)

תכונות חדשות

דוחות של צד שלישי (דוחות ברמת האירוע ודוחות נצברים)

מה משתנה ולמה?

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

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

איך פועל דיווח על ידי צד שלישי?

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

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

כל צד יכול לגשת לדוחות הנפרדים שלו ולהגדיר לו נתונים נפרדים.

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

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

הצטרפות לדיון הציבורי

גיליון מס' 91 גיליון מס' 261

מדידה בעקבות צפייה (דוחות ברמת האירוע ודוחות נצברים)

מה משתנה ולמה?

בהצעה החדשה, מדידת צפיות שהושלמו ומדידת שיעור הקליקים פועלות בצורה מאוחדת:

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

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

איך פועלת המדידה בעקבות צפייה?

מדידת המרות בעקבות צפייה ומדידת קליקים מסתמכים על רישום מבוסס-כותרת.

מידע נוסף זמין בהסבר הטכני

דוחות ברמת האירוע (לקליקים וגם לצפיות)

הצטרפות לדיון הציבורי

גיליון מס' 261

ניפוי באגים / ניתוח ביצועים (דוחות ברמת האירוע ודוחות נצברים)

מה משתנה ולמה?

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

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

איך פועל ניפוי באגים?

רישום המקור וגם רישום הטריגר יקבלו פרמטר חדש debug_key, ללא חתימה של 64 ביט מספר שלם (כלומר מספר גדול).

אם נוצר דוח בעזרת המקור והמפתחות לניפוי באגים, ואם קובץ cookie מסוג Samesite=None ar_debug=1 הוא נמצא במאגר קובצי ה-cookie של מקור הדיווח במקור ומפעילות את זמן הרישום, ניפוי באגים הדוח (JSON) יישלח לנקודת קצה (endpoint) .well-known/attribution-reporting/debug:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

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

מידע נוסף זמין בהסבר הטכני

אופציונלי: דוחות מורחבים של ניפוי באגים

הצטרפות לדיון הציבורי

גיליון מס' 174

יכולות סינון (דוחות ברמת האירוע ודוחות נצברים)

מה משתנה ולמה?

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

  • סינון המרות: סינון המרות לפי מידע בצד המקור. עבור לדוגמה, לבחור נתוני הפעלה שונים (נתוני המרות) עבור קליקים על מודעות וצפיות במודעות.
  • חוסר התאמה בשיוך (Attribution): סינון המרות עם שיוך שגוי; הזה סינון המרות מסוג מסוים. לדוגמה, סינון המרות שתואמות לתוצאות קליק/צפייה שגוי במודעה עקב היקף היעד etld+1 ב-API.

איך עובדות יכולות הסינון? (לדוחות ברמת האירוע)

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

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

רישום לטריגר יקבל עכשיו כותרת אופציונלית Attribution-Reporting-Filters.

כותרת תגובת HTTP Attribution-Reporting-Filters:

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

לחלופין, אפשר להרחיב את הכותרת Attribution-Reporting-Register-Event-Trigger באמצעות שדה filters לביצוע סינון סלקטיבי להגדרת trigger_data על סמך source_data.

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

מידע נוסף זמין בהסבר הטכני

מסנני שיוך (Attribution) אופציונליים

הצטרפות לדיון הציבורי

גיליון מס' 194
גיליון מס' 201

שינויים בהגנה על הפרטיות

רעש ושקיפות (דוחות ברמת האירוע ודוחות נצברים)

מה משתנה ולמה?

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

לשינוי הזה יש כמה יתרונות:

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

המנגנון החדש מחליף את המנגנון הקודם, שבו 5% מהזמן מפעיל נתונים (נתוני המרות) הוחלפו בערך אקראי.

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

יש לכך שני יתרונות עיקריים:

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

איך פועל רעש?

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

הפלט המזויף יכול להיות:

  • לא לשלוח דוחות בכלל – לא משנה אם המשתמש משלים המרה;
  • דוח מזויף אחד או יותר – לא משנה אם המשתמש משלים המרה.

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

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

יש שלושה חלונות דיווח לקליקים (יומיים, 7 ימים או 30 ימים אחרי הקליק). כל זיוף מוקצה באופן אקראי לאחד מחלונות הדיווח.

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

מידע נוסף זמין בהסבר הטכני

דוגמאות להמרות מזויפות מסוג רעשי רקע

הצטרפות לדיון הציבורי

גיליון מס' 84
גיליון מס' 273

מגבלות דיווח (דוחות ברמת האירוע ודוחות נצברים)

מגבלות על מקור הדיווח

מה משתנה ולמה?

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

  • המספר המקסימלי של מקורות דיווח ייחודיים (בדרך כלל טכנולוגיות פרסום) שיכולים לרשום מומלץ להגביל את המקורות לכל {publisher, Advertiser} ל-100 מקורות ב-30 ימים. הזה נספרת ספירה עבור כל קליק על מודעה או צפייה (אירוע מקור), גם עבור כל קליק על מודעה שלא משויך.
  • המספר המקסימלי של מקורות דיווח ייחודיים (בדרך כלל טכנולוגיות פרסום) שיכולים לשלוח דוחות בכל אנחנו ממליצים להגביל את {publisher, Advertiser} ל-10 ימים ב-30 ימים. המונה הזה יהיה מחושב באופן מצטבר לכל המרה משויכת.

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

הפחתה הדרגתית בדיווח והגבלת קצב הדיווח

מה משתנה ולמה?

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

בהצעה החדשה, 100 דוחות לכל {source site, destination, Reporting origin} (בדרך כלל אפשר לקבוע לוח זמנים לפרסום {publisher, Advertiser, adtech}) במשך 30 יום.

מעבר למגבלה הזו, הדפדפן יפסיק לתזמן דוחות שתואמים ל{source site, destination, Reporting origin} (בדרך כלל {publisher, Advertiser, adtech}) – עד 30 הימים האחרונים מספר הדוחות נמוך מ-100 לאותו {source site, destination, Reporting origin}.

מידע נוסף זמין בהסבר הטכני

הפחתה הדרגתית / הגבלות קצב של דיווח

מכסת יעד (דוחות ברמת האירוע בלבד)

מה משתנה ולמה?

מכסת היעד משתנה והיא כוללת את מקור הדיווח (בדרך כלל, AdTech) בהיקף: 100 ייחודי יעדים בהמתנה (בדרך כלל אתרים של מפרסמים או אתרים שבהם ההמרות צפויות להימשך מקום) מותרים לכל {publisher, adtech}.

זוהי הגנה על הפרטיות שנועדה להגביל את השחזור של היסטוריית הגלישה.

מידע נוסף זמין בהסבר הטכני

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

כל המשאבים

תמונת הכותרת היא מ-Diana Polekhina ב-Unbounce.