מדריך להטמעה באתרים ובאפליקציות של Attribution Reporting API

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

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

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

רישום מקורות וטריגרים במערכת ההפעלה Android

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

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

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

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

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

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

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

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

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

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

דוגמה

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

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

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

  1. ערכת ה-SDK לטכנולוגיית פרסום באפליקציית Daily News ל-Android רושמת את הקליק באמצעות registerSource()

  2. ‫Attribution Reporting API ב-Android שולח בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שסופקה ל-registerSource()

  3. השרת של טכנולוגיית הפרסום מגיב עם הכותרת Attribution-Reporting-Register-Source כדי להשלים את רישום המקור.

רישום של טריגרים באינטרנט:

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

  2. ה-ARA באינטרנט מחזיר מידע על הפלטפורמה הנתמכת

  3. הכותרת OS-Trigger אומרת ל-ARA API באינטרנט לקרוא לפונקציה registerWebTrigger() של ARA API במערכת ההפעלה

  4. הקריאה ל-registerWebTrigger() מתבצעת מתחת לפני השטח, והמפתח לא צריך לקרוא ל-registerWebTrigger() ישירות עם מערכת ההפעלה

  5. מערכת ההפעלה ARA משתלטת ושולחת בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שסופקה בכותרת Attribution-Reporting-Register-OS-Trigger

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

  7. ה-ARA של מערכת ההפעלה יבצע ייחוס בהתאם לאותה לוגיקה שחלה על ייחוס המרות מאפליקציה לאפליקציה, וישלח את אותם דוחות

תהליך עבודה

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

  1. טכנולוגיית הפרסום מהאפליקציה רושמת מקור ב-Attribution Reporting API של Android עם ההתאמות הבאות:

    • כדי לרשום מקור אפליקציה שאמור להמיר באתר, כותרת התגובה Attribution-Reporting-Register-Source צריכה לכלול יעד אינטרנט (eTLD+1) במקום יעד אפליקציה.
    Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
    • יכול להיות שמפרסמים מסוימים משתמשים בכמה ספקי מדידה (לדוגמה, כלי מדידה של צד שלישי או כלי ניתוח נתונים) באמצעות שרשראות של הפניות אוטומטיות מסוג 302. במקרים מסוימים, ה-API של דוחות השיוך (Attribution) יעקוב ברקע אחרי נתיב ההפניה האוטומטית שצוין בכותרת Attribution-Reporting-Redirect, ובמקביל יופעל נתיב ההפניה האוטומטית 302 בחזית עבור בקשות ניווט קיימות. הבקשות האלה יופנו לאותה כתובת URL, ויכול להיות שספק המדידה של הצד השלישי יספור את ההרשמות כפליים. כדי למנוע ספירה כפולה של הרשמות, ספקי טכנולוגיות פרסום יכולים לשנות את התנהגות ההפניה האוטומטית כדי לשלוח את ההרשמה ל-Attribution Reporting API לכתובת URL חלופית, אבל דטרמיניסטית.

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

      • הכותרת היא Attribution-Reporting-Redirect-Config
      • הערך של הכותרת צריך להיות redirect-302-to-well-known
      Attribution-Reporting-Redirect-Config: redirect-302-to-well-known

    • שאר תהליך הרישום של המקור זהה לרישום מקור רגיל של אפליקציה לאפליקציה.

  2. טכנולוגיית הפרסום באתר של המפרסם רושמת את הטריגר באמצעות בקשה מ-Chrome להעביר את הרישום אל Android Attribution Reporting API:

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

      1. אפשר להשתמש בפיקסל או בבקשת fetch() כדי לשלוח את הבקשה לרישום טריגר.

      2. כותרת הבקשה Attribution-Reporting-Support מוחזרת על ידי Chrome לספק טכנולוגיית הפרסום. אם ה-API מופעל גם בדפדפן Chrome וגם במכשיר Android, הכותרת תחזיר os, web

      Attribution-Reporting-Support: os, web

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

      1. ההגדרה הזו אומרת ל-Chrome להעביר את הרישום למערכת ההפעלה

      2. דפדפן Chrome מעביר את הרישום למערכת ההפעלה על ידי קריאה לפונקציית ה-API של מערכת ההפעלה registerWebTrigger()

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

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

      Attribution-Reporting-Register-OS-Trigger: "https://adtech.example/register-trigger",
