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) של אפליקציה לאתר](https://developers.google.cn/static/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app/a2w_diagram.png?hl=he)
רישום מקור האפליקציה:
ה-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"
- הכותרת היא
שאר תהליך רישום המקור זהה לתהליך הרגיל רישום מקור מאפליקציה לאפליקציה.
- כדי לרשום מקור של אפליקציה שצפוי להשלים המרה באתר,
כותרת התשובה
טכנולוגיית הפרסום באתר של המפרסם רושמת את הטריגר על ידי בקשת Chrome להאציל את הרישום ל-Android Attribution Reporting API:
אחרי שמשתמש משלים המרה באתר, טכנולוגיית הפרסום תבצע בקשה לרישום הטריגר ב-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
. המפתח הוא פלטפורמה מועדפת הערכים המותרים הםos
ו-web
. הדפדפן ישתמש בפלטפורמה המועדפת כשמערכת ההפעלה תהיה זמינה, הם יחזרו לפלטפורמת האינטרנט כשמערכת ההפעלה לא זמין.
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) של אתר לאפליקציה](https://developers.google.cn/static/privacy-sandbox/private-advertising/attribution-reporting/cross-web-app/w2a_diagram.png?hl=he)
רישום של מקור אתר:
טכנולוגיית הפרסום רושמת מקור ובודקת את הזמינות של מערכת ההפעלה 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"
טכנולוגיית הפרסום אמורה להורות ל-Chrome לתת גישה ל-API ברמת מערכת ההפעלה באמצעות הכותרת
Attribution-Reporting-Register-OS-Source
אשר:- נותנת ל-Chrome הרשאה להאציל את הרישום למערכת ההפעלה
- Chrome מעניק את תהליך הרישום למערכת ההפעלה באמצעות קריאה לפונקציה של OS API
registerWebSource()
- הקריאה ל-
registerWebSource()
מתבצעת מאחורי הקלעים, טכנולוגיית הפרסום לא צריך להתקשר ישירות אלregisterWebSource()
- ה-OS API מפעיל קריאה משנית ל-API ל-URI של טכנולוגיית הפרסום שמועברת מאת הדפדפן
"Attribution-Reporting-Register-OS-Source": "https://adtech.example/register-source"
- במקרים מסוימים הכותרת
Attribution-Reporting-Support
לא זמינה. כשזה קורה, טכנולוגיית הפרסום עדיין יכולה להגדיר פלטפורמה מועדפת לטיפול רישום המקור על ידי הכללת הכותרתAttribution-Reporting-Info
. המפתח הוא פלטפורמה מועדפת והערכים המותרים הם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 של ההקשר באינטרנט לכל פעולה של הפניה אוטומטית.
- שאר התהליך של רישום המקור לא משתנה.
טכנולוגיית הפרסום באפליקציה של המפרסם רושמת טריגר ב-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 זמין.
כשמעניקים גישה למערכת ההפעלה, 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. - אם האפליקציה דורשת התנהגות אחרת, היא תצטרך להשתמש בשיטה חדשה
setAttributionRegistrationBehavior ב-androidx.webkit.WebViewSettingsCompat
בכיתה. השיטה הזו מציינת אם ה-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), אפשר לעיין במדריך לניפוי באגים.