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

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

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

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

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

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

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

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

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

מידות

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

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

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

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

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

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

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

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

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

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

מהם ערכים שאפשר לצבור?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוח שניתן לאסוף מכיל:

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

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

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

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

לדוגמה:

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

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

דוחות סיכום

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

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

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

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

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

דוגמה:

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

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

מפתחות צבירת נתונים בפועל

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

מבנה המפתח

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

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

סוגי מפתחות

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

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

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

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

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

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

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

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

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

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

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

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

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

קידוד מפתחות

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

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

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

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

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

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

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

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

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

דוגמה:

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

התאמת החלקים העיקריים

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

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

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

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

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

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

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

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

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

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

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

כך זה עובד:

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

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

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

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

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

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

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

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

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

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

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

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

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

מה כדאי למדוד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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 בסך 210 ש"ח.

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

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

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

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

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

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

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

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

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

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

• key_purchaseCount: ‏ 1 x 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,
  })
);

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

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

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

[
  {
    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 בפורמט בינארי. שימו לב שהמפתחות הם הטרוגניים (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.