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

שליחת משוב

עדכונים אחרונים

  • רשימת השינויים הקרובים והבעיות הידועות עודכנה
  • הוספנו הגדרות Lite גמישות ברמת האירוע, כגשר להגדרה מלאה ברמת האירוע הגמישה
  • החל מספטמבר 2023, השדות registerWebSource, registerWebTrigger, registerAppSource ו-registerAppTrigger חייבים להשתמש במחרוזות לשדות שזקוקים לערך מספרי (כמו priority, source_event_id, debug_key, trigger_data, deduplication_key וכו').
  • ברבעון הרביעי של שנת 2023, נוסיף תמיכה ב-Android Attribution Reporting API כדי ליצור דוחות סיכום באמצעות שירות צבירה ב-Google Cloud, ותזמון ספציפי יותר מופיע כאן. מידע נוסף על הגדרת שירות צבירה ב-Google Cloud זמין במדריך הפריסה.
  • הגבלות חדשות על מספר היעדים הייחודיים במסגרת ההגנה על הפרטיות.
  • פונקציונליות מעודכנת של מסננים להפעלת חלון מבט לאחור יהיו זמינים ברבעון הראשון של 2024. מידע נוסף זמין בהערה.

סקירה כללית

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

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

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

ב-Attribution Reporting API יש תמיכה בתרחישים הבאים:

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

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

  1. טכנולוגיית המודעות משלים תהליך רישום לשימוש ב-Attribution Reporting API.
  2. טכנולוגיית המודעות רושמת את מקורות השיוך – קליקים או צפיות במודעות – באמצעות Attribution Reporting API.
  3. טכנולוגיית הפרסום רושמת טריגרים – המרות שמשתמשים מבצעים באפליקציה או באתר של המפרסם – באמצעות Attribution Reporting API.
  4. ב-Attribution Reporting API המערכת מתאימה טריגרים למקורות שיוך (Attribution) של המרות. טריגר אחד או יותר נשלחים מחוץ למכשיר באמצעות דוחות ברמת האירוע ודוחות נצברים לטכנולוגיות הפרסום.

קבלת גישה לממשקי Attribution Reporting API

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

רישום מקור שיוך (קליק או הצגה)

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

  • URI של מקור השיוך: הפלטפורמה שולחת בקשה ל-URI הזה כדי לאחזר מטא-נתונים שמשויכים למקור השיוך.
  • אירוע קלט: אובייקט InputEvent (עבור אירוע מסוג קליק) או null (לאירוע של צפייה).

כשה-API שולח בקשה ל-URI של מקור השיוך, טכנולוגיית המודעות צריכה להגיב למטא-נתונים של מקור השיוך בכותרת HTTP חדשה Attribution-Reporting-Register-Source, עם השדות הבאים:

  • מזהה אירוע מקור: הערך הזה מייצג את הנתונים ברמת האירוע המשויכים למקור השיוך הזה (קליק על מודעה או צפייה במודעה). חייב להיות מספר שלם לא חתום ב-64 ביט בפורמט של מחרוזת.
  • Destination: מקור שדומיין eTLD+1 שלו או שם חבילת האפליקציה שבו מתרחש אירוע הטריגר.
  • תאריך תפוגה (אופציונלי): תפוגה, בשניות, לתאריך שבו יש למחוק את המקור מהמכשיר. ברירת המחדל היא 30 יום, וערך מינימלי של יום אחד וערך מקסימלי של 30 יום. הערך יעוגל ליום הקרוב ביותר. אפשר להגדיר אותו כמספר שלם ללא סימן או כמחרוזת של 64 ביט.
  • חלון דוח אירועים (אופציונלי): משך הזמן בשניות אחרי רישום המקור, שבמהלכו ניתן ליצור דוחות אירועים עבור המקור הזה. אם חלון דוח האירועים חלף אבל התפוגה עדיין לא חלף, עדיין ניתן להתאים טריגר למקור, אבל לא נשלח דוח אירועים לטריגר הזה. לא יכול להיות גדול מ-Exppiry. אפשר להיות בפורמט של מספר שלם ללא חתימה או מחרוזת של 64 ביט.
  • חלון דוח מצטבר (אופציונלי): משך הזמן בשניות אחרי רישום המקור, שבמהלכו אפשר ליצור דוחות מצטברים עבור המקור הזה. לא יכול להיות גדול מ-Exppiry. יכול להיות בפורמט של מספר שלם לא חתום או כמחרוזת של 64 ביט.
  • Source origin (אופציונלי): השירות משמש לבחירת מקור השיוך שאליו ישויך טריגר נתון, במקרה שאפשר לשייך לטריגר כמה מקורות נתונים. חייב להיות מספר שלם חתום ב-64 ביט בפורמט של מחרוזת.

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

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

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

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

השלבים הבאים מציגים תהליך עבודה לדוגמה:

  1. ה-SDK של הפרסום הדיגיטלי מפעיל את ה-API כדי להתחיל רישום של מקור שיוך, ומגדיר URI שה-API יקרא:

    registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);

  2. ה-API שולח בקשה אל https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA באמצעות אחת מהכותרות הבאות:

    <!-- For click events -->
