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

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

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

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

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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

הדוח שמתקבל יכול להיות:

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

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

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

אחרי שמחליטים מה רוצים למדוד, אפשר להגדיר את הצד של הלקוח ב-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?..."/>
   

   אפשר גם להשתמש בקריאות JavaScript במקום ברכיבי HTML.

   הנה דוגמה ל-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.

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

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

איסוף נתונים

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

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

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

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

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

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

דוחות מצטברים באצווה

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

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

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

Aggregation Service

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

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

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

מה השלב הבא?

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

דיון על ה-API

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

התנסות עם ה-API

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