דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

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

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

דוגמה

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

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

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

ערכת ה-SDK של טכנולוגיית הפרסום באפליקציית Daily News ל-Android מתעדת את הקליק באמצעות registerSource()
Attribution Reporting API ב-Android שולח בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שצוינה ב-registerSource()
שרת הטכנולוגיה של המודעות משיב עם הכותרת Attribution-Reporting-Register-Source כדי להשלים את רישום המקור

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

טכנולוגיית הפרסום רושמת טריגר ובודקת את הזמינות של מערכת ההפעלה ב-Attribution Reporting API
ה-ARA באינטרנט מחזיר מידע על הפלטפורמה הנתמכת
הכותרת OS-Trigger מורה ל-Web ARA API לקרוא לפונקציה registerWebTrigger() של OS ARA API
הקריאה ל-registerWebTrigger() מתבצעת מתחת לפני השטח, והמפתח לא צריך לבצע קריאה ל-registerWebTrigger() ישירות עם מערכת ההפעלה
ה-OS ARA מקבל את השליטה ושולח בקשה לכתובת ה-URL של שרת חברת טכנולוגיית הפרסום שצוינה בכותרת Attribution-Reporting-Register-OS-Trigger.
טכנולוגיית הפרסום משלימה את רישום הטריגר באמצעות OS API
ה-ARA של מערכת ההפעלה יבצע שיוך לפי אותה לוגיקה שחלה על שיוך בין אפליקציה לאפליקציה, וישלח את אותם דוחות.

תהליך עבודה

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

טכנולוגיית הפרסום מהאפליקציה רושמת מקור ב-Attribution Reporting API של Android עם השינויים הבאים:
- כדי לרשום מקור אפליקציה שצפוי להניב המרות באתר, כותרת התגובה Attribution-Reporting-Register-Source צריכה לכלול יעד אינטרנט (eTLD+1) במקום יעד אפליקציה.
```
Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
```
הערה: בקמפיינים שעשויים להניב המרות ביעד אינטרנט או ביעד אפליקציה, כדאי לעיין בקטע בנושא יעדים כפולים
- יכול להיות שמפרסמים מסוימים משתמשים בכמה ספקי מדידה (למשל, כלי מדידה של צד שלישי או כלי ניתוח נתונים) באמצעות רשתות של הפניות אוטומטיות מסוג 302. במקרים מסוימים, Attribution Reporting API יפעל לפי נתיב ההפניה האוטומטית שצוין בכותרת 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
```
  הערה: לכל ההפניות האוטומטיות הבאות אחרי הכותרת הזו יתווסף הערך .well-known לתחילת הנתיב של ה-URI להפניה האוטומטית.
- שאר תהליך רישום המקור זהה לרישום מקור רגיל מאפליקציה לאפליקציה.
הערה: אם אתם או אפליקציית הפרסום משתמשים ב-webview כדי להציג מודעה באפליקציה ל-Android, כדאי לעיין בקטע בנושא webview
טכנולוגיית הפרסום באתר של המפרסם רושמת את הטריגר על ידי בקשה ל-Chrome להעניק את הגישה לרישום ל-Attribution Reporting API של Android:
- אחרי שמשתמש משלים המרה באתר, מערכת טכנולוגיית הפרסום שולחת בקשה לרישום הטריגר ב-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 מעביר את הרישום למערכת ההפעלה באמצעות קריאה לפונקציית OS API‏registerWebTrigger()
    - הקריאה ל-registerWebTrigger() מתבצעת ברקע, וטכנולוגיית הפרסום לא צריכה לקרוא ל-registerWebTrigger() ישירות
  3. ה-OS 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-Register-Trigger שמכילה את פרטי הרישום באינטרנט וגם את הכותרת Attribution-Reporting-Register-OS-Trigger שמכילה את פרטי הרישום במערכת ההפעלה כשמציינים את הפלטפורמה המועדפת. צריך לספק גם רישום במערכת ההפעלה וגם רישום באינטרנט, כדי שאם הפלטפורמה המועדפת לא זמינה, המידע הנדרש לשיטת החזרה לגיבוי יהיה זמין.
```
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) מהאתר לאפליקציה — תהליך השיוך (Attribution) מאתר לאפליקציה

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