Attribution-Reporting-Source-Info: navigation

<!-- For view events -->
Attribution-Reporting-Source-Info: event

  3. שרת ה-HTTPS של טכנולוגיית המודעות הזו משיב בכותרות שכוללות:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

  4. ה-API שולח בקשה לכל כתובת URL שצוינה ב-Attribution-Reporting-Redirect. בדוגמה הזו מפורטות שתי כתובות URL של שותפי פרסום דיגיטלי, ולכן ה-API שולח בקשה אחת אל https://adtechpartner1.example?their_ad_click_id=567 ובקשה נוספת אל https://adtechpartner2.example?their_ad_click_id=890.

  5. שרת ה-HTTPS של טכנולוגיית המודעות הזו משיב בכותרות שכוללות:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}

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

רישום מקור שיוך מ-WebView

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

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

רישום טריגר (המרה)

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

השיטה registerTrigger() מצפה לפרמטר Trigger URI. ה-API מנפיק בקשה ל-URI הזה לאחזור מטא-נתונים המשויכים לטריגר.

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

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

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

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

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

השלבים הבאים מציגים תהליך עבודה לדוגמה:

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

    registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));

  2. ה-API שולח בקשה אל https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

  3. שרת ה-HTTPS של טכנולוגיית המודעות הזו משיב בכותרות שכוללות:

    Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

  4. ה-API שולח בקשה לכל כתובת URL שצוינה ב-Attribution-Reporting-Redirect. בדוגמה הזו, רק כתובת URL אחת צוינה, ולכן ה-API שולח בקשה אל https://adtechpartner.example?app_install=567.

  5. שרת ה-HTTPS של טכנולוגיית המודעות הזו משיב בכותרות שכוללות:

    Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}

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

יכולות שיוך (Attribution)

בקטעים הבאים מוסבר איך Attribution Reporting API מתאים בין טריגרים של המרות לבין מקורות של שיוך.

הוחל אלגוריתם השיוך עם תעדוף המקור

ב-Attribution Reporting API נעשה שימוש באלגוריתם שיוך לפי תעדוף לפי מקור כדי להתאים טריגר (המרה) למקור שיוך.

פרמטרים של עדיפות מספקים דרכים להתאמה אישית של השיוך של טריגרים למקורות:

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

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

מסנני טריגר

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

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

כדי לסנן טריגרים באופן סלקטיבי, טכנולוגיית הפרסום יכולה להגדיר נתוני סינון, כולל מפתחות וערכים, במהלך רישום המקור והטריגר. אם אותו מפתח מצוין גם למקור וגם לטריגר, המערכת מתעלמת מהטריגר אם הצומת ריק. לדוגמה, מקור יכול לציין "product": ["1234"], כאשר product הוא מפתח המסנן ו-1234 הוא הערך. אם מסנן הטריגר מוגדר לערך "product": ["1111"], המערכת תתעלם מהטריגר. אם אין מפתח סינון טריגרים שתואם ל-product, המערכת מתעלמת מהמסננים.

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

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

פלטפורמות פרסום דיגיטלי יכולות גם לבחור את נתוני הטריגר על סמך נתוני האירועים במקור. לדוגמה, ה-API יוצר באופן אוטומטי את source_type בתור navigation או event. במהלך רישום הטריגר, אפשר להגדיר את trigger_data כערך אחד עבור "source_type": ["navigation"] וכערך אחר ל-"source_type": ["event"].

הטריגרים לא נכללים בדוחות ברמת האירוע אם מתקיים אחד מהתנאים הבאים:

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

