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

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

יומן שינויים

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

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

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

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

העברה לפניך

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

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

שינויי שמות

דוחות סיכום ודוחות מצטברים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לקרוא מידע נוסף בסרטון ההסבר הטכני

רישום של מקורות שיוך (Attribution)

מצטרפים לדיון הציבורי

בעיה מס' 261

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לקרוא מידע נוסף בסרטון ההסבר הטכני

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

מצטרפים לדיון הציבורי

בעיה מס' 91

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

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

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

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

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

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

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

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

רישום מפעילים מרובים ללא הפניות מחדש

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

מצטרפים לדיון הציבורי

בעיה מס' 91 בעיה מס' 261

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

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

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

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

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

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

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

אפשר לקרוא מידע נוסף בסרטון ההסבר הטכני

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

מצטרפים לדיון הציבורי

בעיה מס' 261

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

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

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

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

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

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

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

אפשר לקרוא מידע נוסף בסרטון ההסבר הטכני

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

מצטרפים לדיון הציבורי

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לקרוא מידע נוסף בסרטון ההסבר הטכני

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

כל המשאבים

תמונת הכותרת היא של דיאנה פולקינה בערוץ ביטול המים.