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

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

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

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

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

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

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

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

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

מידות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המטען הייעודי מכיל רשימה של תרומות, שכל אחת מהן היא צמד {aggregation key, aggregatable value}:

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

לדוגמה:

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

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

דוחות סיכום

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

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

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

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

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

דוגמה:

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

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

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

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

מבנה המפתח

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

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

סוגי מפתחות

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמה:

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

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

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

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

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

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

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

דוגמה נוספת מופיעה בקטע שיטה ב'.

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

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

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

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

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

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

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

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

לדוגמה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אילו ערכים לאמוד

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

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

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

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

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

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

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

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

תרגום מטרות לערכים של מפתחות

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

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

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

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

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

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

• סוג מפתח 0: סוג יעד המדידה = 0, שבו בחרתם להגדיר ספירת רכישות.
• סוג מפתח 1: measurement goal type = 1, שבו אתם מחליטים להגדיר את purchase value.

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

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

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

בשיטה א', התשובות לשאלות יהיו:

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

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

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

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

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

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

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

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

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

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

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

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

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

בשיטה ב', התשובות לשאלות יהיו:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חלק המפתח בצד המקור למזהה המפתח...	מחרוזת שמכילה את ערכי המאפיינים שרוצים להגדיר	גיבוב של המחרוזת הזו כקסדצימלי, חתוך ל-64 הביטים הראשונים (64/4 = 16 תווים^1)	גיבוב הקסדצימלי עם צירוף של אפסים כדי לפשט את רישום ה-OR . זהו חלק המפתח בצד המקור.
key_purchaseCount	COUNT, CampaignID=12, GeoID=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec000000000000000
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.

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

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

חלק המפתח בצד הטריגר למזהה המפתח...	מחרוזת שמכילה את ערכי המאפיינים שרוצים להגדיר	גיבוב של המחרוזת הזו כקסדצימלי, חתוך ל-64 הביטים הראשונים (64/4 = 16 תווים^1)	גיבוב (hash) של 16 ביט עם אפוסן של אפסים כדי לפשט את השימוש ב-OR. זהו החלק של המפתח בצד המקור.
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 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 × Geography ID 7 × Product category 25:
  • יוצרים את החלק של המפתח בצד המקור, כמו שעשיתם כשהגדרתם אותו בדפדפן.
  • יוצרים את חלק המפתח בצד הטריגר, כמו שעשיתם כשמגדירים אותו בדפדפן.

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

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

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

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

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

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

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

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

צמצום הערכים

• הערך 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.