הסבר על מפתחות צבירה לדוחות שיוך (Attribution)

מהם מפתחות צבירה, איך משתמשים בהם ב-Attribution Reporting API ואיך אפשר לתרגם מטרות למפתחות.

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

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

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

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

מאפיינים, מפתחות וערכים

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

מידות

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

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

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

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

מהם מפתחות צבירה (buckets)?

המונחים 'מפתח צבירה' ו'bucket' מתייחסים לאותו הדבר. מפתח הצבירה משמש בממשקי ה-API של הדפדפן שמשמשים להגדרת דוחות. המונח bucket (מאגר) משמש בדוחות הניתנים לצבירה ובדוחות הסיכום, וגם בממשקי ה-API של Aggregation Service.

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

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

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

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

מהם ערכים שניתן לצבור?

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

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

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

כשמשתמש שממוקם במיקום הגיאוגרפי עם מזהה 7 רואה מודעה עם מזהה קמפיין 12, ולאחר מכן מבצע המרה ברכישת מוצר מקטגוריית מוצרים 25 במחיר של 120$ (בהנחה שהמטבע שלכם הוא דולר ארה"ב), אתם יכולים להגדיר מפתח צבירה וערכים ניתנים לצבירה שייראו כך:

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

הערכים שניתנים לצבירה מסוכמים כדי ליצור תובנות מצטברות לגבי יעדי המדידה שלכם.

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

ממפתחות וערכים לדוחות

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

דוחות שניתן לצבור

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

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

בהמשך נראה שדוח ניתן לצבירה {מפתח צבירה, ערך ניתן לצבירה} לא נראה בדיוק כך – אבל כרגע נתמקד במידע שמופיע בדוח.

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

דוח שאפשר לצבור בו נתונים כולל:

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

דוחות שניתן לצבור הם בפורמט JSON וכוללים, בין היתר, שדה מטען ייעודי (payload) שישמש כקלט נתונים לדוח הסיכום הסופי.

המטען הייעודי (payload) מכיל רשימה של תרומות, שכל אחת מהן היא צמד {מפתח צבירה, ערך ניתן לצבירה}:

• ‫bucket: מפתח הצבירה, מקודד כמחרוזת בייטים.
• ‫value: הערך המצטבר של יעד המדידה הזה, בקידוד כמחרוזת בייטים.

לדוגמה:

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

בפועל, דוחות שניתן לצבור מקודדים באופן שגורם לדליים ולערכים להיראות שונה מהדוגמה הקודמת (כלומר, דלי יכול להיראות כמו \u0000\u0000\x80\u0000). Bucket ו-value הם מחרוזות של בייטים.

דוחות סיכום

דוחות שניתן לצבור אותם נצברים בדפדפנים ובמכשירים רבים (משתמשים) באופן הבא:

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

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

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

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

דוגמה:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

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

מפתחות צבירה בפועל

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

מבנה המפתח

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

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

סוגי מפתחות

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

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

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

• מספר הרכישות הוא הסוג הראשון של יעד מדידה.
• ערך רכישה הוא סוג היעד השני למדידה.

אם הגדרתם n יעדי מדידה, לסוג יעד המדידה יהיו n סוגים שונים של ערכים.

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

גודל המפתח, גודל המאפיין

גודל המפתח המקסימלי מוגדר בביטים – מספר האפסים והאחדות בפורמט בינארי ליצירת המפתח המלא. ה-API מאפשר אורך מפתח של 128 ביטים.

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

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

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

‫7 ביט יכולים לאחסן רק 2⁷ = 128 אפשרויות שונות, שזה פחות מ-200 האפשרויות הנדרשות.

‫8 ביט יאפשרו אחסון של 2⁸ = 256 אפשרויות שונות, שזה יותר מ-200 האפשרויות הנדרשות, ולכן אפשר להשתמש ב-n=8 ביט כדי לקודד את המימד הזה.

קידוד מפתח

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

הגדרת שני חלקי מפתח למפתח מלא

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

• מזהה הקמפיין
• מזהה גיאוגרפי
• קטגוריית המוצר

בעוד שהמאפיינים Campaign ID (מזהה קמפיין) ו-Geography ID (מזהה מיקום גיאוגרפי) ידועים בזמן הצגת המודעה (זמן הצגת המודעה), המאפיין Product category (קטגוריית מוצר) יהיה ידוע מאירוע הפעלה, כשהמשתמש ישלים המרה (זמן ההמרה).

בפועל, זה אומר שתגדירו מפתח בשני שלבים:

1. תגדירו חלק אחד של המפתח – מזהה קמפיין × מזהה גיאוגרפי – בזמן הלחיצה או הצפייה.
2. את החלק השני של המפתח – קטגוריית מוצרים – מגדירים בזמן ההמרה.

החלקים השונים של המפתחות נקראים חלקי מפתח.

מפתח מחושב על ידי ביצוע פעולת OR ‏ (v) על חלקי המפתח שלו.

דוגמה:

• חלק המפתח בצד המקור = 0x159
• חלק המפתח בצד הטריגר = 0x400
• מקש = 0x159 v 0x400 = 0x559

התאמה של חלקים מרכזיים

עם שני חלקי מפתח של 64 ביט שהורחבו ל-128 ביט באמצעות מילויים או היסטים של 64 ביט שהוצבו בקפידה (16 האפסים), פעולת OR על חלקי המפתח שקולה לשרשור שלהם, וקל יותר להבין ולאמת אותה:

• חלק המפתח בצד המקור = 0xa7e297e7c8c8d0540000000000000000
• חלק המפתח בצד הטריגר = 0x0000000000000000674fbe308a597271
• מקש = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

כמה מפתחות לכל קליק או צפייה במודעה

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

• מפתח שעוקב אחרי מזהה גיאוגרפיה × מזהה קמפיין.
• מפתח נוסף שעוקב אחרי סוג הקריאייטיב × מזהה הקמפיין.

דוגמה נוספת מופיעה באסטרטגיה ב'.

קידוד מאפיינים במפתחות

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

דוחות הסיכום מכילים צמדים גולמיים של {מפתח, ערך סיכום}, ולא מידע נוסף על המפתח. משמעות השינוי:

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

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

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

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

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

לדוגמה:

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

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

עם יעדי המדידה האלה, למאפיין המפתח יש את המאפיינים הבאים:

• קטגוריית המוצר
• סוג יעד המדידה
• מזהה גיאוגרפי
• מזהה הקמפיין

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

• ‫29 קטגוריות שונות של מוצרים.
• 8 אזורים גיאוגרפיים שונים: צפון אמריקה, מרכז אמריקה, דרום אמריקה, אירופה, אפריקה, אסיה, הקריביים ואוקיאניה.
• 16 קמפיינים שונים.

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

• קטגוריית מוצרים: 5 ביטים (‎2⁵ = 32 > 29).
• סוג יעד המדידה: ביט אחד. יעד המדידה הוא מספר הרכישות או ערך הרכישות, כלומר יש שתי אפשרויות שונות, ולכן מספיק ביט אחד כדי לאחסן את הנתון הזה.

• מזהה מיקום גיאוגרפי: 3 ביטים (2³ = 8). כדאי גם להגדיר מיפוי של מאפיין מזהה גיאוגרפי כדי לדעת איזה אזור גיאוגרפי מייצג כל ערך בינארי. מיפוי המאפיינים שלכם למאפיין 'מזהה גיאוגרפי' עשוי להיראות כך:

  ערך בינארי במפתח	גיאוגרפיה
  000	צפון אמריקה
  001	מרכז אמריקה
  010	דרום אמריקה
  011	אירופה
  100	אפריקה
  101	אסיה
  110	קריביים
  111	אוקיאניה

• מזהה הקמפיין: 4 ביטים (2⁴ = 16)

מפתחות שנוצרו לפי המבנה הזה יהיו באורך 13 ביט (5 + 1 + 3 + 4).

בדוגמה הזו, מפת מבנה המפתחות של המפתחות האלה תיראה כך:

סדר המאפיינים בתוך המפתח תלוי בכם.

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

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

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

נניח שמפתח לדוגמה הוא 0b1100100111100, ושאתם יודעים שהמפתח הזה תואם למבנה המפתח שמוצג בתרשים הקודם.

לפי מפת מבנה המפתח, המפתח הזה יפוענח כך:

`11001 0 011 1100`

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

קידוד מימדים באמצעות פונקציית גיבוב

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

כך זה עובד:

1. בוחרים אלגוריתם גיבוב.
2. בזמן הצגת המודעה, יוצרים מחרוזת שכוללת את כל המאפיינים שרוצים לעקוב אחריהם ואת הערכים שלהם. כדי ליצור את חלק המפתח בצד המקור, מבצעים גיבוב של המחרוזת הזו ומומלץ להוסיף סיומת של אפסים באורך 64 ביט כדי להתאים אותה לחלק המפתח בצד הטריגר, וכדי להקל על ההסקה לגבי OR.
   • חלק המפתח בצד המקור
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • שימו לב ש-COUNT מקודד את אותו הדבר כמו measurementGoalType=0 בגישה של מיפוי מבנה המפתח. ‫COUNT קצת יותר רזה ומפורש.
3. בזמן ההמרה, יוצרים מחרוזת שכוללת את כל המאפיינים שרוצים לעקוב אחריהם ואת הערכים שלהם. כדי ליצור חלק מהמפתח בצד הטריגר, מבצעים גיבוב של המחרוזת הזו ומוסיפים קידומת של אפסים באורך 64 ביט:
   • חלק מהמפתח בצד הטריגר = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. הדפדפן מבצע פעולת OR על חלקי המפתח האלה כדי ליצור מפתח.
   • מפתח צבירה של 128 ביט
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. בהמשך, כשתרצו לבקש דוח סיכום למפתח הזה, תוכלו ליצור אותו באופן מיידי:
   • על סמך המאפיינים שמעניינים אתכם, יוצרים קטע מפתח בצד המקור וקטע מפתח בצד הטריגר, כמו שעשיתם קודם.
     • חלק המפתח בצד המקור
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • חלק המפתח בצד הטריגר
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • חלק המפתח בצד הטריגר = toHex(hash("productCategory=25"))
   • בדומה לדפדפן, אפשר להשתמש בחלקים האלה של המפתח כדי ליצור את אותו מפתח שהדפדפן יצר קודם.
     • מפתח צבירה של 128 ביט
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

כמה טיפים מעשיים לשימוש בגישה הזו שמבוססת על גיבוב:

• חשוב להשתמש תמיד באותו סדר של המימדים. כך אפשר לוודא שאפשר ליצור מחדש את הגיבובים באופן מהימן. (הפונקציה "COUNT, CampaignID=12, GeoID=7" לא תיצור את אותו גיבוב כמו הפונקציה "COUNT, GeoID=7, CampaignID=12"). דרך פשוטה להשיג את זה היא למיין את המאפיינים בסדר אלפאנומרי. זה מה שנעשה בדוגמה, חוץ מהעובדה שתמיד נגדיר את COUNT או VALUE כפריט הראשון במאפיין – זו בחירה שנועדה לשפר את הקריאות, כי COUNT או VALUE מקודדים מידע ששונה קונספטואלית מכל שאר המאפיינים.
• חשוב לעקוב אחרי קבוצת המאפיינים שבהם אתם משתמשים במפתחות. אתם רוצים להימנע מיצירת מפתחות שמבוססים על קבוצה של מאפיינים שמעולם לא השתמשתם בהם.
• התנגשויות של ערכי Hash הן נדירות אם נעשה שימוש בפונקציית Hash מתאימה, אבל בדיקה מול ערכי Hash שהיו בשימוש בעבר (שצריכים להישמר כדי לפרש את התוצאות משירות הצבירה) יכולה למנוע הוספה של מפתחות חדשים שמתנגשים עם מפתחות ישנים יותר.

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

ערכים שניתן לצבור בפועל

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

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

המגבלה הזו נקראת CONTRIBUTION_BUDGET. בהסבר, המגבלה הזו נקראת תקציב L1, אבל היא זהה לCONTRIBUTION_BUDGET.

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

דוגמה: המרה אחת לכל קליק או צפייה

בדוגמה הזו, נניח שאתם רוצים לקבל תשובות לשאלות הבאות:

• אילו קטגוריות מוצרים הן הכי משתלמות בכל אזור?
• אילו אסטרטגיות קמפיין הכי יעילות בכל אזור?

נניח שבתרחיש השימוש שלכם, אתם צריכים תובנות שבועיות.

צריך גם לעקוב אחרי הפעולות הבאות:

• 16 קמפיינים שונים.
• 8 אזורים גיאוגרפיים שונים: צפון אמריקה, מרכז אמריקה, דרום אמריקה, אירופה, אפריקה, אסיה, הקריביים ואוקיאניה.
• ‫29 קטגוריות מוצרים שונות.

מה כדאי למדוד

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

בדוגמה הזו נתמקד בהגדרות קמפיין שמודדות רק המרה אחת לכל קליק או צפייה: רכישה.

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

מה לגבי מטבעות?

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

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

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

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

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

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

• אסטרטגיה א': מבנה מפתח גרנולרי אחד.
• אסטרטגיה ב': שני מבני מפתח גסים.

אסטרטגיה א': עץ עמוק אחד (מבנה מפורט אחד של מילות מפתח)

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

כל המפתחות שלכם משתמשים במבנה הזה.

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

• סוג מפתח 0: סוג יעד המדידה = 0, שאתם מחליטים להגדיר כמספר הרכישות.
• סוג מפתח 1: סוג יעד המדידה = 1, שאתם מגדירים כערך רכישה.

דוחות הסיכום נראים כך:

אפשר לחשוב על אסטרטגיה א' כאסטרטגיה של 'עץ בעומק אחד':

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

אם תשתמשו באסטרטגיה א', התשובות לשאלות יהיו:

בנוסף, תוכלו לענות ישירות על השאלה השלישית באמצעות אסטרטגיה א':

"כמה הכנסות הניב כל אחד מהמוצרים שלי בכל אחד מהקמפיינים שלי בכל אזור גיאוגרפי?"

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

אסטרטגיה ב': שני עצים רדודים (שני מבני מפתח גסים)

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

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

• סוג יעד המדידה = 0, שאתם מחליטים להגדיר כמספר הרכישות.
• סוג יעד המדידה = 1, שאתם מחליטים להגדיר כערך רכישה.

בסופו של דבר, יש ארבעה סוגים של מפתחות:

• סוג המפתח I-0: מבנה המפתח I, מספר הרכישות.
• סוג מפתח I-1: מבנה מפתח I, ערך רכישה.
• סוג מפתח II-0: מבנה מפתח II, מספר הרכישות.
• סוג מפתח II-1: מבנה מפתח II, ערך רכישה.

דוחות הסיכום נראים כך:

אפשר לחשוב על אסטרטגיה ב' כאסטרטגיה של 'שני עצים רדודים':

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

אם תבחרו באסטרטגיה ב', התשובות לשאלות יהיו:

החלטה: אסטרטגיה א'

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

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

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

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

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

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

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

בחירת אלגוריתם גיבוב

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

נניח שבחרתם באפשרות SHA-256. אפשר גם להשתמש באלגוריתם פשוט יותר ופחות מאובטח, כמו MD5.

בדפדפן: הגדרת מפתחות וערכים

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

בהמשך מופיעה סקירה כללית של הכותרות שתגדירו כדי לרשום מפתחות וערכים בדפדפן:

הגדרת חלקים מרכזיים בצד המקור

כשמשתמש לוחץ על מודעה או צופה בה, צריך להגדיר את מפתחות הצבירה בכותרת Attribution-Reporting-Register-Aggregatable-Source. בשלב הזה, לכל מפתח אפשר להגדיר רק את החלק של המפתח, או key piece, שידוע בזמן הצגת המודעה.

בואו ניצור את החלקים העיקריים:

עכשיו נגדיר את החלקים העיקריים:

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

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

אופציונלי: דוחות ברמת האירוע

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

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

משתמש משלים המרה

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

• מגדירים את החלקים העיקריים של המפתח בצד ההמרה (בצד הטריגר) כדי להשלים את המפתח. תגדירו את הרכיבים העיקריים האלה באמצעות הכותרת Attribution-Reporting-Register-Aggregatable-Trigger-Data.
• מגדירים את הערך המצטבר של ההמרה באמצעות הכותרת Attribution-Reporting-Register-Aggregatable-Values.

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

בואו ניצור את החלקים העיקריים:

עכשיו נגדיר את החלקים העיקריים:

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

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

הגדרת ערכים שניתן לצבור

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

נניח שבוצעה רכישה אחת של מוצר מסוג 25 במחיר של 52$.

לא מגדירים את הערכים האלה ישירות כערכים שניתן לצבור:

• ‫key_purchaseCount: המרה אחת
• key_purchaseValue: 52$

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

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

במקרה כזה, לכל יעד מוקצה מקסימום של CONTRIBUTION_BUDGET/2 (‎=65,536/2=32,768).

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

גורם קנה המידה של ערך הרכישה צריך להיות:

‫((CONTRIBUTION_BUDGET/2) / 1,500) = 32,768/1,500 = 21.8 ≈ 22

מקדם ההרחבה שלכם למספר הרכישות הוא 32,768/1 = 32,768, כי החלטתם לעקוב אחרי רכישה אחת לכל היותר לכל קליק על מודעה או צפייה במודעה (אירוע המקור).

עכשיו אפשר להגדיר את הערכים הבאים:

• ‫key_purchaseCount: 1 × 32,768 = 32,768
• ‫key_purchaseValue: 52 × 22 = 1,144

בפועל, מגדירים אותם באופן הבא באמצעות הכותרת הייעודית Attribution-Reporting-Register-Aggregatable-Values:

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

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

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

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

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

כאן אפשר לראות שתי תרומות נפרדות בדוח אחד שניתן לצבירה.

בקשה לדוח סיכום

• דוחות שאפשר לצבור בהם נתונים. פועלים לפי העצות שמופיעות במאמר בנושא עיבוד בקבוצות.
• יוצרים את המפתחות שרוצים לראות את הנתונים שלהם. לדוגמה, כדי לראות נתוני סיכום של COUNT (מספר הרכישות הכולל) ושל VALUE (ערך הרכישה הכולל) עבור מזהה הקמפיין 12 × מזהה המיקום הגיאוגרפי 7 × קטגוריית המוצרים 25:
  • יוצרים את חלק המפתח בצד המקור, כמו שעשיתם כשהגדרתם אותו בדפדפן.
  • יוצרים את חלק המפתח בצד הטריגר, כמו שעשיתם כשהגדרתם אותו בדפדפן.

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

טיפול בדוח הסיכום

בסופו של דבר, תקבלו דוח סיכום שעשוי להיראות כך:

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

הבאקט הראשון הוא המפתח COUNT בפורמט בינארי. הקטגוריה השנייה היא VALUE key בפורמט בינארי. שימו לב: המפתחות הם הטרוגניים (COUNT לעומת VALUE), אבל הם מופיעים באותו דוח.

הקטנת הערכים

• ‫2,558,500 הוא מספר הרכישות של המפתח הזה, אחרי שהוכפל בפקטור ההתאמה שחישבתם קודם. הגורם לקביעת קנה מידה של ספירת הרכישות היה 32,768. מחלקים את הסכום 2,558,500 בתקציב התרומה של המטרה: 2,558,500/32,768 = 156.15 רכישות.
• ‫687,060 ← 687,060/22 = 31,230 $‎ ערך הרכישה הכולל.

כתוצאה מכך, בדוחות הסיכום מוצגות התובנות הבאות:

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.