"https://other-adtech.example/register-trigger"

    • במקרים מסוימים, הכותרת Attribution-Reporting-Support לא זמינה ואי אפשר לשלוח אותה. במקרים כאלה, טכנולוגיית הפרסום עדיין יכולה להגדיר פלטפורמה מועדפת לטיפול ברישום הטריגר על ידי הוספת הכותרת Attribution-Reporting-Info. המפתח הוא preferred-platform והערכים המותרים הם os ו-web. הדפדפן ישתמש בפלטפורמה המועדפת כשהיא תהיה זמינה, ויחזור לפלטפורמת האינטרנט אם מערכת ההפעלה לא תהיה זמינה.

    Attribution-Reporting-Info: preferred-platform=os
    • כדי להשלים את רישום הטריגר, נקודת הקצה של כלי הפרסום הדיגיטלי צריכה להשיב לבקשה של Android Attribution Reporting API באמצעות כותרת התגובה.
    Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}

רישום של מקור אינטרנט וטריגר לאפליקציה

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

דוגמה

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

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

רישום מקורות באינטרנט:

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

  2. ה-ARA באינטרנט מחזיר מידע על הפלטפורמה הנתמכת

  3. הכותרת OS-Source אומרת ל-ARA API באינטרנט לקרוא לפונקציה registerWebSource() של ARA API במערכת ההפעלה

  4. הקריאה ל-registerWebSource() מתבצעת מתחת לפני השטח, והמפתח לא צריך לקרוא ל-registerWebSource() ישירות עם מערכת ההפעלה

  5. מערכת ההפעלה ARA משתלטת ושולחת בקשה לכתובת ה-URL של שרת הטכנולוגיה הפרסומית שסופקה בכותרת Attribution-Reporting-Register-OS-Source

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

רישום טריגר של אפליקציה:

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

  2. ‫Attribution Reporting API ב-Android שולח בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שסופקה ל-registerTrigger()

  3. שרת הטכנולוגיה הפרסומית מגיב עם הכותרת Attribution-Reporting-Register-Trigger כדי להשלים את רישום הטריגר.

  4. ה-ARA של מערכת ההפעלה יבצע ייחוס בהתאם לאותה לוגיקה שחלה על ייחוס המרות מאפליקציה לאפליקציה, וישלח את אותם דוחות

