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

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

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

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

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

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

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

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

הערה: מפתחות הצבירה שמוזכרים במסמך הזה הם ספציפיים ל-Attribuion Reporting API.

מידות

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

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

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

הערה: בתרשים שבמסמך זה נציג את המימדים באופן הבא:

• מימדים הידועים בזמן הצגת המודעה על רקע ירוק.
• מידות הידועות בזמן ההמרה על רקע צהוב ומודגשות בקו תחתון.

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

מאפיינים למעקב

מהם מפתחות צבירה (קטגוריות)?

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

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

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

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

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

מהם ערכים נצברים?

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

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

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

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

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

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

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

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

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

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

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

דוחות נצברים

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

הערה: בהסבר, צמד של {aggregation key, aggregatable value} נקרא גם תרומת היסטוגרמה: הוא מייצג את האופן שבו ההמרה הזו, ואת המאפיינים והערכים שמשויכים אליה, מוסיפים לדוח הסיכום.

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

בהמשך תראו שדוח {aggregation key, aggregatable value} לא נראה בדיוק כך. בינתיים, נתמקד במידע שכלול בדוח.

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

דוח נצברים כולל:

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

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

המטען הייעודי (Payload) מכיל רשימה של תכנים שנוספו, כל אחד מהם הוא צמד {aggregation key, aggregatable value}:

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

לדוגמה:

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

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

דוחות סיכום

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

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

התוצאה היא דוח סיכום שמכיל קבוצה של {aggregation key, Summary value} זוגות של {aggregation key,summary value}.

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

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

דוגמה:

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

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

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

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

מבנה המפתחות

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

לדוגמה, מזהה הקמפיין × GeoID × Product Category (קטגוריית מוצרים) הוא מבנה מרכזי.

סוגי מפתחות

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

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

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

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

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

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

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

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

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

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

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

7 ביטים יאחסנו רק את הערך 2⁷ = 128 אפשרויות נפרדות, פחות מ-200 האפשרויות הנדרשות.

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

קידוד מפתחות

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

הערה: נתונים הקסדצימליים בדרך כלל מתחילים ב-0x. לדוגמה, 0x19 הוא 19 בהקסדצימלי; 0x25 הוא 25 בעשרוני, ולא 19. התחילית של מספרים בינאריים היא בדרך כלל 0b. לדוגמה, 0b11001 הוא 11001 בבינארי, כלומר 25 בעשרוני ולא 11,001.

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

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

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

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

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

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

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

אזהרה: המסמך מתאר בטעות חלקים עיקריים כשמשלבים אותם באמצעותbitwise-XOR, כשלמעשה הם משולבים באמצעות bitwise-OR.

כדי לחשב מפתח, צריך לקחת את ה-XOR (^) של חלקי המפתח שלו.

דוגמה:

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

יישור של חלקים מרכזיים

עם שני חלקי מפתח של 64 ביט שמורחבים ל-128 ביטים באמצעות פונקציות מילוי/היסטים של 64 ביט המוצבים בקפידה (6-10 אפסים), ערכי XOR-0 של מפתחי אחד מקבילים לשרשור של כל אחד מהם, כך שקל יותר להסיק אותו ולאמת אותו:

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

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

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

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

לדוגמה, אפשר לעיין באסטרטגיה ב'.

קידוד המאפיינים למפתחות

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

דוחות הסיכום מכילים צמדי {key, Summary value} גולמיים, ואין בהם מידע נוסף על המפתח. משמעות השינוי:

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

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

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

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

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

לדוגמה:

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

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

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

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

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

• 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 שהושק באירופה.

קידוד של מאפיינים באמצעות פונקציית גיבוב (hash)

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

זה עובד כך:

1. בוחרים אלגוריתם גיבוב (hashing).
2. בזמן הצגת המודעה, יוצרים מחרוזת שכוללת את כל המאפיינים שרוצים לעקוב אחריהם ואת הערכים שלהם. כדי ליצור את חלק המפתח בצד המקור, מומלץ לגבב את המחרוזת הזו. מומלץ להוסיף סיומת של אפסים בגודל 64 ביט כדי ליישר אותה לפי המפתח בצד הטריגר, כדי שיהיה קל יותר להסביר את ה-XOR באמצעותו.
   • חלק מפתח בצד המקור
     = <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. הדפדפן XOR מעביר את חלקי המפתח האלה כדי ליצור מפתח.
   • מפתח צבירה של 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"))
   • בדיוק כמו הדפדפן, XOR את חלקי המפתח האלה כדי ליצור את אותו מפתח שהדפדפן יצר קודם.
     • מפתח צבירה של 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 מקודדים מידע שהקונספט שלו שונה מעט מכל המאפיינים האחרים.
