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

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

נתיבי טריגר

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

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

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

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

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

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

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

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

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

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

בקטע הזה נסביר על השינויים שחלים על טכנולוגיות פרסום שמשתמשות ב-Attribution Reporting API.

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

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

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

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

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

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

השלכות של מעקב המרות מאתר לאתר

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

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

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

דוגמאות לקליקים של משתמשים ולהמרות במהלך תקופה של 3 ימים.
דוגמה לרישום של מקור וטריגר בדפדפן ובאפליקציה
  • ביום הראשון, המשתמש לוחץ על מודעה באפליקציית הדפדפן.
    • אפליקציית הדפדפן יכולה לבחור להשתמש בפתרון מדידה משלה או להעביר את הרישום של הקליק על המודעה באתר אל 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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