שיוך אחרי התקנה

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

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

  • כשרושמים מקור שיוך, צריך לציין חלון שיוך להתקנה שבמהלכו צפויות ההתקנות (בדרך כלל 2-7 ימים, טווח מקובל 1 עד 30 ימים). צריך להגדיר את חלון הזמן הזה כמספר של שניות.
  • כשרושמים מקור שיוך, צריך לציין חלון בלעדיות לשיוך אחרי ההתקנה שבו צריך לשייך את כל אירועי ההפעלה לאחר ההתקנה למקור השיוך שהוביל להתקנה (בדרך כלל 7 עד 30 ימים, טווח הקביל של 0 עד 30 ימים). צריך לציין את חלון הזמן הזה כמספר של שניות.
  • Attribution Reporting API בודק מתי מתבצעת התקנה של האפליקציה, ומשייך באופן פנימי את ההתקנה למקור השיוך בעדיפות גבוהה. עם זאת, ההתקנה לא נשלחת לטכנולוגיות הפרסום ולא נספרת במגבלות הקצב של יצירת בקשות בהתאם לפלטפורמות.
  • אימות התקנת אפליקציה זמין לכל אפליקציה שהורדתם.
  • טריגרים עתידיים שיתרחשו במהלך חלון השיוך לאחר ההתקנה משויכים לאותו מקור שיוך כמו ההתקנה המאומתת, כל עוד מקור השיוך הזה עומד בדרישות.

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

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

אירוע היום שבו מתרחש האירוע הערות
קליק 1 1 הערך של install_attribution_window מוגדר ל-172800 (יומיים), והערך post_install_exclusivity_window מוגדר ל-864000 (10 ימים)
התקנה מאומתת 2 ה-API משייך באופן פנימי התקנות מאומתות, אבל ההתקנות האלה לא נחשבות לטריגרים. לכן לא יישלחו דוחות בשלב הזה.
טריגר 1 (פתיחה ראשונה) 2 הטריגר הראשון שנרשם על ידי טכנולוגיית המודעות. בדוגמה הזו, הוא מייצג פתיחה ראשונה, אבל יכול להיות כל סוג של טריגר.
מיוחס לקליק 1 (תואם לשיוך של התקנה המאומתת).
קליק 2 4 משתמשת באותם ערכים עבור install_attribution_window ועבור post_install_exclusivity_window כמו של 'קליק 1'
טריגר 2 (לאחר התקנה) 5 הטריגר השני שנרשם על ידי טכנולוגיית פרסום. בדוגמה הזו, הוא מייצג המרה אחרי ההתקנה, כמו רכישה.
מיוחס לקליק 1 (תואם לשיוך של התקנה המאומתת).
הקליק 2 נמחק ולא עומד בדרישות לשיוך בעתיד.

פירטנו כאן כמה הערות נוספות לגבי שיוך אחרי ההתקנה:

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

יש תמיכה בכל השילובים של נתיבי הפעלה מבוססי-אפליקציה ומבוססי אינטרנט

Attribution Reporting API מאפשר שיוך של נתיבי הטריגר הבאים במכשיר Android יחיד:

  • App-to-app: המשתמש רואה מודעה באפליקציה, ולאחר מכן מבצע המרה באפליקציה הזו או באפליקציה אחרת שמותקנת.
  • App-to-web: המשתמש רואה מודעה באפליקציה, ולאחר מכן מבצע המרה בדפדפן בנייד או באפליקציה.
  • Web-to-app: המשתמש רואה מודעה בדפדפן בנייד או באפליקציה, ולאחר מכן מבצע המרה באפליקציה.
  • Web-to-web: המשתמש רואה מודעה בדפדפן בנייד או באפליקציה, ולאחר מכן משלים המרה באותו דפדפן או בדפדפן אחר באותו מכשיר.

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

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

קביעת עדיפות לטריגרים מרובים למקור שיוך יחיד

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

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

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

מאפשרים למספר טכנולוגיות פרסום לרשום מקורות שיוך או טריגרים

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

מפרסמים שרוצים להשתמש בצד שלישי כדי לבצע ביטול כפילויות חוצה-פלטפורמות יכולים להמשיך לעשות זאת באמצעות שיטה שדומה לזו:

  • הגדרת שרת פנימי לרישום ולקבל דוחות מה-API.
  • המשך השימוש בשותף קיים למדידת ביצועים בנייד.

מקורות שיוך (Attribution)

