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

שליחת משוב

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

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

סקירה כללית

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

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

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

Attribution Reporting API תומך בתרחישים הבאים לדוגמה:

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

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

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

איך מקבלים גישה לממשקי Attribution Reporting API

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

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

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

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

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

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

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

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

אפשר גם שהתשובה של המטא-נתונים של מקור השיוך תכלול נתונים נוספים בכותרת Attribution reporting redirects. הנתונים מכילים כתובות 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 מקור השיוך (Attribution) והטריגר לרישום מ-WebView לקבלת הוראות לאפליקציות.

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

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

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

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

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

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

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

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

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

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

  1. ה-SDK של AdTech מבצע קריאה ל-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 Reporting API טריגרים של המרות למקורות של שיוך.

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

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

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

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

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

מסנני הפעלה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ברשימה הבאה יש עוד כמה הערות לגבי ההתקנה לאחר ההתקנה. Attribution:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקורות שיוך

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

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

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

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

טריגרים

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

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

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

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

  • המשתמש מבצע את אותה פעולה (טריגר) כמה פעמים. לדוגמה, המשתמש מעיין באותו מוצר מספר פעמים באותו דיווח חלון.
  • האפליקציה למפרסם משתמשת בכמה ערכות SDK למעקב המרות, כל ההפניות מפנות לאותה טכנולוגיית פרסום. לדוגמה, אפליקציית המפרסם משתמשת בשני שותפי מדידה, MMP #1 ו-MMP #2. שתי פלטפורמות ה-MMP מפנות אוטומטית לטכנולוגיית הפרסום מס' 3. כשמתרחש טריגר, שני מנהלי ה-MMP רושמים אותם ב-Attribution Reporting API. לאחר מכן, מערכת טכנולוגיית הפרסום מס' 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 גם במפתחות הצבירה שלהן.

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

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

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

הרשימה הבאה מציגה סדרה היפותטית של פעולות משתמש, שכל אחת מהן יתרחשו יום אחד בנפרד, והאופן שבו Attribution Reporting API מטפל בפעולות האלה בכל הנוגע לטכנולוגיות פרסום א', פרסום דיגיטלי ב' ו-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 תגובת השרת.

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

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

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

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

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

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

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

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

כך מתבצע השיוך:

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

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

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

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

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

הרשמה של מקור

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

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

רישום טריגר

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

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

שיוך (Attribution)

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

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

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

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

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

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

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

ניפוי באגים

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

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

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

גילוי מרכזי לשיוך חוצה-רשתות ללא הפניות לכתובת אחרת

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

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

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

בעקבות ההשקה של חשיפת מפתחות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המקור השני, למקור הדיווח 2 של חברת AdTech A, יידחה על ידי ה-API. מקור הדיווח 2 של חברת AdTech A לא יוכל לרשום מקור באותו מכשיר באפליקציה B עד ליום הבא.

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

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

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

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

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

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

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

רמת דיוק מוגבלת של נתוני הטריגר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגמישות הנוספת הזו תיכלל בדוח השיוך API בשני שלבים:

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

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

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

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

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

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

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

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

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

דוחות נצברים

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

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

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

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

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

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

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

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

שירותי צבירת נתונים

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

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

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

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

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

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

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

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

שירות ניהול מפתחות (KMS)

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

דיווח על דוחות עם נתונים מצטברים

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

Reports API עם אפשרות צבירת נתונים

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

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

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

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

מפתח הקטגוריה הסופי של ההיסטוגרמה מוגדר במלואו בזמן ההפעלה, על ידי ביצוע פעולת 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, עם השדות הבאים לכל מפתח צבירה ברשימה:

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

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

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

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

בדוגמה הבאה, תקציב הפרטיות מחולק באופן שווה בין 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 שונים בדוחות השיוך (Attribution) ו-Protected Audience API ממשקי API מאפשרים לטכנולוגיות הפרסום להעריך את ביצועי השיוך שלהן לשיטות רימרקטינג כדי להבין אילו סוגי קהלים מספקים את החזר ה-ROI הגבוה ביותר.

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

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

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

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

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

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

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

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

נניח שמשתמש מבצע את הפעולות הבאות:

  1. המשתמש רואה מודעה. טכנולוגיית הפרסום רושמת מקור שיוך באמצעות ה-API, עם עדיפות של 0 (צפייה מס' 1).
  2. המשתמש רואה מודעה, שרשומה עם רמת תעדוף 0 (צפייה מס' 2).
  3. המשתמש לוחץ על מודעה שרשומה בעדיפות 1 (קליק 1).
  4. המשתמש משלים המרה (מגיעים לדף נחיתה) באפליקציה של מפרסם. טכנולוגיית הפרסום רושמת טריגר באמצעות ה-API, עם עדיפות של 0 (המרה מס' 1).
    • לאחר רישום הטריגרים, ה-API מבצע את השיוך קודם לפני יצירת דוחות.
    • יש 3 מקורות שיוך (Attribution): תצוגה מס' 1, צפייה 2 ו לוחצים על 'מספר 1'. ה-API משייך את הטריגר הזה לקליק מס' 1 כי בעדיפות הגבוהה ביותר והעדכנית ביותר.
    • צפייה מס' 1 ותצוגה מספר 2 נמחקו, והן לא עומדות בדרישות בעתיד Attribution.
  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.
    • כל 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) ללא מזהים חוצי-אפליקציות. לכן, אנחנו תומכים במנגנון המעבר כדי לקבל מידע נוסף על דוחות שיוך (Attribution) כאשר מזהה הפרסום זמין (המשתמש לא ביטל את ההסכמה להתאמה אישית באמצעות מזהה הפרסום, והאפליקציה של בעל התוכן הדיגיטלי או האפליקציה של המפרסם הצהירה על מזהה הפרסום הרשאות). כך אפשר להבטיח שה-API יהיה מובן במלואו להשיק, לעזור בניקוי באגים כלשהם ולהשוות בקלות רבה יותר את הביצועים אלטרנטיבות שמבוססות על מזהי הפרסום. יש שני סוגים של דוחות ניפוי באגים: attribution-success ו-verbose.

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

דוחות ניפוי באגים בהצלחה

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

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

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

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

דוחות מפורטים של ניפוי באגים מאפשרים למפתחים לעקוב אחרי כשלים מסוימים את מקור הייחוס או את ההפעלה של הרשמות. דוחות ניפוי הבאגים האלה נשלחים עם עיכוב מוגבל אחרי שמקור השיוך או הטריגרים של הרישום נשלחים אל .נקודת קצה (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) לאפליקציות שהועמסו מראש או לאפליקציות שהותקנו מחדש?