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

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

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

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

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

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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זרימת אירועי שיוך (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 מקודדת כדי למנוע בעיות עם תווים מיוחדים.
```
const encodedUrl = encodeURIComponent(
  'https://adtech.example/attribution_source?ad_id=...');
window.open(
  "https://shoes.example/landing",
  "_blank",
  attributionsrc=${encodedUrl});
```

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

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

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

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

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

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

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

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

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

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

איסוף נתונים

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

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

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

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

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

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

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

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

דוחות נצברים מרובים

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

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

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

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

Aggregation Service

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

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

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

מה השלב הבא?

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

לדון ב-API

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

התנסות עם ה-API

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