הפניות אוטומטיות ממקור שיוך נתמכות בשיטה registerSource():

  1. טכנולוגיית המודעות שקוראת לשיטה registerSource() יכולה לספק בתגובה שדה Attribution-Reporting-Redirect נוסף, שמייצג את קבוצת כתובות ה-URL להפניה אוטומטית של טכנולוגיות הפרסום של השותפים.
  2. לאחר מכן, ה-API קורא לכתובות ה-URL להפניה אוטומטית, כדי שטכנולוגיות הפרסום של השותפים יוכלו לרשום את מקור השיוך.

בשדה Attribution-Reporting-Redirect אפשר לציין כמה כתובות URL של טכנולוגיות פרסום של שותפים, וטכנולוגיות פרסום של שותפים לא יכולות לציין את שדה Attribution-Reporting-Redirect משלהן.

ה-API גם מאפשר טכנולוגיות פרסום שונות לכל קריאה ל-registerSource().

טריגרים

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

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

טיפול בטריגרים כפולים

טכנולוגיית פרסום עשויה לרשום את אותו טריגר כמה פעמים באמצעות ה-API. בתרחישים נכללים:

  • המשתמש מבצע את אותה פעולה (טריגר) כמה פעמים. לדוגמה, המשתמש גולש באותו מוצר כמה פעמים באותו חלון דיווח.
  • באפליקציית המפרסם נעשה שימוש בכמה ערכות SDK למעקב המרות, שמפנות כולן לאותה טכנולוגיית פרסום. לדוגמה, באפליקציית המפרסם נעשה שימוש בשני שותפי מדידה, MMP #1 ו-MMP #2. שני רכיבי ה-MMP מופנים לטכנולוגיית מודעות מס' 3. כשמתרחש טריגר, שני סוגי ה-MMP רושמים אותם ב-Attribution Reporting API. לאחר מכן, טכנולוגיית Ad Tech מס' 3 מקבלת שתי הפניות נפרדות – אחת מ-MMP #1 ואחת מ-MMP #2 – לאותו טריגר.

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

שיטה מומלצת: מפתח לביטול כפילויות

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

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

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

שיטה חלופית: טכנולוגיות הפרסום מסכמות לגבי סוגי הטריגרים לכל מפרסם

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

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

דוגמה לשיוך חוצה-פלטפורמות

בדוגמה שמתוארת בקטע הזה, המפרסם משתמש בשתי פלטפורמות של פרסום דיגיטלי (Ad tech A ו-Ad tech B) ובשותף אחד למדידת ביצועים (MMP).

כדי להתחיל להשתמש ב-Attribution Reporting API, צריך לבצע את כל הפעולות שנדרשות כדי להתחיל להשתמש ב-Ad Tech A, Ad tech B ו-MMP. למידע נוסף, ראו הרשמה לחשבון של ארגז חול לפרטיות.

ברשימה הבאה מוצגת סדרה היפותטית של פעולות משתמשים, שכל אחת מהן מתרחשת בהפרש של יום, והאופן שבו Attribution Reporting API מטפל בפעולות האלה ביחס ל-Ad tech A, Ad tech B ו-MMP:

יום 1: משתמש לוחץ על מודעה שהוצגה על ידי טכנולוגיית פרסום א'

טכנולוגיית פרסום א' מפעילה את registerSource() באמצעות ה-URI שלה. ה-API שולח בקשה ל-URI, והקליק רשום עם המטא-נתונים מתגובת השרת של Ad Tech A.

טכנולוגיית הפרסום א' כוללת גם את ה-URI של MMP בכותרת Attribution-Reporting-Redirect. ה-API שולח בקשה ל-URI של ה-MMP, והקליק נרשם עם המטא-נתונים מתגובת השרת של ה-MMP.

יום 2: משתמש לוחץ על מודעה שהוצגה על ידי טכנולוגיית פרסום ב'

טכנולוגיית מודעה ב' מתקשרת אל registerSource() עם ה-URI שלה. ה-API שולח בקשה ל-URI, והקליק נרשם עם המטא-נתונים מתגובת השרת של Ad tech B.

בדומה ל-Ad tech א', ה-URI של ה-MMP של Ad tech B כולל גם את ה-URI של ה-MMP בכותרת Attribution-Reporting-Redirect. ה-API שולח בקשה ל-URI של ה-MMP, והקליק נרשם עם המטא-נתונים מתגובת השרת של ה-MMP.

יום 3: משתמש צופה במודעה שהוצגה על ידי טכנולוגיית פרסום א'

ה-API מגיב באותו אופן כמו ביום הראשון, מלבד העובדה שצפייה רשומה עבור Ad Tech A ו-MMP.

