Attribution Reporting API: מדריך השילוב

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

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

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

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

בדף הזה, המונח מקור מייצג קליק או צפייה, והמונח טריגר מייצג המרה.

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

תהליך עבודה של שילוב שיוך.
איור 1. תהליך העבודה של שילוב השיוך (Attribution).

דרישות מוקדמות והגדרה

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

להכיר את ה-API

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

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

  1. כשמוכנים להתחיל בשילוב, צריך להגדיר את הגרסה העדכנית של Developer Preview ב-Android Studio.
  2. הגדרת נקודות קצה (endpoints) של שרת מדומה לרישום אירועים ולשליחת דוחות. סיפקנו מודלים שאפשר להשתמש בהם יחד עם כלים שזמינים באינטרנט.
  3. כדי להכיר את התהליך של רישום מקורות וטריגרים, מורידים ומריצים את הקוד באפליקציה לדוגמה.
    1. הגדרת חלון הזמן לשליחת דוחות. ה-API תומך בחלונות של יומיים, 7 ימים או תקופה מותאמת אישית בין יומיים ל-30 ימים.
    2. אחרי שמפעילים את אפליקציית הדוגמה ומשתמשים בה כדי לרשום מקורות וטריגרים, וכשחלף פרק הזמן שהוגדר, צריך לוודא שקיבלתם דוח ברמת האירוע ודוח נצבר מוצפן. אם אתם צריכים לנפות באגים בדוחות, אתם יכולים ליצור אותם מהר יותר על ידי הפעלה בכוח של משימות דיווח.
    3. בודקים את התוצאות של השיוך מקמפיין לקידום אפליקציה לקמפיין לקידום אפליקציה. מוודאים שהנתונים בתוצאות האלה הם כצפוי גם במקרים של מגע אחרון וגם במקרים של פוסט-התקנה.

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

לפני השילוב

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

Partner engagement

שותפים בתחום טכנולוגיות הפרסום (MMP/SSP/DSP) יוצרים לעיתים קרובות פתרונות משולבים לשיוך המרות. השלבים בקטע הזה יעזרו לכם להתכונן לשיתוף פעולה מוצלח עם שותפים בתחום הטכנולוגיה הפרסומית.

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

אב טיפוס של שיוך (Attribution) ברמת האירוע מאפליקציה לאפליקציה

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

  1. מגדירים שרת איסוף לרשומות של אירועים. כדי לעשות את זה, אפשר להשתמש במפרט שסופק כדי ליצור שרת מדומה, או להגדיר שרת משלכם באמצעות קוד השרת לדוגמה.
  2. מוסיפים קריאות לאירוע של רישום מקור ל-SDK או לאפליקציה כשמודעות מוצגות.
    • הנה כמה שיקולים חשובים:
      • מוודאים שמזהי אירועים של מקורות זמינים ומועברים בצורה תקינה אל קריאות ה-API של רישום המקור.
      • מוודאים שאפשר גם להעביר InputEvent כדי לרשום מקורות קליקים.
      • קובעים איך תגדירו את העדיפות של מקורות לסוגים שונים של אירועים. לדוגמה, אפשר להקצות עדיפות גבוהה לאירועים שנחשבים בעלי ערך גבוה, כמו קליקים על צפיות.
      • ערך ברירת המחדל של תאריך התפוגה מתאים לבדיקות. אפשרות אחרת היא להגדיר חלונות תפוגה שונים.
      • במהלך הבדיקה, אפשר להשאיר את המסננים ואת חלונות השיוך כברירות מחדל.
    • שיקולים אופציונליים כוללים את הדברים הבאים:
      • אם אתם מוכנים לכך, כדאי לעצב מפתחות צבירה.
      • כדאי לשקול את אסטרטגיית ההפניה האוטומטית כשקובעים איך רוצים לעבוד עם שותפים אחרים למדידת ביצועים.
  3. מוסיפים register trigger events (רישום אירועים להפעלת טריגר) ל-SDK או לאפליקציה כדי לתעד אירועי המרה.
    • הנה כמה שיקולים חשובים:
    • שיקולים אופציונליים כוללים את הדברים הבאים:
      • אל תיצרו מפתחות לביטול כפילויות עד שתבצעו בדיקות דיוק.
      • אל תיצרו מפתחות וערכים של צבירה עד שהתמיכה בבדיקות סימולציה תהיה מוכנה.
      • כדאי לדלג על הפניות אוטומטיות עד שתחליטו איך אתם רוצים לעבוד עם שותפי מדידה אחרים.
      • סדר העדיפויות של הטריגרים לא חיוני לבדיקה.
      • בבדיקות הראשוניות, סביר להניח שאפשר להתעלם מהמסננים.
  4. בודקים שאירועים במקור נוצרים עבור מודעות, ושגורמים מפעילים מובילים ליצירת דוחות אירועים.

