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

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

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

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

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

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

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

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

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

סקירה כללית

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

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

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

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

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

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

החלטות עיצוב

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

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

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

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

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

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

תקשורת בין האתר לדפדפן

תהליך האירועים של השיוך (Attribution)

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

1. באתר של בעלי התוכן הדיגיטלי, רכיב מודעה (תג <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});
   

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

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

   

3. בהמשך, המשתמש נכנס לאתר של המפרסם.

4. בכל דף רלוונטי באתר המפרסם – לדוגמה, דף אישור רכישה או דף מוצר – פיקסל המרה (רכיב <img>) או קריאה ל-JavaScript שולחים בקשה אל https://adtech.example/conversion?param1=...&param2=....

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

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

7. הדפדפן מתזמן שליחת דוח אל attributionsrc. הדוח הזה כולל:

   1. נתוני ההגדרה של השיוך בהתאמה אישית שסופקו על ידי ספק טכנולוגיית הפרסום או המפרסם וצורפו לאירוע המקור בשלב 3.
   2. נתוני ההמרות בהתאמה אישית שהוגדרו בשלב 6.

   

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

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

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

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

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

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

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

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

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

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

איסוף נתונים

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

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

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

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

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

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

דוחות מצטברים בקבוצות

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

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

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

Aggregation Service

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות ב-API

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