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

דוחות שיוך (Attribution): סקירה כללית של המערכת

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

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

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

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

עליכם לקרוא את המאמר הזה אם:

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

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

סקירה כללית

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

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

תמיד יש שני רכיבים (ולפעמים גם שלושה) שפועלים יחד כדי לתמוך בדיווח:

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

אם אספתם דוחות מצטברים, תצטרכו רכיב שלישי:

יצירת דוח סיכום. צרו דוחות נצברים והשתמשו ב-Aggregation Service כדי לעבד את הדוחות וליצור דוח סיכום.

החלטות בנוגע לעיצוב

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

דוח הפלט יכול להיות:

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

הבחירה בדוח קובעת אילו נתונים צריך לאסוף.

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

אחרי שתחליטו מה רוצים למדוד, תוכלו להגדיר את הצד הלקוח ל-Attribution Reporting API.

תקשורת מאתר לדפדפן

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

זרימת אירועי שיוך (Attribution)

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

באתר של בעל התוכן הדיגיטלי, רכיב מודעה (תג <a> או <img>) מוגדר עם מאפיין מיוחד attributionsrc. הערך שלו הוא כתובת URL, לדוגמה https://adtech.example/register-source/ad_id=....

הנה דוגמה לקישור שירשום מקור לאחר לחיצה עליו:
```
<a href="https://shoes.example/landing" 
  attributionsrc="http://adtech.example/register-source?..."
  target="_blank">
Click me</a>
```
הנה דוגמה לתמונה שתגרום לרישום של מקור כשמציגים אותו:
```
<img href="https://advertiser.example/landing" 
  attributionsrc="https://adtech.example/register-source?..."/>
```
לחלופין, במקום רכיבי HTML, ניתן להשתמש בקריאות של JavaScript.

הנה דוגמה ל-JavaScript באמצעות window.open(). שימו לב שכתובת ה-URL מקודדת בקידוד URL כדי למנוע בעיות בתווים מיוחדים.
```
const encodedUrl = encodeURIComponent(
  'https://adtech.example/attribution_source?ad_id=...');
window.open(
  "https://shoes.example/landing",
  "_blank",
  attributionsrc=${encodedUrl});
```

כשמשתמש לוחץ על המודעה או צופה בה, הדפדפן שולח בקשת GET אל attributionsrc. בדרך כלל מדובר בנקודת קצה של מפרסם או של ספק טכנולוגיית פרסום.
לאחר קבלת הבקשה, המפרסם או ספק טכנולוגיות הפרסום מחליטים להנחות את הדפדפן לרשום אירועי מקור עבור אינטראקציות עם המודעה, כדי שניתן יהיה לשייך המרות למודעה הזו בשלב מאוחר יותר. כדי לעשות את זה, המפרסם או ספק הפרסום הדיגיטלי כוללים בתגובה כותרת HTTP מיוחדת. הוא מצרף נתונים מותאמים אישית לכותרת שמספקים מידע על אירוע המקור (קליק על מודעה או צפייה במודעה). אם בסופו של דבר המרה מתרחשת במודעה, הנתונים המותאמים אישית האלה יוצגו בסופו של דבר בדוח השיוך (Attribution).
לאחר מכן, המשתמש מבקר באתר של המפרסם.
בכל דף רלוונטי באתר של המפרסם – לדוגמה, דף אישור רכישה או דף מוצר – פיקסל המרה (אלמנט <img>) או קריאה של JavaScript שולח בקשה אל https://adtech.example/conversion?param1=...&param2=....
השירות בכתובת ה-URL הזו – בדרך כלל, המפרסם או ספק טכנולוגיית הפרסום – מקבל את הבקשה. הוא מחליט לסווג את ההמרה הזו כהמרה, לכן צריך להנחות את הדפדפן לתעד המרה – כלומר, להפעיל שיוך (Attribution). כדי לעשות זאת, המפרסם או ספק הפרסום הדיגיטלי כוללים בתגובה לבקשת ה-Pixel כותרת HTTP מיוחדת שכוללת נתונים מותאמים אישית לגבי ההמרה.
הדפדפן, במכשיר המקומי של המשתמש, מקבל את התגובה הזו ומתאים את נתוני ההמרה לאירוע המקורי המקורי (קליק על מודעה או צפייה במודעה). מידע נוסף זמין במאמר התאמת מקורות לטריגרים
הדפדפן מתזמנ את שליחת הדוח לכתובת attributionsrc. הדוח כולל:
1. נתוני ההגדרה של השיוך בהתאמה אישית שהספק או המפרסם צירפו לאירוע המקור בשלב 3.
2. נתוני ההמרות המותאמות אישית שהוגדרו בשלב 6.
לאחר מכן, הדפדפן שולח את הדוחות לנקודת הקצה שהוגדרה ב-attributionsrc, עם עיכוב ורעש מסוימים. הדוחות המצטברים מוצפנים, ואילו הדוחות ברמת האירוע לא מוצפנים.

טריגרים של שיוך (האתר של המפרסם)

טריגר השיוך (Attribution) הוא האירוע שאומר לדפדפן לתעד המרות.

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

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

התאמת מקורות לטריגרים

כשדפדפן מקבל תגובה לטריגר של שיוך, הדפדפן ניגש לאחסון המקומי כדי למצוא מקור שתואם גם למקור של טריגר השיוך וגם ל-eTLD+1 של כתובת ה-URL של הדף.

לדוגמה, כשהדפדפן מקבל טריגר שיוך מ-adtech.example ב-shoes.example/shoes123, הדפדפן מחפש מקור באחסון המקומי שתואם גם ל-adtech.example וגם ל-shoes.example.

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

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

איסוף נתונים

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

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

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

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

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

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

דוחות נצברים

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

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

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

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

שירות צבירה

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

ניסוי עם ה-API

אתם יכולים לנסות ולהשתתף בשיחה על Attribution Reporting API.