טכנולוגיית הפרסום רושמת מקור ובודקת את הזמינות של מערכת ההפעלה ב-Attribution Reporting API
ה-ARA באינטרנט מחזיר מידע על הפלטפורמה הנתמכת
הכותרת OS-Source מורה ל-Web ARA API לקרוא לפונקציה registerWebSource() של OS ARA API
הקריאה ל-registerWebSource() מתבצעת מתחת לפני השטח, והמפתח לא צריך לבצע קריאה ל-registerWebSource() ישירות עם מערכת ההפעלה
ה-OS ARA מקבל את השליטה ושולח בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שצוינה בכותרת Attribution-Reporting-Register-OS-Source.
טכנולוגיית הפרסום משלימה את רישום המקור באמצעות OS API

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

ערכת ה-SDK של טכנולוגיית הפרסום באפליקציה של חנות הבגדים ל-Android רושמת את הטריגר ב-OS ARA
Attribution Reporting API ב-Android שולח בקשה לכתובת ה-URL של שרת טכנולוגיית הפרסום שצוינה ב-registerTrigger()
שרת טכנולוגיית הפרסום משיב עם הכותרת Attribution-Reporting-Register-Trigger כדי להשלים את רישום הטריגר
ה-ARA של מערכת ההפעלה יבצע שיוך לפי אותה לוגיקה שחלה על שיוך בין אפליקציה לאפליקציה, וישלח את אותם דוחות.

תהליך עבודה

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

טכנולוגיית הפרסום באתר של בעל האפליקציה רושמת את המקור על ידי הנחיה ל-Chrome להעביר את ההרשמה ל-Attribution Reporting API של Android:
- בתרחיש לדוגמה של אתר לאפליקציה, כשרושמים מקור, צריך לציין ישירות את הפרמטר של מקור השיוך, באמצעות התג attributionsrc או באמצעות רישום ב-JavaScript.
- בדוגמה הבאה נעשה שימוש בתג attributionsrc כדי לציין את הפרמטר source:
```
<img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">
```
כותרת הבקשה Attribution-Reporting-Support מוחזרת על ידי Chrome לטכנולוגיית הפרסום. אם ממשק ה-API מופעל גם בדפדפן Chrome וגם במכשיר Android, הכותרת תחזיר את הערך os, web.
```
Attribution-Reporting-Support: os, web
```
הערה: כדי לבצע מדידה באפליקציה ובאינטרנט, צריך להפעיל את Attribution Reporting API במערכת ההפעלה Android.
טכנולוגיית הפרסום צריכה להורות ל-Chrome להעביר את הגישה ל-API ברמת מערכת ההפעלה באמצעות הכותרת Attribution-Reporting-Register-OS-Source, שמכילה את הפרטים הבאים:
1. מציינת ל-Chrome להעביר את הרישום למערכת ההפעלה
2. Chrome מעביר את הרישום למערכת ההפעלה באמצעות קריאה לפונקציית OS 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-Register-Source שמכילה את פרטי הרישום באינטרנט וגם את הכותרת Attribution-Reporting-Register-OS-Source שמכילה את פרטי הרישום במערכת ההפעלה כשמציינים את הפלטפורמה המועדפת. צריך לספק גם רישום במערכת ההפעלה וגם רישום באינטרנט, כדי שאם הפלטפורמה המועדפת לא זמינה, המידע הנדרש לשיטת החזרה לגיבוי יהיה זמין.
```
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",
    ...
}
```
- כדי לתמוך בהפניות אוטומטיות לרישומי מקורות, Chrome יעקוב אחרי ההפניות האוטומטיות ויקרא לממשקי ה-API של הקשר האינטרנטי בכל שלב בהפניה האוטומטית.
- שאר השלבים של רישום המקור לא משתנים.
טכנולוגיית הפרסום באפליקציה של המפרסם רושמת טריגר ב-Attribution Reporting API של Android:
- לגבי טריגרים שמתרחשים באפליקציות, האפליקציות רושמו טריגרים ב-Android Attribution Reporting API כרגיל.

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

