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

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

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

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

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

רישום מקורות וטריגרים ב-Android OS

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

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

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

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

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

דוגמה

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

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

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

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

רישום טריגר לאתרים:

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

תהליך עבודה

בשלבים הבאים מוסבר איך משלימים את המשימה:

טכנולוגיית הפרסום מהאפליקציה רושמת מקור עם Attribution של Android Reporting API כולל את ההתאמות הבאות:
- כדי לרשום מקור של אפליקציה שצפוי להשלים המרה באתר, כותרת התשובה 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 להאציל את הרישום ל-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 מעניק את תהליך הרישום למערכת ההפעלה באמצעות קריאה לפונקציה של 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. המפתח הוא פלטפורמה מועדפת הערכים המותרים הם os ו-web. הדפדפן ישתמש בפלטפורמה המועדפת כשמערכת ההפעלה תהיה זמינה, הם יחזרו לפלטפורמת האינטרנט כשמערכת ההפעלה לא זמין.
הערה: גם Attribution-Reporting-Register-Trigger הכותרת שמכילה את פרטי הרישום באינטרנט ואת הכותרת Attribution-Reporting-Register-OS-Trigger שמכילה את הרישום של מערכת ההפעלה צריך להחזיר מידע כאשר מציינים פלטפורמה מועדפת כדי להבטיח שהאימות רישום לפלטפורמה. רישומים של מערכות הפעלה ושל אתרים חייבים כך שאם הפלטפורמה המועדפת לא זמינה, המידע חובה לשיטת החלופה.
```
Attribution-Reporting-Info: preferred-platform=os
```
- כדי להשלים את רישום הטריגר, נקודת הקצה (endpoint) של טכנולוגיית הפרסום אמורה להגיב לבקשה של 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 כדי להעניק את הרישום ל-Android Attribution Reporting API באמצעות Attribution Reporting API ב-Chrome. המשתמש רוכש את הסוודר אפליקציית השופינג. לאחר מכן טכנולוגיית הפרסום באפליקציה של המפרסם רושמת את שהמקור שלו הוא Android Attribution Reporting API. ברמת מערכת ההפעלה Attribution Reporting API יכול להתאים בין המקור של האתר לבין הטריגר של האפליקציה, וגם לשלוח את הדוחות הרלוונטיים.

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

רישום של מקור אתר:

טכנולוגיית הפרסום רושמת מקור ובודקת את הזמינות של מערכת ההפעלה Attribution Reporting API
אתר ARA מחזיר מידע על הפלטפורמה הנתמכת
הכותרת OS-Source מנחה את ממשק ה-API של ARA באינטרנט לקרוא ל-OS ARA API פונקציית registerWebSource()
הקריאה ל-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 כדי להשלים את רישום הטריגר
מערכת ההפעלה OS ARA תבצע שיוך (Attribution) לפי אותה לוגיקה שחלה על אפליקציה<>שיוך לאפליקציה ולשלוח את אותם דוחות

תהליך עבודה

בשלבים הבאים מוסבר איך משלימים את המשימה:

טכנולוגיית הפרסום באתר של בעל התוכן הדיגיטלי רושמת את המקור באמצעות הוראה Chrome להאציל את הרישום ל-Android Attribution Reporting API:
- בתרחיש לדוגמה מהאתר לאפליקציה, בזמן רישום מקור, השיוך יש לציין ישירות את פרמטר המקור, באמצעות הפונקציה תג attributionsrc או באמצעות רישום JavaScript
- הדוגמה הבאה משתמשת בתג attributionsrc כדי לציין את פרמטר המקור:
```
<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 OS כדי לבצע מדידה באפליקציה ובאתר.
טכנולוגיית הפרסום אמורה להורות ל-Chrome לתת גישה ל-API ברמת מערכת ההפעלה באמצעות הכותרת Attribution-Reporting-Register-OS-Source אשר:
1. נותנת ל-Chrome הרשאה להאציל את הרישום למערכת ההפעלה
2. Chrome מעניק את תהליך הרישום למערכת ההפעלה באמצעות קריאה לפונקציה של OS API registerWebSource()
3. הקריאה ל-registerWebSource() מתבצעת מאחורי הקלעים, טכנולוגיית הפרסום לא צריך להתקשר ישירות אל registerWebSource()
4. ה-OS API מפעיל קריאה משנית ל-API ל-URI של טכנולוגיית הפרסום שמועברת מאת הדפדפן
```
"Attribution-Reporting-Register-OS-Source": "https://adtech.example/register-source"
```
- במקרים מסוימים הכותרת Attribution-Reporting-Support לא זמינה. כשזה קורה, טכנולוגיית הפרסום עדיין יכולה להגדיר פלטפורמה מועדפת לטיפול רישום המקור על ידי הכללת הכותרת Attribution-Reporting-Info. המפתח הוא פלטפורמה מועדפת והערכים המותרים הם 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 של ההקשר באינטרנט לכל פעולה של הפניה אוטומטית.
- שאר התהליך של רישום המקור לא משתנה.
טכנולוגיית הפרסום באפליקציה של המפרסם רושמת טריגר ב-Android Attribution Reporting API:
- כשמדובר בטריגרים שקורים באפליקציות, האפליקציות רושמים טריגרים עם Android Attribution Reporting API כרגיל.

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

הגדרת שני יעדים
- ייתכן שבחלק מהקמפיינים יוגדרו המרות באפליקציה של המפרסם או בדף האינטרנט של המפרסם, בהתאם לגורמים שונים, כמו אם המשתמש כולל את האפליקציה מותקנת.
- במקרים כאלה, מומלץ להאציל את רישום המקור אל מערכת הפעלה כשהאפשרות זמינה, כדי שניתן יהיה לשייך את המקור בצורה נכונה, ללא קשר המיקום שבו מופיע הטריגר. כשמבצעים רישום של המקור במערכת ההפעלה, גם אפשר לציין את היעד של האפליקציה והאתר בפרמטרים המתאימים.
- יעד האפליקציה צריך להיות בשדה destination
- יעד האינטרנט צריך להיות בשדה web_destination
- מפתחי Chrome צריכים לשים לב שהשדה destination עבור מערכת ההפעלה 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, למשל רינדור מודעות, אירוח תוכן באינטרנט או אפליקציה מותאמת אישית שמתאימות יותר לפורמט אינטרנט.

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

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

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

ניפוי באגים

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

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