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

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

שליחת משוב

עדכונים אחרונים

• נוסף קטע בנושא דוחות ניפוי באגים מהלך
• נוספו הוראות להצטרפות לרשימת היתרים לרישום מקורות אינטרנט

כפי שמתואר בהצעת העיצוב של Attribution Reporting API, ה-API מאפשר שיוך של נתיבי הטריגר הבאים במכשיר יחיד שמופעל באמצעות Android:

• App-to-app: המשתמש רואה מודעה באפליקציה, ולאחר מכן מבצע המרה באפליקציה הזו או באפליקציה אחרת שמותקנת.
• App-to-web: המשתמש רואה מודעה באפליקציה, ולאחר מכן מבצע המרה בדפדפן בנייד או באפליקציה.
• Web-to-app: המשתמש רואה מודעה בדפדפן בנייד או באפליקציה, ולאחר מכן מבצע המרה באפליקציה.
• Web-to-web: המשתמש רואה מודעה בדפדפן בנייד או באפליקציה, ולאחר מכן מבצע המרה באותו דפדפן או בדפדפן אחר באותו מכשיר.

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

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

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

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

קבלת גישה לממשקי Attribution Reporting API

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

אחרי שתהליך הרישום יושלם, ה-API יבטל את הרישום אם מתקבלת קריאה לרישום שלא נרשם.

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

שינויים בטכנולוגיה של מודעות

שינויים ברישום ובשיוך (Attribution)

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

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

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

קבלת דוחות על אפליקציות ואתרים

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

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

ההשלכות של מדידה מאתר לאתר

האפליקציות בוחרות מתי להעביר את הרישום ל-Attribution Reporting API. יש כמה שיקולים שכדאי להביא בחשבון:

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

הדוגמה הבאה מראה איך אפליקציות דפדפן יכולות לעבוד עם Attribution Reporting API כדי לספק מדידה מדויקת כשמשתמש לוחץ על מודעה באפליקציית דפדפן וגם באפליקציה שאינה בדפדפן:

דוגמה להרשמה של מקור וטריגר בדפדפן ובאפליקציה

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

רישום מקור השיוך והטריגר מ-WebView

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

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

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

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

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

שימו לב: אם התשובה לא כוללת את הכותרות הקודמות, או שהיא כוללת גם את הכותרות Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger על אף שאין תמיכה באינטרנט, הרישום כולו ייכשל.

כדי להבין אם WebView ישתמש ב-registerSource() / registerWebSource() וב-registerTrigger() / registerWebTrigger() (ואיך לשנות את ההתנהגות הזו), תוכלו לעיין במאמר מקור השיוך (Attribution) ולהפעיל רישום מ-WebView.

דוחות ניפוי באגים לפי מעבר

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

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

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

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

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

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

• דוחות מפורטים של המקור תלויים רק בהרשאות בצד של בעל האתר. כדי שיישלחו דוחות מפורטים של מקורות, המשתמש לא צריך לבטל את ההסכמה להתאמה אישית של מזהה הפרסום, ואפליקציית בעל התוכן הדיגיטלי צריכה להיות מוצהרת על הרשאות AdID.
• הפעלת דוחות מפורטים תלויים רק בהרשאות של הטריגר (בדוגמה הזו, באינטרנט). קובצי cookie של צד שלישי חייבים להיות זמינים בדפדפן כדי להפעיל דוחות מפורטים.
• כשמפעילים דוחות מפורטים שיכולים לכלול source_debug_key, הערך source_debug_key נכלל אם מזהה הפרסום זמין לאפליקציה של בעל האתר.

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

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

שינויים באפליקציות

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

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

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

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

רישום של מקור שיוך (Attribution)

כשרושמים מקור שיוך (Attribution), האפליקציות יכולות לבצע קריאה לפונקציה registerWebSource(), שמקבלת את הפרמטרים הבאים:

• מזהי URI של מקור השיוך: הפלטפורמה שולחת בקשה לכל URI ברשימה הזו כדי לאחזר מטא-נתונים שמשויכים למקור השיוך.
  
  כל URI צריך ללוות סימון בוליאני Debug כדי לציין אם מפתחות ניפוי הבאגים שסופקו על ידי הטכנולוגיות צריכים להיכלל בדוח.