יום 4: המשתמש מתקין את האפליקציה, שמשתמשת ב-MMP למעקב המרות

רכיב ה-MMP מבצע קריאה אל registerTrigger() באמצעות ה-URI שלו. ה-API שולח בקשה לכתובת ה-URL, וההמרה רשומה עם המטא-נתונים מתגובת השרת של ה-MMP.

MMP כולל גם את מזהי ה-URI של Ad tech A ו-Ad tech B בכותרת Attribution-Reporting-Redirect. ה-API שולח בקשות לשרתים של Ad Tech A ו-Ad tech B, וההמרה מתועדת בהתאם עם המטא-נתונים מהתגובות של השרת.

התרשים הבא ממחיש את התהליך המתואר ברשימה הקודמת:

דוגמה לאופן שבו Attribution Reporting API מגיב לסדרה של פעולות משתמשים.

השיוך פועל כך:

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

שיוך (Attribution) חוצה-רשתות ללא הפניות אוטומטיות

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

זרימה ברמה גבוהה

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

רישום מקור

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

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

רישום הפעלה

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

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

שיוך (Attribution)

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

  • המשתמש לחץ על המודעות שהוצגו על ידי טכנולוגיות המודעות א', ב', ג' וד'. לאחר מכן המשתמש התקין את האפליקציה של המפרסם, שמשתמשת בשותף מדידה של טכנולוגיות פרסום (MMP).
  • טכנולוגיית הפרסום א' מפנה את המקורות שלה ל-MMP.
  • טכנולוגיות הפרסום ב' ו-ג' לא מבצעות הפניה אוטומטית, אלא משתפות את מפתחות הצבירה שלהן.
  • Ad Tech D לא מפנה לכתובת אחרת ולא משתפת מפתחות צבירה.

ה-MMP רושם מקור מ-Ad tech A, ומגדיר הגדרת שיוך (Attribution) שכוללת את Ad tech B ואת Ad tech D.

השיוך של ה-MMP כולל עכשיו:

  • טכנולוגיית פרסום א', כי ה-MMP רשם מקור מההפניה האוטומטית הזו של טכנולוגיית המודעות.
  • Ad Tech B, מאחר ש-Ad tech B שיתפה מפתחות וה-MMP כללו אותה בהגדרת השיוך שלהם.

השיוך של ה-MMP לא כולל:

  • Ad Tech C, כי ה-MMP לא כלל אותו בהגדרת השיוך שלו.
  • Ad tech D, כי הם לא הפנו לכתובת אחרת ולא שיתפו מפתחות צבירה.

ניפוי באגים

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

בתרחישים הבאים תהיה תמיכה בתכונה הזו לניפוי באגים רק בשיוך חוצה-פלטפורמות, ללא הפניות לכתובת אחרת:

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

גילוי מפתח עבור שיוך חוצה-פלטפורמות ללא הפניות מחדש

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

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

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

אחרי ההשקה של גילוי מפתחות:

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

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

הצגת נתוני מדידה בדוחות שיוך (Attribution)

Attribution Reporting API מאפשר להפעיל את סוגי הדוחות הבאים, שמתוארים בפירוט בהמשך הדף:

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

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

דוחות ברמת האירוע

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

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

הדוח ברמת האירוע מכיל נתונים כמו:

  • יעד: שם החבילה של אפליקציית המפרסם או eTLD+1 שבו התרחש הטריגר
  • מזהה מקור ייחוס: אותו מזהה מקור ייחוס ששימש לרישום מקור ייחוס
  • Trigger type (סוג הטריגר): סיביות של 1 או 3 סיביות של נתוני טריגרים ברמת דיוק נמוכה, בהתאם לסוג מקור השיוך (Attribution)

מנגנונים להבטחת שמירה על הפרטיות שחלים בכל הדוחות

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

מגבלות על מספר טכנולוגיות הפרסום

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

  • 100 טכנולוגיות של מודעות עם מקורות שיוך לכל {source app, destination app, 30 days, device}.
  • 10 טכנולוגיות של מודעות עם טריגרים משויכים לכל {source app, destination app, 30 days, device}.
  • 20 טכנולוגיות של מודעות יכולות לרשום מקור שיוך אחד או טריגר אחד (באמצעות Attribution-Reporting-Redirect)

מגבלות על מספר היעדים הייחודיים

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

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

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