הגדרת שני יעדים
- יכול להיות שקמפיינים מסוימים מוגדרים להמרה באפליקציה של המפרסם או בדף האינטרנט של המפרסם, בהתאם לגורמים שונים, כמו אם המשתמש התקין את האפליקציה.
- במקרים כאלה, מומלץ להעניק גישה לרישום המקור למערכת ההפעלה, אם האפשרות הזו זמינה, כדי שאפשר יהיה לשייך את המקור בצורה נכונה, ללא קשר למיקום שבו מתרחש הטריגר. כשרושמים את המקור במערכת ההפעלה, אפשר לציין פרמטרים נפרדים לאפליקציה ולאתר אינטרנט.
- היעד של האפליקציה צריך להופיע בשדה 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"
    ...
}
```
- בקטע הבא, בנושא דיווח גס, נסביר איך שימוש בשני יעדים יכול להשפיע על הרעש בדוחות.
כדאי להשתמש בדיווח גס כדי לצמצם את הרעש בדוחות ברמת האירוע של מקורות עם שני יעדים:
- אם בזמן רישום המקור צוינו גם מערכת הפעלה (אפליקציה) וגם יעד אינטרנט, בדוחות ברמת האירוע יצוין כברירת מחדל אם הטריגר התרחש ביעד אינטרנט או ביעד אפליקציה. עם זאת, כדי לשמור על מגבלות הפרטיות, יתווסף רעש נוסף לדוחות האלה.
- טכנולוגיות הפרסום יכולות להשתמש בשדה coarse_event_report_destinations מתחת לכותרת Attribution-Reporting-Register-Source כדי להפעיל דיווח גס ולצמצם את הרעש. אם מקור עם השדה coarse_event_report_destinations יזכה בשיוך, הדוח שייווצר יכלול גם את יעדי האפליקציה וגם את יעדי האינטרנט, ללא הבחנה לגבי המיקום שבו הטריגר התרחש בפועל, אבל עם פחות רעשי רקע בהשוואה לדוחות שבהם מצוין יעד האפליקציה או יעד האינטרנט.
- דוחות הצבירה לא השתנו.

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

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

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

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

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

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

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

כשמפעילים הענקת גישה למערכת ההפעלה, 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 כשיתבצע קריאה ל-Attribution Reporting API של Android. כך מתבצע שיוך של מקורות לאפליקציה, והטריגר מופעל עם המקור ברמה העליונה של כתובת ה-URL ב-WebView כשהטריגר מתרחש.

אם באפליקציה נדרש התנהגות שונה, המפתחים יצטרכו להשתמש בשיטה החדשה setAttributionRegistrationBehavior במחלקה androidx.webkit.WebViewSettingsCompat. השיטה הזו תציין אם WebView צריך לקרוא ל-registerWebSource() או ל-registerWebTrigger() במקום ל-registerSource() או ל-registerTrigger().
צריך להגדיר את ההתנהגות הזו לכל WebView שמופעל.
אם ערכת ה-SDK של טכנולוגיית הפרסום היא זו שמפעילה את WebView, היא תצטרך להגדיר את התנהגות ברירת המחדל הזו.
כדי שאפליקציות יוכלו להשתמש ב-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.

רישום מקורות וטריגרים מ-WebView
טכנאי הפרסום צריכים להגיב לרישומי מקורות באמצעות הכותרת 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",
  ...
}
```
שאר השלבים של רישום המקור לא משתנים.
טכנאי הפרסום צריכים להגיב לרישומי טריגרים באמצעות הכותרת Attribution-Reporting-Register-OS-Trigger. בהתאם להתנהגות שהוגדרה ל-WebView, תתבצע קריאה ל-registerTrigger() או ל-registerWebTrigger() באמצעות מערכת ההפעלה, ותופעל קריאה משנית ל-API מ-Rb אל ה-URI של טכנולוגיית הפרסום.
כדי להשלים את ההרשמה של הטריגר, נקודת הקצה של טכנולוגיית הפרסום צריכה להשיב לבקשה של Attribution Reporting API ל-Android באמצעות כותרת התגובה.

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"]}
    ],
    ...
}

שאר תהליך הרשמת הטריגר נשאר ללא שינוי.

ניפוי באגים

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

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