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

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

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

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

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

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

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

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

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

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

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

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

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

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

שינויים לטכנולוגיות פרסום

שינויים ברישום ובשיוך

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

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

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

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

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

• בדוחות ברמת האירוע, נתמוך בשדה יעד שמציין אם הטריגר התרחש באתר (היעד הוא TLD+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() (וגם כדי לשנות את ההתנהגות הזו), אפשר לעיין במאמר מקור שיוך והרשמה של טריגרים מ-WebView.

הערה: כדי לאפשר ל-WebViews להשתמש ב-Attribution Reporting API, צריך להגדיר לאפליקציית ההטמעה את ההרשאות המתאימות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רישום של מקור שיוך

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

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

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

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

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

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

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

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

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

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

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

האפשרויות הזמינות עבור setAttributionRegistrationBehavior הן:

ערך	תיאור	תרחיש לדוגמה
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.
מושבת	השבתת ההרשמה של המקור והטריגר מ-WebView. הערה: ייתכן שהקריאה הראשונית לרשת של URI של מקור השיוך או הטריגר עדיין תתבצע, אבל כל תגובה תידחה ולא יישמר דבר במכשיר.

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

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

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

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

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

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

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

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

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

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

פקדי משתמש

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

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

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

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

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