מקור דיווח אחד לכל אפליקציית מקור ביום

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

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

  1. המקור המדווח 1 של Ad Tech A רושם מקור באפליקציה ב'
  2. 12 שעות לאחר מכן, המקור המדווח של טכנולוגיית הפרסום א' מנסה לרשום מקור באפליקציה ב'

המקור השני, מקור הדיווח 2 של טכנולוגיות הפרסום, יידחה על ידי ה-API. לא ניתן יהיה לרשום מקור מדווח 2 באותו מכשיר באפליקציה ב' עד היום הבא, שמקור הדיווח 2 של Ad tech Tech.

תקופת צינון ומגבלות קצב

כדי להגביל את כמות הדליפה של זהות משתמש בין צמד {source, destination}, ה-API מווסת את כמות המידע הכולל שנשלח למשתמש בתקופת זמן נתונה.

ההצעה הנוכחית היא להגביל כל פרסום דיגיטלי ל-100 טריגרים משויכים לכל {source app, destination app, 30 days, device}.

מספר היעדים הייחודיים

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

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

מנגנונים לשמירה על הפרטיות שהוחלו על דוחות ברמת האירוע

דיוק מוגבל של נתוני הפעלה

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

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

מסגרת לרעש על פרטיות דיפרנציאלית

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

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

התגובה האקראית עם k היא אלגוריתם שהוא אפסילון פרטי דיפרנציאלי אם מתקיים המשוואה הבאה:

\[ p = \frac{k}{k + e^ε - 1} \]

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

  • p=0.24% למקורות ניווט
  • p=0.00025% למקורות אירועים

מגבלות על טריגרים זמינים (המרות)

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

  • 1-2 טריגרים למקורות השיוך של צפייה במודעה (2 טריגרים זמינים רק במקרה של שיוך (Attribution) לאחר ההתקנה)
  • 3 טריגרים למעקב אחרי קליקים על מקורות של מודעות לטירגוט

חלונות זמן ספציפיים לשליחת דוחות (התנהגות ברירת המחדל)

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

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

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

הגדרה גמישה ברמת האירוע

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

הגמישות הנוספת הזו תושק ב-Attribution Reporting API בשני שלבים:

  • שלב 1: הגדרה גמישה ברמת האירוע
    • הגרסה הזו מספקת חלק מהתכונות של החבילה, ואפשר להשתמש בה בנפרד משלב 2.
  • שלב 2: גרסה מלאה של הגדרה גמישה ברמת האירוע

אפשר להשתמש בשלב 1 (רמת אירוע גמיש Lite) כדי:

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

אפשר להשתמש בשלב 2 (רמת האירוע הגמיש המלא) כדי לבצע את כל היכולות בשלב 1, וגם:

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

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

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

  • עד 20 דוחות בסך הכול, גלובלי ולכל trigger_data
  • עד 5 חלונות דיווח אפשריים לכל trigger_data
  • עד 32 עוצמה (cardinality) של נתוני טריגר (לא רלוונטי לשלב 1: Lite ברמת האירוע הגמישה)

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

דוחות נצברים

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

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

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

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

המבנה הכללי של האופן שבו Attribution Reporting API מכין ושולח דוחות נצברים (כפי שמוצג בתרשים), הוא:

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

דוחות נצברים כוללים את הנתונים הבאים שקשורים למקורות שיוך:

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

שירותי צבירה

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

השירותים האלה מנוהלים על ידי גורמים שונים, כפי שמתואר בפירוט בהמשך הדף:

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

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

שירות הצבירה הזה פועל בסביבת ביצוע מהימנה (TEE) בענן. סביבת TEE מציעה את יתרונות האבטחה הבאים:

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

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

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

שירות ניהול מפתחות

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

חשבונאות נצברת

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

Aggregatable Reports API

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

רישום נתוני המקור המצטברים

כש-API שולח בקשה ל-URI של מקור השיוך, טכנולוגיית המודעות יכולה לרשום רשימה של מפתחות צבירה בשם histogram_contributions, על ידי תגובה עם שדה חדש שנקרא aggregation_keys בכותרת ה-HTTP Attribution-Reporting-Register-Source, עם מפתח בתור key_name והערך key_piece:

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

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

המפתחות הסופיים מוגבלים ל-128 ביט לכל היותר. מפתחות ארוכים יותר, חתוכים. כלומר, מחרוזות הקסדצימליות ב-JSON יכולות להיות מוגבלות ל-32 ספרות לכל היותר.

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