• יש לעקוב אחר קבוצת המאפיינים שבה אתם משתמשים במפתחות. אתם רוצים להימנע מיצירת מפתחות על סמך קבוצה של מאפיינים שמעולם לא השתמשתם בהם.
• התנגשויות 'גיבובים' הן נדירות. אבל אם משתמשים בפונקציית גיבוב מתאימה, מומלץ לבדוק מול גיבובים שהיו בשימוש בעבר (שצריך לאחסן כדי לפרש את התוצאות משירות הצבירה) כדי להימנע מהכנסת מפתחות חדשים שמתנגשים עם מפתחות ישנים.

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

ערכים נצברים בפועל

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

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

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

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

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

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

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

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

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

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

מה כדאי למדוד

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

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

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

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

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

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

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

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

תרגום מטרות עסקיות למפתחות

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

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

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

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

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

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

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

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

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

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

בעזרת אסטרטגיה א' תענו על השאלות הבאות:

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

בעזרת אסטרטגיה א' תוכלו גם לענות ישירות על השאלה השלישית הבאה:

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

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

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

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

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

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

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

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

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

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

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

בעזרת אסטרטגיה ב' תענו על השאלות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חלק המפתח בצד המקור למזהה המפתח...	מחרוזת שמכילה את ערכי המאפיינים שרוצים להגדיר	גיבוב (hash) של המחרוזת הזו בפורמט הקסדצימלי, חתוך בהתאם ל-64 הביטים הראשונים (64/4 = 16 תווים^1)	גיבוב הקסדצימלי עם צירוף של אפסים כדי לפשט את יצירת ה-XOR . זהו חלק המפתח בצד המקור.
key_purchaseCount	COUNT, CampaignID=12, GeoID=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	VALUE, CampaignID=12, GeoID=7	0x245265f432f16e73	0x245265f432f16e730000000000000000

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

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

// 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.

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

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

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

חלק המפתח בצד הטריגר למזהה המפתח...	מחרוזת שמכילה את ערכי המאפיינים שרוצים להגדיר	גיבוב (hash) של המחרוזת הזו בפורמט הקסדצימלי, חתוך בהתאם ל-64 הביטים הראשונים (64/4 = 16 תווים^1)	גיבוב הקסדצימלי עם צירוף של אפסים כדי simplify את יצירת ה-XOR. זה חלק המפתח בצד המקור.
key_purchaseCount	ProductCategory=25	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
key_purchaseValue	(זהה)	(זהה)	(זהה)

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

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

// 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) המוצפן לצד המטא-נתונים של הדוחות.

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

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR 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 XOR 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 × Geography ID 7 × Product category 25:
  • יוצרים את חלק המפתח בצד המקור, כמו שעשיתם כשמגדירים אותו בדפדפן.
  • יוצרים את חלק המפתח בצד הטריגר, כמו שעשיתם כשמגדירים אותו בדפדפן.

המדד שאתם רוצים לבקש^1	חלק מפתח בצד המקור	חלק מפתח בצד הטריגר	מפתח לבקשה לשירות הצבירה^2
מספר רכישות כולל (COUNT)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
ערך רכישה כולל (VALUE)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹המדד הרצוי (למזהה הקמפיין 12 × Geography ID 7 × קטגוריית המוצר 25). ²מפתח לבקשה לשירות הצבירה = חלק המפתח בצד המקור XOR חלק המפתח בצד הטריגר.

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

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

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

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

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

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

שינוי קנה המידה של הערכים

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

לכן, דוחות הסיכום מספקים את התובנות הבאות:

• במהלך תקופת הדיווח, קמפיין מס' 12 שפעל באירופה יצר כ-156 רכישות (± "רעש") בקטגוריית המוצרים מס' 25.
• במהלך תקופת הדיווח, קמפיין מס' 12 שפעל באירופה גרם לרכישות של 31,230$ (רעש ±) עבור קטגוריית המוצרים מס' 25.