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

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