סקירה כללית על דוחות שיוך (Attribution) באינטרנט

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

למי זה מיועד?

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

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

מה זה Attribution Reporting API?

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

Attribution Reporting API מאפשר לבצע את המדידות האלה תוך שמירה על הפרטיות, ללא קובצי cookie של צד שלישי.

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

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

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

אני רוצה לנסות את ה-API

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

אם אתם רוצים להתנסות ב-API, עברו למאמר Attribution Reporting: הניסוי והשתתפות.

שינויים ב-API

זמינות

הצעה סטטוס
תהליך ההמרה: מהאפליקציה לאתר
הודעת הסבר באינטרנט והודעת הסבר ל-Android
הודעה בנושא רשימת תפוצה		 האפשרות זמינה ב-Chrome וב-Android לגרסת המקור לניסיון
תהליך ההמרה: בין מכשירים
הסבר		 הצעה זו הועברה לארכיון. אין כרגע תוכניות להטמעת הנתונים.
מניעה של דוחות נצברים לא חוקיים באמצעות אימות דוחות
הסבר 		צפויות בחירות ב-Chrome במחצית הראשונה של 2024
רשימת ההיתרים שמוגדרת כברירת מחדל ב-Attribution Reporting API תישאר *
הודעה על רשימת תפוצה		 ברבעון הראשון של 2023 יש גישה ל-Chrome
פרק זמן של דיווח ברמת האירוע הניתן להגדרה
בעיה ב-GitHub		 זמינות ב-Chrome ברבעון הרביעי של 2023
מרווח פנימי למטען ייעודי (payload) של דוחות מצטברים
הסבר מעודכן		 זמינות ב-Chrome ברבעון הרביעי של 2023
שלב 1 Lite גמיש ברמת האירוע
הסבר על הגדרות גמישות ברמת האירוע		 זמינות ב-Chrome ברבעון הרביעי של 2023
האפשרות להתאים אישית את המספר של דוחות השיוך (Attribution) ואת המספר/האורך של חלונות הדיווח.

התכונה זמינה ב-Chrome ברבעון הראשון של 2024
האפשרות להתאים אישית את מספר הסיביות של הנתונים בטריגר.
תמיכה בניפוי באגים בדוחות שיוך (Attribution) אחרי ההוצאה משימוש של קובצי cookie של צד שלישי
בקשת משוב על GitHub		 צפויות בחירות ב-Chrome במחצית הראשונה של 2024
תמיכה ב-Attribution Reporting API ובשירות צבירה ל-Google Cloud
הסבר על Attribution Reporting API
הסבר על שירות צבירה		 זמינות ב-Chrome במחצית השנייה של 2023

תרחישים לדוגמה ותכונות

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

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

דוחות ברמת האירוע

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

דוח ברמת האירוע
דוח לדוגמה ברמת האירוע: מזהה הקליק 200400600 ב-news.example (מצורף למזהה המשתמש Bob_Doe ב-news.example) הוביל לרכישה ב-shop.example.

דוחות ברמת האירוע מתאימים למקרים הבאים:

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

דוחות סיכום

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

מידע נוסף על דוחות סיכום

דוגמה לתובנות מדוחות סיכום.
דוגמה לתובנות מדוחות סיכום: CampaignID 1234567 ב-news.example הוביל ל-518 המרות ב-shoes.example, ולהוצאה כוללת של 3,174$. מחצית מההמרות הגיעו ממשתמשים בניו יורק, ארה"ב.

דוחות סיכום מתאימים במיוחד לתרחישי דיווח. הדוחות האלה עוזרים לענות על שאלות כמו: "מהו ההחזר על ההשקעה שלי?"

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

תכונות אחרות

תכונות נוספות של ה-API הזה:

תמיכת דפדפן

אומנם שני ממשקי ה-API שונים, אבל Chrome ו-WebKit עובדים יחד בשטח פתוח כדי לפשט את חוויית המפתח, למשל על ידי התאמה בין שמות המאפיינים לבין מבנה ה-JSON של הדוחות.

קבוצת התכונות של Attribution Reporting API שונה מזו של Private Click Measurement API שמוצע על ידי Safari ו-WebKit. התכונה הבולטת ביותר היא Attribution Reporting API:

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

הגדרת הדפדפן

  • המשתמשים יכולים לבטל את ההסכמה ל-API דרך הגדרות המשתמשים בכתובת chrome://settings/adPrivacy.
  • ה-API לא פעיל במצב מצב פרטי.
  • ה-API לא פעיל כשקובצי cookie של צד שלישי מושבתים.

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

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

צדדים שלישיים שרירותיים – לדוגמה, מסגרות iframe של מודעות ממקורות שונים שלא נוספו לדף עם סקריפט עם גישה ברמה העליונה – לא יכולים להשתמש ב-API ללא ידיעתו של בעל התוכן הדיגיטלי או המפרסם: במסגרות ה-iframe האלה, יש להפעיל באופן מפורש את Attribution Reporting API עם Permissions Policy.

<iframe src="..." allow="attribution-reporting"></iframe>

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

אתר יכול להשבית את Attribution Reporting API לכל הצדדים, כולל סקריפטים עם גישה ברמה העליונה, על ידי שליחת כותרת התגובה של HTTP:

Permissions-Policy: attribution-reporting=()

איך פועל Attribution Reporting API?

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

דוחות ברמת האירוע

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

דוחות סיכום

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

דוחות סיכום נוצרים באופן הבא:

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

מידע נוסף על דוחות סיכום

פרטיות

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

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

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

תצוגה זה לצד זה של האינטרנט של היום (הזהות שהצטרפת) והאינטרנט של מחר (זהות מחולקת למחיצות)
תצוגה זה לצד זו של האינטרנט של היום (הזהות שהצטרפת אליה) והאתר של מחר (זהות מחולקת למחיצות)

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

הגנות בכל סוג דוח

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

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

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

בפירוט: דוחות ברמת האירוע ופרטיות

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

  • לא נעשה שימוש במזהה בין אתרים, ולא מתבצעת יציאה מהמכשיר בעקבות פעילות גלישה מפורטת בין אתרים.
  • דוחות ברמת האירוע משייכים 64 ביטים בצד המודעה (news.example) רק ביט אחד או 3 ביטים בצד ההמרה (shop.example). 64 ביטים הם מספיק מידע כדי שאפשר יהיה למפות אותם למזהה של משתמש יחיד, אבל 64 הביטים האלה אפשר לקשר רק עם מעט מאוד מידע בין אתרים: 1 ביט או 3 ביט, והם לא מספיקים כדי להכיל מזהה.
    • קטעי ה-64 סיביות בצד המודעה אינם מידע חדש. מזהה משתמש כבר יכול להיות זמין בצד המודעה היום. news.example או adtech.example כבר יודעים על פעילות של משתמש מסוים ב-news.example.
  • אמצעי הגנה נוספים מופעלים כדי למנוע ניצול לרעה ומעקב באתרים שונים:
    • הדוחות נשלחים עם עיכוב.
    • נתוני ההמרות כוללים רעש: אחוז מסוים מהזמן, מופקים דוחות מזויפים.
    • מספר הדוחות על המרות משויכות מוגבל לכל קליק או צפייה.

בפירוט: דוחות סיכום ופרטיות

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

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

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