דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

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

מידות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוחות נצברים

כשמשתמש לוחץ על מודעה או צופה בה ומאוחר יותר מבצע המרה, אתם מנחים את הדפדפן לשמור צמד {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 הם שניהם בייט-מחרוזות.

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

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

מבנה המפתחות

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

לדוגמה, מזהה הקמפיין × 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 בהקסדצימלי; שהוא 25 במספר העשרוני, לא 19. מספרים בינאריים בדרך כלל מתחילים ב-0b. לדוגמה, 0b11001 הוא 11001 בבינארי. כלומר 25 במספר העשרוני, לא 11,001.

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

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

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

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

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

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

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

כדי לחשב מפתח, צריך לקחת את ה-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) כדי ליצור מפתחות באופן דינמי בצורה עקבית ואמינה.

זה עובד כך:

בוחרים אלגוריתם גיבוב (hashing).
בזמן הצגת המודעה, יוצרים מחרוזת שכוללת את כל המאפיינים שרוצים לעקוב אחריהם ואת הערכים שלהם. כדי ליצור את חלק המפתח בצד המקור, לבצע גיבוב של המחרוזת הזו וכדאי להוסיף סיומת של אפסים באורך 64 ביט כדי ליישר אותו בעזרת המקש בצד הטריגר, כך של-XOR יהיה קל יותר לחשוב על זה.
- חלק מפתח בצד המקור
  = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
- חשוב לשים לב שהמקודד COUNT מקודד את אותו קידוד כמו measurementGoalType=0 בגישה של מפת מבנה המפתחות. COUNT הוא קצת נקי יותר ויותר בוטה.
בזמן ההמרה, יוצרים מחרוזת שכוללת את כל המאפיינים שרוצים לעקוב אחריהם. את הערכים שלהם. כדי ליצור קטע מפתח בצד הטריגר, צריך לגבב את המחרוזת הזו ולהוסיף קידומת של 64 ביט של אפסים:
- חלק מפתח בצד הטריגר = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
הדפדפן XOR מעביר את חלקי המפתח האלה כדי ליצור מפתח.
- מפתח צבירה של 128 ביט
  = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
בשלב מאוחר יותר, כשרוצים לבקש דוח סיכום למפתח הזה, אפשר ליצור אותו במהירות:
- על סמך המאפיינים הרצויים, יוצרים חלק מפתח בצד המקור ובצד הטריגר כפי שעשיתם קודם לכן.
  - חלק מפתח בצד המקור
    = <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, שאותו אתם מחליטים להגדיר purchase count.
סוג מפתח 1: סוג יעד המדידה = 1, שאותו אתם מחליטים להגדיר ערך רכישה.

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

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

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

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

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

שאלה

תשובה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המדד שאתם רוצים לבקש¹	חלק מפתח בצד המקור	חלק מפתח בצד הטריגר	מפתח לבקשה לשירות הצבירה²
מספר רכישות כולל (`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). קטגוריה ו 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.