• אירוע קלט: אובייקט InputEvent (לאירוע מסוג קליק) או null (לאירוע של צפייה)
• מקור המקור: המקור שבו התרחש המקור (אתר בעל האתר).
• יעד מערכת ההפעלה: שם של חבילת אפליקציות שבה מתרחש האירוע של הטריגר.
• יעד אינטרנט: eTLD+1 שבו מתרחש אירוע הטריגר.
• מאומת יעד: Intent של URI של מערכת הפעלה או יעד אינטרנט שמשמש לניווט בקליק של המשתמש.

כש-API שולח בקשה ל-URI של מקור השיוך, טכנולוגיית המודעות צריכה להגיב למטא-נתונים של מקור השיוך בכותרת HTTP, Attribution-Reporting-Register-Source. בכותרת הזו יש שדות זהים לרישום מקור השיוך מאפליקציה לאפליקציה, עם כמה שינויים:

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

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

רישום של הטריגר (המרה)

בעת רישום הטריגר, האפליקציות יכולות לקרוא לפונקציה registerWebTrigger(), שמצפה לפרמטרים הבאים:

• Trigger URIs: הפלטפורמה שולחת בקשה לכל URI ברשימה הזו כדי לאחזר מטא-נתונים שמשויכים לטריגר
• Destination origin: המקור שבו התרחש הטריגר (האתר של המפרסם)

מקור השיוך ורישום הטריגר מ-WebView

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

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

האפשרויות הזמינות ל-setAttributionRegistrationBehavior הן:

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

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

שיקולי פרטיות ואבטחה

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

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

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

יצירת אמון בהקשר באינטרנט

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

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

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

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

פקדי משתמש

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

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

שיקולים עתידיים ושאלות פתוחות

אנחנו עדיין עובדים על יכולת הפעולה ההדדית של Attribution Reporting API בין אפליקציה לאתר. אנחנו רוצים לבקש משוב מהקהילה על כמה רעיונות:

1. איך משתמשים בפתרונות למדידת ביצועים בדפדפן עם Android Attribution Reporting API במכשיר שתומך בארגז החול לפרטיות ב-Android? אתם מעדיפים להעביר את הכול ל-Android?
2. האם יש חשש לקבלת שני פינגים לכל מקור וטריגר של שיוך – אחד מהדפדפן או מהאפליקציה והשני מ-Attribution Reporting API?
3. איך נוכל לעזור לכם לנפות באגים בממשקי API שונים בקלות רבה יותר?
4. ההצעה לא כוללת אימות לכך שיעדי האפליקציה והאתר משויכים. בעתיד ייתכן שנוכל לאמת את היעדים האלה על ידי בדיקת שיוכים באמצעות Digital Asset Links (קישורים לנכס דיגיטלי). האם היא תחסום את התרחישים לדוגמה שלכם? האם הגיוני להשתמש ב-Digital Asset Links (קישורים לנכס דיגיטלי) לצורך האימות הזה?
5. כשרושמים מקור שיוך (Attribution), צריך לציין יעד. במקרה של אתר לאפליקציה, כדאי לציין קישור לאפליקציה. באילו פורמטים אתם משתמשים כדי לציין את הקישור לאפליקציה?
6. כשרושמים מקור שיוך (Attribution) מאפליקציה לאתר, צריך לרשום את אירוע המקור הזה באפליקציה באמצעות Android Attribution Reporting API. לדוגמה, אם המשתמש לוחץ על מודעה והקליק נפתח בדפדפן או בכרטיסייה בהתאמה אישית בדפדפן, צריך לרשום את הקליק (אירוע מקור) מהאפליקציה ולא בהקשר של הדפדפן. אם יש לכם חששות בנושא הזה, או אם יש תרחישים לדוגמה אחרים שלא משתייכים לקטגוריות שמצוינות בבעיה שמתארת את תהליכי העבודה הנתמכים, אתם יכולים לפנות אלינו.