בדיקות סימולציה

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

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

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

  1. הגדרת ספריית סימולציית המדידה במחשב מקומי.
  2. כדאי לעיין במפרט כדי להבין איך צריך לעצב את נתוני ההמרות כדי שיהיו תואמים לכלי ליצירת דוחות מסימולציות.
  3. מעצבים את מפתחות הצבירה על סמך הדרישות העסקיות.
    • הנה כמה שיקולים חשובים:
      • כדאי לחשוב על המימדים הקריטיים שהלקוחות או השותפים צריכים לצבור, ולהתמקד בהם בהערכה.
      • קובעים את המספר המינימלי של מאפיינים מצטברים ושל עוצמות הקבוצות שנדרשים בהתאם לדרישות.
      • מוודאים שחלקי המפתח בצד המקור ובצד הטריגר לא חורגים מ-128 ביטים.
      • אם הפתרונות שלכם כוללים תרומה לכמה ערכים לכל אירוע הפעלה, הקפידו להתאים את הערכים לתקציב המקסימלי לתרומה, L1. כך אפשר לצמצם את ההשפעה של הרעש.
      • בדוגמה הבאה מוסבר איך להגדיר מפתח לאיסוף נתונים מצטברים של מספר ההמרות ברמת הקמפיין, ומפתח לאיסוף נתונים מצטברים של ערכי הרכישה ברמה הגיאוגרפית.
  4. מריצים את כלי הדוחות כדי ליצור דוחות על אירועים ודוחות שניתן לצבור.
  5. מריצים את הדוחות עם נתונים שאפשר לצבור דרך שרתי הצבירה המדומים כדי לקבל דוחות סיכום.
  6. עריכת ניסויים של כלי עזר:
    • כדי לקבוע את רמת הדיוק של דיווח ההמרות, אפשר להשוות בין סכומי ההמרות בדוחות ברמת האירוע ובדוחות הסיכום לבין נתוני המרות היסטוריים. כדי לקבל את התוצאות הטובות ביותר, מומלץ להריץ את בדיקות הדיווח וההשוואות על חלק נרחב ומייצג של בסיס המפרסמים.
    • מאמנים מחדש את המודלים על סמך נתוני דיווח ברמת האירוע, ואולי גם על סמך נתוני דיווח סיכום. השוואה בין רמת הדיוק של המודלים לבין מודלים שמבוססים על נתוני אימון היסטוריים.
    • נסו אסטרטגיות שונות של אצווה ובדקו איך הן משפיעות על התוצאות.
      • הנה כמה שיקולים חשובים:
      • הזמן שנדרש להפקת דוחות סיכום לצורך התאמת הצעות מחיר.
      • התדירויות הממוצעות של אירועים שניתן לשייך למכשיר. לדוגמה, משתמשים לא פעילים שחוזרים על סמך נתונים היסטוריים של אירועי רכישה.
      • רמת הרעש. יותר קבוצות אומרות צבירה קטנה יותר, וצבירה קטנה יותר אומרת שמוחל יותר רעש.

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

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

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

שילוב של שרת צבירה של אב טיפוס לצורך שיוך:

כדי להמשיך מכאן, צריך להשלים את השלבים שמתוארים בקטע Prototype aggregation server attribution: Setup או בקטע Prototype App to App Event-Level Attribution**.

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

שיפור העיצוב באמצעות תכונות אופציונליות

בהמשך מפורטות תכונות נוספות שאפשר לכלול בפתרון המדידה.

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

התאמה אישית של התנהגויות שיוך

  1. שיוך לטריגרים אחרי התקנה
    • אפשר להשתמש בתכונה הזו במקרים שבהם צריך לשייך טריגרים אחרי התקנה לאותו מקור שיוך שהניב את ההתקנה, גם אם יש מקורות שיוך כשירים אחרים שהתרחשו לאחרונה.
    • לדוגמה, יכול להיות שמשתמש ילחץ על מודעה שמובילה להתקנה. אחרי ההתקנה, המשתמש לוחץ על מודעה אחרת ומבצע רכישה. במקרה כזה, יכול להיות שחברת הטכנולוגיה הפרסומית תרצה לשייך את הרכישה לקליק הראשון ולא לקליק של האינטראקציה החוזרת.
  2. שימוש במסננים כדי לצמצם את הנתונים בדוחות ברמת האירוע
    • אפשר להגדיר מסנני המרה כך שיתעלמו מטריגרים נבחרים ויחריגו אותם מדוחות האירועים. יש מגבלות על מספר הטריגרים לכל מקור שיוך, ולכן המסננים מאפשרים לכלול רק את הטריגרים שמספקים את המידע הכי שימושי בדוחות האירועים.
    • אפשר גם להשתמש במסננים כדי לסנן באופן סלקטיבי טריגרים מסוימים, וכך להתעלם מהם. לדוגמה, אם יש לכם קמפיין שמטרגט התקנות של אפליקציות, יכול להיות שתרצו לסנן טריגרים שמופעלים אחרי ההתקנה כדי שלא ישויכו למקורות מהקמפיין הזה.
    • אפשר גם להשתמש במסננים כדי להתאים אישית את נתוני הטריגר על סמך נתוני המקור. לדוגמה, במקור אפשר לציין "product" : ["1234"] כאשר product הוא מפתח המסנן ו-1234 הוא הערך. המערכת מתעלמת מכל טריגר עם מפתח מסנן product שערכו שונה מ-1234.
  3. התאמה אישית של העדיפות של מקורות וטריגרים
    • אם אפשר לשייך כמה מקורות שיוך להפעלה, או שאפשר לשייך כמה הפעלות למקור, אפשר להשתמש במספר שלם חתום של 64 ביט כדי לתעדף שיוכים מסוימים של מקורות או הפעלות על פני אחרים.

עבודה עם MMPs ועם גורמים אחרים

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

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

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