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

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

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

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

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

למי המסמך הזה מיועד?

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

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

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

סקירה כללית

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

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

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

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

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

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

החלטות עיצוב

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

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

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

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

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

אחרי שתחליטו מה אתם רוצים למדוד, תוכלו להגדיר את 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}`);
   

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

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

   

4. בהמשך, המשתמש מבקר באתר של המפרסם.

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

איסוף נתונים

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

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

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

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

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

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

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

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

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

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

Aggregation Service

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות ב-API

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