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

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

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

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

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

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

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

תרשים של תהליך העבודה לשילוב שיוך (Attribution)

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

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

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

היכרות עם ה-API

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

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

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

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

לפני השילוב

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

התעניינות השותפים

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

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

שיוך ברמת האירוע באפליקציה – אב-טיפוס

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

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

בדיקות הדמיה

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

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

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

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

שיוך (Attribution) של שרת צבירה אב-טיפוס: הגדרה

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

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

שיוך (Attribution) של שרת צבירת אב-טיפוס: שילוב

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

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

עיצוב חוזר עם תכונות אופציונליות

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

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

התאמה אישית של התנהגויות שיוך (Attribution)

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

עבודה עם MMP ועם אחרים

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

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

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