תהליך עבודה

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

  1. טכנולוגיית הפרסום באתר של בעל האתר רושמת את המקור על ידי מתן הוראה ל-Chrome להעביר את הרישום ל-Android Attribution Reporting API:

    • בתרחיש שימוש של מעבר מאתר לאפליקציה, כשרושמים מקור, צריך לציין את פרמטר המקור של השיוך ישירות, באמצעות התג attributionsrc או באמצעות רישום ב-JavaScript
    • בדוגמה הבאה משתמשים בתג attributionsrc כדי לציין את פרמטר המקור:
    <img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">

  2. כותרת הבקשה Attribution-Reporting-Support מוחזרת על ידי Chrome לטכנולוגיית הפרסום. אם ה-API מופעל גם בדפדפן Chrome וגם במכשיר Android, הכותרת תחזיר os, web.

    ‫
    Attribution-Reporting-Support: os, web

  3. טכנולוגיית הפרסום צריכה להנחות את Chrome להעביר את הבקשה אל ה-API ברמת מערכת ההפעלה באמצעות הכותרת Attribution-Reporting-Register-OS-Source, שכוללת:

    1. ההגדרה הזו אומרת ל-Chrome להעביר את הרישום למערכת ההפעלה
    2. דפדפן Chrome מעביר את הרישום למערכת ההפעלה על ידי קריאה לפונקציית ה-API של מערכת ההפעלה registerWebSource()
    3. הקריאה ל-registerWebSource() מתבצעת מאחורי הקלעים, ואין צורך ש-registerWebSource() יתקשר ישירות
    4. ממשק ה-API של מערכת ההפעלה יוזם קריאה משנית ל-API ל-URI של טכנולוגיית הפרסום שהועבר מהדפדפן
    Attribution-Reporting-Register-OS-Source: "https://adtech.example/register-source"
    • במקרים מסוימים, הכותרת Attribution-Reporting-Support לא זמינה. במקרים כאלה, טכנולוגיית הפרסום עדיין יכולה להגדיר פלטפורמה מועדפת לטיפול ברישום המקור על ידי הכללת הכותרת Attribution-Reporting-Info. המפתח הוא preferred-platform והערכים המותרים הם os ו-web. הדפדפן ישתמש בפלטפורמה המועדפת כשהיא זמינה, ויחזור לפלטפורמת האינטרנט כשהמערכת ההפעלה לא זמינה.
    Attribution-Reporting-Info: preferred-platform=os
    • כדי להשלים את רישום המקור, נקודת הקצה של טכנולוגיית הפרסום צריכה להשיב לבקשה של Android Attribution Reporting API עם כותרת התגובה Attribution-Reporting-Register-Source. התגובה צריכה לציין גם יעד לאפליקציה בשדה היעד.
    Attribution-Reporting-Register-Source: {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}

  4. טכנולוגיית הפרסום באפליקציה של המפרסם רושמת טריגר ב-Android Attribution Reporting API:

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

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

  1. הגדרה של שני יעדים

    • יכול להיות שחלק מהקמפיינים מוגדרים להמרות באפליקציה של המפרסם או בדף האינטרנט של המפרסם, בהתאם לגורמים שונים כמו אם האפליקציה מותקנת אצל המשתמש.
    • במקרים כאלה, מומלץ להעביר את רישום המקור למערכת ההפעלה (אם האפשרות זמינה), כדי שהמקור ישויך בצורה נכונה בלי קשר למיקום הטריגר. כשרושמים את המקור במערכת ההפעלה, אפשר לציין גם אפליקציה וגם יעד אינטרנט בפרמטרים המתאימים.
    • היעד של האפליקציה צריך להיות בשדה destination
    • כתובת היעד באינטרנט צריכה להיות בשדה web_destination
    • מפתחי Chrome צריכים לשים לב שהשדה destination של OS Attribution Reporting API צריך להיות חבילת אפליקציה ולא כתובת URL.
    Attribution-Reporting-Register-Source: {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    "web_destination": "https://example.advertiser"
    ...
}
    • בקטע הבא בנושא דיווח גס מוסבר איך שימוש ביעדים כפולים עשוי להשפיע על הרעש בדוחות.

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

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

באפליקציות שמשתמשות בכרטיסיות מותאמות אישית ב-Chrome

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

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

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

  3. רישום של מקור CCT וטריגר CCT