בדוגמה הבאה, טכנולוגיית פרסום משתמשת ב-API כדי לאסוף את הנתונים הבאים:

  • מספרים מצטברים של המרות ברמת הקמפיין
  • ערכי רכישה מצטברים ברמה גיאוגרפית
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

רישום הטריגר המצטבר

רישום הטריגר כולל שני שדות נוספים.

השדה הראשון משמש לרישום רשימה של מפתחות מצטברים בצד הטריגר. נציג טכנולוגיות הפרסום אמור להגיב באמצעות השדה aggregatable_trigger_data בכותרת ה-HTTP Attribution-Reporting-Register-Trigger, עם השדות הבאים לכל מפתח צבירה ברשימה:

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

השדה השני משמש לרישום רשימת ערכים שצריכים לתרום לכל מפתח. טכנולוגיית הפרסום צריכה להגיב באמצעות השדה aggregatable_values בכותרת ה-HTTP Attribution-Reporting-Register-Trigger. השדה השני משמש לרישום רשימת ערכים שאמורים לתרום לכל מפתח, שיכולים להיות מספרים שלמים בטווח $ [1, 2^{16}] $.

כל טריגר יכול להוסיף כמה תכנים לדוחות המצטברים. הסכום הכולל של התרומות לכל אירוע מקור נתון מחויב בפרמטר $ L1 $, שהוא הסכום המקסימלי של תרומות (ערכים) בכל המפתחות המצטברים של מקור נתון. $ L1 $ מתייחס לרגישות או לנורמה של L1 של תרומות ההיסטוגרמה לכל אירוע מקור. חריגה מהמגבלות האלה גורמת להפסקה שקטה של תכנים עתידיים. ההצעה הראשונית היא להגדיר את $ L1 $ ל- $ 2^{16} $ (65536).

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

בדוגמה הבאה, תקציב הפרטיות מחולק באופן שווה בין campaignCounts לבין geoValue על ידי פיצול התרומה של $ L1 $ לכל אחד מהם:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

הדוגמה הקודמת יוצרת את התרומות הבאות להיסטוגרמה:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

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

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

פרטיות דיפרנציאלית

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

\[ Laplace(\frac{L1}{ε}) \]

שילוב של Protected Audience API ו-Attribution Reporting API

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

באמצעות השילוב בין ה-API הזה, טכנולוגיות הפרסום יכולות:

  • יוצרים מפת מפתח/ערך של מזהי URI שאפשר להשתמש בה גם 1) לדיווח על אינטראקציה וגם 2) לרישום מקור.
  • כוללים את CustomAudience במיפוי המפתח בצד המקור לדיווח מצטבר של סיכום (באמצעות Attribution Reporting API).

כשמשתמש רואה מודעה או לוחץ עליה:

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

למידע נוסף על אופן ההפעלה של האפשרות הזו ב-Protected Audience API, קראו את הקטע הרלוונטי בהסבר בנושא Protected Audience API.

עדיפות רישום, ייחוס ודוגמאות לדיווח

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

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

