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

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

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

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

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

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

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

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

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

מידות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוחות נצברים

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

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

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

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

דוח מצטבר כולל:

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

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

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

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

לדוגמה:

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

בפועל, דוחות שנצברו\u0000\u0000\x80\u0000

דוחות סיכום

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

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

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

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

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

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

דוגמה:

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

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

שימוש במפתחות צבירה

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

מבנה מפתחות

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

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

סוגים של מפתחות

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

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

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

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

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

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

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

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

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

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

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

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

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

קידוד מקשים

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

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

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

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

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

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

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

מפתח מחושב באמצעות ה-XOR (^) של חלקי המפתח שלו.

דוגמה:

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

סידור חלקים מרכזיים

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

קטע המפתח בצד המקור = 0xa7e297e7c8c8d0540000000000000000
קטע של מפתח בצד הטריגר = 0x0000000000000000674fbe308a597271
מקש =
- 0xa7e297e7c8c8d054000000000000000 ^ 0x000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה:

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

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

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

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

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

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

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

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

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

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

מזהה הקמפיין: 4 ביט (24 = 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 מקודדת את אותו הדבר כמו metricGoalType=0 בגישת מפת מבנה המפתחות. COUNT הוא קצת יותר רזה ומפורש יותר.
בזמן ההמרה, יוצרים מחרוזת שכוללת את כל המאפיינים שאחריהם רוצים לעקוב ואת הערכים שלהם. כדי ליצור קטע של מפתח בצד הטריגר, מגבבים את המחרוזת הזו ומוסיפים קידומת של אפסים ב-64 ביט:
- קטע מפתח בצד הטריגר = <64-bit 00000000...><64-bit hex hash("productCategory=25")>
הדפדפן XORs את החלקים המרכזיים האלה כדי ליצור מפתח.
- מפתח צבירה ב-128 סיביות
  = < 64-bit hex source-side key formula Hash><64-bit hex key-side key בחלק>
לאחר מכן, כשתהיו מוכנים לבקש דוח סיכום עבור המפתח הזה, תוכלו ליצור אותו במהירות:
- על סמך המאפיינים שמעניינים אתכם, יוצרים קטע מפתח בצד המקור ובצד הטריגר כמו שעשיתם קודם.
  - קטע מפתח בצד המקור
    = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000...>
  - קטע מפתח בצד הטריגר
    = <64-bit 00000000...><64-bit hex hash("productCategory=25")>
  - Trigger-side key word = toHex(hash("productCategory=25"))
- בדיוק כמו הדפדפן, XOR את החלקים המרכזיים האלה יוצרים את אותו מפתח שהדפדפן יצר קודם.
  - מפתח צבירה באורך 128 ביט
    = < 64-bit source-side key formula hash><64-bit-bit source key formulaפ>

אם אתם משתמשים בגישה הזו שמבוססת על גיבוב (hash), הנה כמה טיפים מעשיים:

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

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

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

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

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

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

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

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

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

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

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

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

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

מה כדאי למדוד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שאלה

תשובה

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

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

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

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

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

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

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

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

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

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

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

בסוף תקבלו 4 סוגי מפתחות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירה של אלגוריתם גיבוב (hashing)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הקטנת הערכים

2,558,500 מתייחס למספר הרכישות של המפתח הזה, שהתעדכן בהתאם לגורם קנה המידה שחושב קודם לכן. גורם קנה המידה לספירת הרכישות היה 32,768. חלקו 2,558,500 בתקציב התרומה ליעד: 156.15 רכישות = 2,558,500/32,768.
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.

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