באפליקציות שמשתמשות ב-WebView

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

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

  2. ב-WebView אפשר להשתמש רק בשיוך ברמת מערכת ההפעלה. הכותרת Attribution-Reporting-Support תחזיר רק את מערכת ההפעלה, ורק אם Attribution Reporting API ל-Android זמין.

  3. כשמעבירים את ההרשאה למערכת ההפעלה, יכול להיות ש-WebView ישתמש ב-registerSource או ב-registerWebSource וב-registerTrigger או ב-registerWebTrigger. האפליקציה שמעבדת את WebView מגדירה באילו שיטות נעשה שימוש ב-WebView, וההגדרה הזו נקבעת לכל WebView בנפרד.

    • ההבדל בין registerSource לבין registerWebSource הוא המקור שמתועד כבעל התוכן הדיגיטלי. במקרה של registerSource, האפליקציה מתועדת כמקור התנועה. דוגמה לשימוש ב-registerSource היא אפליקציה של בעל תוכן דיגיטלי שמציגה מודעה שמוצגת באמצעות WebView. במקרה של registerWebSource, האתר שמארח את WebView נרשם כמקור התנועה. דוגמה לשימוש ב-registerWebSource היא אפליקציה שמארחת WebView, והאתר שעובר עיבוד על ידי WebView מציג מודעות. ההתנהגות של registerTrigger ו-registerWebTrigger דומה. בתרשים בפריט מספר 3 מפורטים תרחישים שונים שבהם מפתח אפליקציה או מפתח SDK ירצה להגדיר את ה-API לשימוש ב-registerSource או ב-registerWebSource, וב-registerTrigger או ב-registerWebTrigger.
    • כברירת מחדל, WebView ישתמש ב-registerSource וב-registerWebTrigger כשקוראים ל-Android Attribution Reporting API. הפעולה הזו משייכת מקורות לאפליקציה ולטריגרים עם המקור ברמה העליונה של כתובת ה-URL ב-WebView כשהטריגר מופעל.

      • אם האפליקציה דורשת התנהגות שונה, המפתחים יצטרכו להשתמש בשיטה חדשה setAttributionRegistrationBehavior במחלקה androidx.webkit.WebViewSettingsCompat. השיטה הזו קובעת אם WebView צריך לקרוא ל-registerWebSource() או ל-registerWebTrigger() במקום ל-registerSource() או ל-registerTrigger().

      • צריך להגדיר את ההתנהגות הזו לכל WebView שמופעל.

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

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

      ערך תיאור תרחיש שימוש לדוגמה
      APP_SOURCE_AND_WEB_TRIGGER (ברירת מחדל) מאפשרת לאפליקציות לרשום מקורות של אפליקציות (מקורות שמשויכים לשם החבילה של האפליקציה) וטריגרים של אתרים (טריגרים שמשויכים ל-eTLD+1) מ-WebView. אפליקציות שמשתמשות ב-WebView כדי להציג מודעות במקום לאפשר גלישה באינטרנט
      WEB_SOURCE_AND_WEB_TRIGGER מאפשר לאפליקציות לרשום מקורות אינטרנט וטריגרים באינטרנט מ-WebView. אפליקציות דפדפן שמבוססות על WebView, שבהן יכולות להתרחש חשיפות של מודעות והמרות באתרים ב-WebView.
      APP_SOURCE_AND_APP_TRIGGER מאפשר לאפליקציות לרשום מקורות אפליקציות וטריגרים של אפליקציות מ-WebView. אפליקציות מבוססות WebView שבהן צפיות במודעות והמרות צריכות להיות משויכות תמיד לאפליקציה ולא ל-eTLD+1 של WebView.
      מושבת משביתה את רישום המקור והטריגר מ-WebView.
    1. רישום מקורות וטריגרים מ-WebView

    2. ספקי טכנולוגיות פרסום צריכים להגיב לרישום מקורות באמצעות הכותרת Attribution-Reporting-Register-OS-Source. בהתאם להתנהגות שהוגדרה עבור WebView, הפונקציה תקרא ל-registerSource() או ל-registerWebSource() עם מערכת ההפעלה ותפעיל קריאה משנית ל-API מ-Android Attribution Reporting API ל-URI של טכנולוגיית הפרסום.

      • כדי להשלים את רישום המקור, נקודת הקצה של כלי הפרסום הדיגיטלי צריכה להגיב לבקשה של Android Attribution Reporting API עם כותרת התגובה.
       Attribution-Reporting-Register-OS-Source: {
  "source_event_id":"123001",
  "destination":"android-app://com.example.advertiser",
  ...
}

    3. שאר השלבים ברישום המקור נשארים ללא שינוי.

    4. ספקי טכנולוגיות פרסום צריכים להגיב לרישום של טריגרים באמצעות הכותרת Attribution-Reporting-Register-OS-Trigger. בהתאם להתנהגות שמוגדרת ל-WebView, הפונקציה תקרא ל-registerTrigger() או ל-registerWebTrigger() עם מערכת ההפעלה ותפעיל קריאה משנית ל-API מ-Rb ל-URI של טכנולוגיית הפרסום.

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

    Attribution-Reporting-Register-OS-Trigger: {
    "event_trigger_data": [{"trigger_data":"1"}],
    "aggregatable_trigger_data": [
        {"key_piece":"0x400","source_keys":["campaignCounts"]},
        {"key_piece":"0xA80","source_keys":["geoValue"]}
    ],
    ...
}

ניפוי באגים

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

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