חשוב להביא בחשבון את המקרים שבהם המשתמש מבצע את הפעולות הבאות:

  1. המשתמש רואה מודעה. טכנולוגיית הפרסום רושמת מקור שיוך באמצעות ה-API, עם עדיפות של 0 (תצוגה מס' 1).
  2. המשתמש רואה מודעה שרשומה בעדיפות של 0 (תצוגה מפורטת 2).
  3. המשתמש לוחץ על מודעה שרשומה בעדיפות של 1 (קליק מס' 1).
  4. המשתמש משלים המרה (מגיע לדף הנחיתה) באפליקציה של מפרסם. טכנולוגיית הפרסום רושמת טריגר באמצעות ה-API, עם עדיפות של 0 (המרה 1).
    • כאשר הטריגרים רושמים, ה-API מבצע שיוך לפני הפקת הדוחות.
    • יש 3 מקורות זמינים של שיוך: תצוגה מס' 1, תצוגה מס' 2 ולחיצה על מס' 1. ה-API משייך את הטריגר הזה לקליק מס' 1, כי הוא העדיפות הגבוהה ביותר והעדכנית ביותר.
    • התצוגה המפורטת מס' 1 ותצוגה מפורטת 2 נמחקות ולא עומדות בדרישות יותר לשיוך בעתיד.
  5. המשתמש מוסיף פריט לעגלת הקניות באפליקציית המפרסם, עם עדיפות של 1 (המרה 2).
    • קליק 1 הוא מקור השיוך היחיד שעומד בדרישות. ה-API משייך את הטריגר הזה כדי ללחוץ על #1.
  6. המשתמש מוסיף פריט לעגלת הקניות באפליקציית המפרסם, עם עדיפות של 1 (המרה 3).
    • קליק 1 הוא מקור השיוך היחיד שעומד בדרישות. ה-API משייך את הטריגר הזה כדי ללחוץ על #1.
  7. המשתמש מוסיף פריט לעגלת הקניות באפליקציית המפרסם, עם עדיפות של 1 (המרה 4).
    • קליק 1 הוא מקור השיוך היחיד שעומד בדרישות. ה-API משייך את הטריגר הזה כדי ללחוץ על #1.
  8. המשתמש מבצע רכישה באפליקציית המפרסם, שרשומה בעדיפות של 2 (המרה 5).
    • קליק 1 הוא מקור השיוך היחיד שעומד בדרישות. ה-API משייך את הטריגר הזה כדי ללחוץ על #1.

דוחות ברמת האירוע כוללים את המאפיינים הבאים:

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

המאפיינים של דוחות נצברים הם:

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

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

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

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

  • בדוגמה שלמעלה נשלחים 5 דוחות נצברים, אחד לכל טריגר רשום.

דוחות ניפוי באגים לפי מעבר

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

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

דוחות לניפוי באגים בנושא שיוך (Attribution)

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

אם דוח נוצר עם מפתחות ניפוי באגים גם מקור וגם כטריגר, נשלח דוח ניפוי באגים כפול עם עיכוב מוגבל לנקודת קצה (endpoint) .well-known/attribution-reporting/debug/report-event-attribution. דוחות ניפוי הבאגים זהים לדוחות רגילים, כולל שני השדות של מפתח ניפוי הבאגים. הכללת המפתחות האלה בשני המפתחות מאפשרת לקשר דוחות רגילים לזרם הנפרד של דוחות ניפוי הבאגים.

  • בדוחות ברמת האירוע:
    • דוחות ניפוי באגים כפולים נשלחים בעיכוב מוגבל, ולכן הם לא מוסתרים על ידי המגבלות על הטריגרים הזמינים, וכך טכנולוגיות הפרסום יכולות להבין את ההשפעה של המגבלות האלה על דוחות ברמת האירוע.
    • דוחות ברמת האירוע שמשויכים לאירועי הפעלה FALSE לא יכללו ערכי trigger_debug_key. כך טכנולוגיות הפרסום יכולות להבין טוב יותר איך רעש מסונן ב-API.
  • בדוחות נצברים:
    • אנחנו נתמוך בשדה debug_cleartext_payload חדש שמכיל את המטען המפוענח, רק אם הוגדרו גם source_debug_key וגם trigger_debug_key.

דוחות מפורטים של ניפוי באגים

דוחות מפורטים של ניפוי באגים מאפשרים למפתחים לעקוב אחרי כשלים מסוימים במקור השיוך (Attribution) או להפעיל הרשמות. דוחות ניפוי הבאגים נשלחים בעיכוב מוגבל אחרי מקור השיוך או מפעילים הרשמות אל .נקודת קצה אחת (well-known/attribution-reporting/debug/verbose).

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

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

טכנולוגיות הפרסום צריכות להביע הסכמה כדי לקבל דוחות מפורטים על ניפוי באגים באמצעות שדה מילון debug_reporting חדש בכותרות Attribution-Reporting-Register_Source ו-Attribution-Reporting-Register-Trigger.

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

איך משתמשים בדוחות של ניפוי באגים

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

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

אם אין התאמה, יכולות להיות לכך כמה סיבות.

פועל כמתוכנן:

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

סיבות לא מכוונות:

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

שיקולים עתידיים ושאלות פתוחות

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

בנוסף, אנחנו מבקשים מהקהילה משוב על מספר נושאים:

  1. האם יש תרחישים לדוגמה שבהם אתם רוצים שה-API ישלח דוחות על ההתקנה המאומתת? הדוחות האלה ייספרו כחלק ממגבלות הקצב של יצירת המודעות בפלטפורמות של טכנולוגיות פרסום.
  2. האם צפויים קשיים כלשהם בהעברת InputEvent מהאפליקציה לטכנולוגיית הפרסום לצורך רישום המקור?
  3. האם יש לכם תרחישים מיוחדים לדוגמה של שיוך (Attribution) לאפליקציות שנטענו מראש או לאפליקציות שהותקנו מחדש?