למדוד מקרים שבהם קליקים או צפייה במודעה מובילים להמרה, כמו רכישה באתר של מפרסם.
למי זה מיועד?
כאן מוצגים העקרונות הבסיסיים של דוחות שיוך (Attribution) ומספר מושגים בסיסיים, אבל לא הרבה פרטים טכניים.
- אם אתם עובדים בתחום פרסום או טכנולוגיית פרסום, מוסבר איך ה-API הזה מספק יכולות שמופעלות על ידי קובצי cookie של צד שלישי. בתרחישים לדוגמה של ה-API יש פרטים נוספים על יצירת הדוחות.
- אם אתם מפתחים או מהנדסי תוכנה, כדאי לקרוא את הסקירה הכללית המלאה של המערכת או להשתתף בניסוי ב-API.
מפרסמים ובעלי תוכן דיגיטלי שמסתמכים על פלטפורמות פרסום דיגיטלי למדידת המרות לא צריכים להשתמש ישירות ב-API. כדאי להבין איך פועל דוחות השיוך (Attribution) אם אתם מתכננים לשלב את הפרסום הדיגיטלי שלכם עם ה-API הזה.
מה זה Attribution Reporting API?
כיום, מעקב ההמרות ממודעות מסתמך בדרך כלל על קובצי cookie של צד שלישי. הדפדפנים מגבילים את הגישה לקובצי Cookie של צד שלישי, כי הם יכולים לשמש למעקב אחרי משתמשים באתרים שונים ולפגיעה בפרטיות המשתמשים.
Attribution Reporting API מאפשר לבצע את המדידות האלה באופן ששומר על הפרטיות, בלי קובצי cookie של צד שלישי.
ה-API הזה מאפשר למפרסמים ולספקים של טכנולוגיות פרסום למדוד המרות במקרים הבאים:
- קליקים על מודעות וצפיות.
- מודעות ב-iframe של צד שלישי, כמו מודעות באתר של בעל תוכן דיגיטלי שמשתמש בספק צד שלישי של טכנולוגיות פרסום.
- מודעות בהקשר של אינטראקציה ישירה (First-Party),, למשל מודעות ברשת חברתית או בדף תוצאות של מנוע חיפוש, או בעל אתר שמציג את המודעות שלו.
אם אתם לא מכירים חלק מהמונחים או מהמושגים האלה, תוכלו לעיין במילון המונחים של ארגז החול לפרטיות.
רוצה לנסות את ה-API?
- בדיקה מקומית בדפדפן. מגדירים דגל, שמציין לדפדפן Chrome להפעיל תכונות ניסיוניות ספציפיות.
אם אתם רוצים להתנסות ב-API, כדאי לקרוא את המאמר Attribution Reporting: ניסוי והשתתפות.
שינויים ב-API
- יש לעקוב אחר השינויים ב-API.
- למה שלחנו את Attribution Reporting API במחצית הראשונה של שנת 2023.
זמינות
הצעה | סטטוס |
---|---|
תהליך ההמרה: מהאפליקציה לאתר הודעת הסבר באינטרנט והודעת הסבר ל-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 נותן גישה לסוגים שונים של תובנות, עם שני סוגי דוחות שאפשר לשלוח למפרסם או לספק צד שלישי של טכנולוגיות פרסום. אפשר להשתמש בשני סוגי הדוחות האלה בו-זמנית והם משלימים את התהליך.
- דוחות ברמת האירוע משייכים קליק או צפייה מסוימים על מודעה (בצד המודעה) לנתונים בצד ההמרה. הנתונים בצד ההמרה מוגבלים מאוד, והנתונים מושמעים (כלומר, באחוז קטן מהמקרים, נתונים אקראיים נשלחים במקום דוחות אמיתיים). כך אפשר לשמור על פרטיות המשתמשים על ידי מניעת צירוף של זהות המשתמש בין אתרים. כאמצעי הגנה נוסף על הפרטיות, הדיווחים נשלחים בעיכוב.
- דוחות הסיכום לא משויכים לאירוע ספציפי בצד המודעה. הדוחות האלה מספקים נתוני המרות עשירים יותר ובעלי רמת דיוק גבוהה יותר בדוחות מאשר בדוחות ברמת האירוע. שילוב של שיטות לשמירה על פרטיות עוזר להפחית את הסיכון לאיחוד זהויות באתרים.
דוחות ברמת האירוע
דוחות ברמת האירוע משייכים קליק על מודעה או צפייה במודעה לנתוני המרות משוערים.
דוחות ברמת האירוע מתאימים למקרים הבאים:
- אופטימיזציה. ענו על שאלות כמו "איך אפשר לשפר את ההחזר על ההשקעה?". באופן ספציפי, ניתן להשתמש בדוחות האלה לאופטימיזציה של מיקומי המודעות, כי הדוחות יכולים לכלול מזהים ייחודיים בצד המודעה. דוחות ברמת האירוע יכולים לספק נתוני אימון למודלים של למידת מכונה.
- דיווח גס, שבו נדרש מעט מאוד מידע לגבי ההמרה. המגבלה הנוכחית היא 3 סיביות של נתוני המרות לקליקים⏤פירוש המשמעות היא שאפשר להקצות המרה אחת מתוך שמונה קטגוריות⏤ וביט אחד עבור צפיות. בדוחות ברמת האירוע אין תמיכה בקידוד של נתונים מפורטים בצד ההמרה, כמו מחיר ספציפי או מועד המרה ספציפי.
- זיהוי הונאות. הנתונים בדוחות מסוימים יכולים להיות שימושיים לזיהוי ולניתוח של הונאות במודעות, כי הם מאפשרים להבין את הדפוסים שבהם אפשר להשתמש כדי לזהות פעילות ספאמית או לא חוקית.
דוחות סיכום
דוחות סיכום (לשעבר 'דוחות מצטברים') מציעים נתוני המרות מפורטים יותר וגמישות רבה יותר לצירוף נתוני קליקים או צפייה ונתוני המרות.
מידע נוסף על דוחות סיכום
דוחות סיכום מתאימים במיוחד לתרחישי דיווח. הדוחות האלה עוזרים לענות על שאלות כמו: "מהו ההחזר על ההשקעה שלי?"
השימוש בדוחות סיכום לצורך אופטימיזציה (לדוגמה, כדי לבצע אופטימיזציה לפי ערך רכישה שלא נתמך בדוחות ברמת האירוע (כי נתוני ההמרות גסים מדי)) הוא תחום מחקר פעיל.
תכונות אחרות
תכונות נוספות של ה-API הזה כוללות:
- שיוך מאפליקציה לאתר: אפשר לראות מודעה באפליקציה או ללחוץ עליה ולגרום להמרה באתר.
תמיכת דפדפן
- ל-Firefox ו-Edge לא שותפו אותות.
- Safari ו-Webkit הם שליליים, והציעו ממשק API אחר למדידת המרות ממודעות, שנקרא מדידת קליקים פרטיים.
יש שני ממשקי API שונים, אבל Chrome ו-WebKit עובדים יחד במקום פתוח כדי לפשט את חוויית הפיתוח. לדוגמה, על ידי התאמה בין שמות המאפיינים לבין מבנה JSON בדוחות.
קבוצת התכונות של Attribution Reporting API שונה מזו של ה-Private קליקים Measurement API שמוצע על ידי Safari ו-WebKit. ההגבלה המשמעותית ביותר היא באמצעות Attribution Reporting API:
- יש תמיכה במדידה בעקבות צפייה.
- אפשר לספק דוחות ברמת האירוע.
- דוחות סיכום מכילים מידע עשיר, הן בצד של קליק/צפייה והן בצד ההמרות.
- צדדים שלישיים, כמו פלטפורמות של פרסום דיגיטלי, יכולים לקבל דוחות בשם בעלי האתרים והמפרסמים.
הגדרת הדפדפן
- המשתמשים יכולים לבטל את ההסכמה לשימוש ב-API דרך הגדרות המשתמש בכתובת
chrome://settings/adPrivacy
. - ה-API לא פעיל במצב פרטי.
- ה-API לא פעיל כאשר קובצי cookie של צד שלישי מושבתים.
איך אתרים יכולים לשלוט בגישה?
אם ה-API זמין בדפדפן מסוים, הוא יהיה זמין כברירת מחדל בכל אתר נתון, גם במסמכים ובסקריפטים ברמה העליונה, וגם במסגרות iframe ממקור זהה.
צדדים שלישיים שרירותיים – לדוגמה, מסגרות iframe של מודעות ממקורות שונים שלא נוספו לדף עם סקריפט שיש לו גישה ברמה העליונה – לא יכולים להשתמש ב-API ללא ידיעתו של בעל האתר או המפרסם: במסגרות ה-iframe האלה, צריך להפעיל את Attribution Reporting API באופן מפורש באמצעות מדיניות ההרשאות.
<iframe src="..." allow="attribution-reporting"></iframe>
צדדים שלישיים עם גישה ברמה העליונה שמוסיפים לדף מסגרות iframe ממקורות שונים יכולים להפעיל גם את Attribution Reporting API עם מדיניות ההרשאות.
אתרים יכולים להשבית את Attribution Reporting API לכל הצדדים, כולל סקריפטים עם גישה ברמה העליונה, על ידי שליחת כותרת התגובה של ה-HTTP:
Permissions-Policy: attribution-reporting=()
איך פועל Attribution Reporting API?
Attribution Reporting API מאפשר למדוד שני אירועים שמקושרים יחד: אירוע באתר של בעל התוכן הדיגיטלי, למשל משתמש צופה במודעה או לוחץ עליה, ובהמשך המרה באתר של המפרסם.
דוחות ברמת האירוע
דוחות סיכום
דוחות סיכום נוצרים באופן הבא:
- משתמש לוחץ על מודעה שהוגדרה במיוחד או צופה בה. הדפדפן – במכשיר המקומי של המשתמש – מתעד את האירוע הזה, לצד נתוני שיוך (Attribution) שנקבעו מראש.
- בהמשך, כשהמשתמש משלים המרה, הדפדפן מתאים את האירוע המפורט של הקליק או הצפייה (שנקרא אירוע מקור השיוך (Attribution)) לנתוני המרות מפורטים (שנקראים נתונים של טריגר השיוך (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 הביטים האלה אפשר לקשר רק למידע מועט מאוד מאתרים שונים: ביט אחד או 3 ביט, שאינם מספיקים בשביל מזהה.- 64 הביטים בצד המודעה הם לא מידע חדש. מזהה משתמש כבר יכול להיות זמין בצד המודעה כיום. ל-
news.example
או ל-adtech.example
כבר יש מידע על הפעילות של משתמש מסוים ב-news.example
.
- 64 הביטים בצד המודעה הם לא מידע חדש. מזהה משתמש כבר יכול להיות זמין בצד המודעה כיום. ל-
- אמצעי הגנה נוספים חלים כדי למנוע ניצול לרעה ומעקב בין אתרים:
- הדוחות נשלחים עם עיכוב.
- נתוני ההמרות רעשים: באחוז מסוים מהזמן מופקים דוחות מזויפים.
- מספר הדוחות של ההמרות המשויכות מוגבל לכל קליק או צפייה.
בפירוט: דוחות סיכום ופרטיות
דוחות סיכום משייכים אירוע קליק או צפייה לנתונים מפורטים של המרות. הם מספקים תובנות לגבי המרות בלי לעקוב אחרי המשתמשים באתרים שונים, תוך שימוש במנגנוני הפרטיות הבאים:
- לא נעשה שימוש במזהה חוצה-אתרים.
- כל שיוך יכול להוסיף מספר תכנים לדוח סיכום שמתקבל. כל משתמש נתון יכול להפעיל מספר ייחוסים לקליק (או לצפייה) ולהמרה מסוימת.
- הנתונים נצברים עד לרמה של אירועים רבים (משתמשים רבים), ואי אפשר לצפות באירועים ספציפיים בצורה מדויקת. כשבוחנים את הנתונים הנצברים, ככל שרמת הפירוט עולה, כך עולה גם הרעש היחסי בנתונים האלה. פלחי נתונים שצוברים הרבה אירועים ומשתמשים מדויקים יותר כדי לשמר את התועלת.
- הדוחות הגולמיים שמשויכים לאירוע מפורט של קליק או צפייה עם נתוני המרות מפורטים מוצפנים, וחברת הפרסום הדיגיטלי לא יכולה לקרוא אותם. רק שירות הצבירה יכול לקרוא את הנתונים האלה.
- אמצעי הגנה נוספים חלים כדי למנוע ניצול לרעה ומעקב בין אתרים:
- דוחות נשלחים עם עיכובים אקראיים.
- שאילתות על פילוחים שונים של הנתונים מוגבלות לקצב שליחת בקשות.
מעורבות ושיתוף משוב
- אם יש לכם שאלות על ה-API: יוצרים בעיה במאגר ה-API.
- עוקבים אחרי ההודעות והעדכונים של ה-API ברשימת התפוצה של Attribution Reporting.
- אם יש לכם שאלות טכניות, תוכלו לדווח על באג ב-Chromium.
- לשאלות בנושא הטמעה, שילוב ושיטות מומלצות כלליות: יוצרים בעיה במאגר התמיכה למפתחים של ארגז החול לפרטיות.