מסגרת לבדיקת עומסים של שירות צבירה

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

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

1. מומחי טכנולוגיות הפרסום צריכים לגשת למדידת השיוך של ההמרות באמצעות Attribution Reporting API בתרחישי השימוש שלהם לדיווח.
2. טכנולוגיית הפרסום צריכה לקבל החלטות בנוגע לעיצוב תוך צמצום הרעש (הפנייה: בניית מודל להחלטות בנוגע לעיצוב)
3. במהלך הבדיקה, טכנאי הפרסום צריכים לעקוב אחרי מספר המשימות שהם מריצים ביום (למשל, משימות של מפרסמים), אחרי ההתפלגות המשוערת של נפח אירועי ההמרה ואחרי מספר המפתחות המצטברים כקלט לכל משימה לעיבוד (אפשר לעיין בפרמטר של המשימה output_domain_blob_prefix במסמכי התיעוד של Aggregation Service API), וגם אחרי מספר אירועי ההמרה הממוצע המשוער לכל דוח קלט.
4. לצורך בדיקה, מומחי טכנולוגיית הפרסום צריכים לחפש את סוג המכונה המומלץ בטבלת ההנחיות לבחירת גודל, על סמך גודל המשימה הצפוי (כלומר נפח הדוחות, גודל הדומיין) ולהתאים את הגודל של שירות האגרגציה לפריסה בהתאם. מידע נוסף: הנחיות לקביעת היקף לשירות המצטבר ב-AWS
5. טכנאי הפרסום צריכים להריץ משימות צבירת נתונים לבדיקות עומס.

יעדים

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

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

דרישות מוקדמות

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

שלבים

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

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

מספר המפרסמים שיש לכם
לדוגמה, נניח שיש לכם 1,000 מפרסמים.

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

• תחום (לדוגמה: ביטוח, תכשיטים, קמעונאות בצמיחה)
• הוצאות (לדוגמה: פחות מ-50,000$ ברבעון, 50,000$ עד 150,000$ ברבעון, 150,000$ עד 250,000$ ברבעון)
• נפח המרות (נמוך, בינוני, גבוה)

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

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

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

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

• מבנה מפתח 1: (Industry = insurance, spend = <50,000, conversion volume = low)

  • תשובה: 4 מאפיינים: קמפיין (למשל: 50 אפשרויות), קבוצת מודעות (למשל: 20 אפשרויות), סוג מכשיר (למשל: 5 אפשרויות), גיאו (למשל: 50 אפשרויות)
    1. שילובים אפשריים של מאפיינים = 50 x 20 x 5 x 50 = 250,000. המספר הזה מייצג את מספר השילובים האפשריים של המאפיינים למפתחות בצד המקור במבנה המפתח 1.
    2. צריך להקצות 18 ביט (18 ביט = 262,144 שילובים אפשריים)

• מבנה מפתח 2: (Industry = insurance, spend = <50,000, conversion volume = medium)

  • תשובה: 4 מאפיינים: קמפיין (למשל: 30 אפשרויות), קבוצת מודעות (למשל: 80 אפשרויות), סוג מודעה (למשל: 3 אפשרויות), Geo (למשל: 50 אפשרויות).
    1. שילובים אפשריים של המימדים = 30 x 80 x 3 x 50 = 360,000. המספר הזה מייצג את מספר השילובים האפשריים של המאפיינים או המפתחות בצד המקור של מבנה המפתח 2.
    2. צריך להקצות 19 ביט (19 ביט) = 524,288 שילובים אפשריים)

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

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

• מבנה מפתח 1: (Industry = insurance, spend = <50,000, conversion volume = low)

  • תשובה: 2 מאפיינים: קטגוריית מוצרים (למשל: 100 אפשרויות), סוג המרה (למשל: 5 אפשרויות)
    1. שילובים אפשריים של מאפיינים = 100 x 5 = 500
    2. צריך להקצות 9 ביט (9 ביט = 512 שילובים אפשריים)

• מבנה מפתח 2: (Industry = insurance, spend = <50,000, conversion volume = medium)

  • תשובה: 3 מאפיינים: קטגוריית מוצרים (למשל: 50 אפשרויות), סוג המוצר (10 אפשרויות), סוג ההמרה (3 אפשרויות)
    1. שילובים אפשריים של מאפיינים = 50 x 10 x 3 = 1,500
    2. צריך להקצות 11 ביט (11 ביט = 2,048 שילובים אפשריים)

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

אומדנים למפתחות מצטברים

• מבנה מפתח 1: 250,000 מפתחות חשיפות x 500 מפתחות המרות = 125,000,000 מפתחות
• מבנה מפתחות 2: 360,000 מפתחות חשיפות x 1,500 מפתחות המרות = 540,000,000 מפתחות
• מבנה מפתח 3: (תוכלו לתכנן באופן דומה את כל מבני המפתחות שיש לכם)
• חוזרים על הפעולה לכל מבנה מפתח
• מספר מפתחות האגרגציה המקסימלי = 540,000,000 מפתחות (בכל מבני המפתחות). צריך להקצות 30 ביט (30 ביט = 1.07 מיליארד שילובים אפשריים)

נפח ההמרות הצפוי

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

• מבנה מפתח 1: (Industry = insurance, spend = <50,000, conversion volume = low)
  • תשובה: צפוי שהמפרסם יבצע הוצאות בסך כ-500,000 $במהלך הרבעון הקרוב באמצעות מבנה המפתח 1, במחיר ממוצע של 8 $לאלף חשיפות. כתוצאה מכך, צפויות 62,500,000 חשיפות שצריך לרשום.
  • צפוי שהשיעור הממוצע של המרות מחשיפה שיהיה מורכב ממבנה המפתח 1 במהלך הרבעון הבא יהיה 0.08%, וכתוצאה מכך יידרשו 50,000 המרות משויכות לתיעוד. לכל המרה, צריך למדוד את ערך הרכישה ואת מספר הרכישות.
• מבנה מפתח 2: (Industry = insurance, spend = <50,000, conversion volume = medium)
  • תשובה: צפוי שהמילה המפתח 2 תניב הוצאה של כ-800,000$ ברבעון הקרוב, במחיר ממוצע של 10$ לאלף חשיפות. צפויים להירשם 80,000,000 חשיפות.
  • צפוי ששיעור ההמרה הממוצע מחשיפה של מפתח 2 יהיה 0.03125% ברבעון הקרוב, וכתוצאה מכך יידרשו 25,000 המרות משויכות לתיעוד. לכל המרה, צריך למדוד את ערך הרכישה ואת מספר הרכישות.
• חוזרים על הפעולה לכל מבנה מפתח

תדירות הדיווח והאצווה (אצווה לכל מפרסם)**

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

• תשובה: מדי שעה
• ב: יומי
• ג': מדי שבוע

הערות

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

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

• כדי למנוע שגיאות שנובעות מקיבוץ שגוי, חשוב לוודא שהקיבוצים משתמשים בשדה scheduled_report_time ולא בשדה report arrival time. לדוגמה: אם אתם אוספים את הדוחות בכל שעה, האוסף של השעה 11:00 צריך לכלול רק דוחות עם scheduled_report_time בין השעות 10:00 ל-11:00, ולא דוחות שהגיעו בין השעות 10:00 ל-11:00 עם scheduled_report_time שונה (למשל: 9:00).

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

• מבנה מפתח 1: 50,000 המרות משויכות / 2,160 (דיווח שעתי, שעות ברבעון) = 24 דוחות סיכום לשעה לכל מפרסם (24 x 1,000 מפרסמים = 24,000 דוחות סיכום)
• מבנה מפתח 2: 25,000 המרות משויכות / 2,160 (דיווח שעתי, שעות ברבעון) = 12 דוחות סיכום לשעה לכל מפרסם (12 x 1,000 מפרסמים = 12,000 דוחות סיכום)
• מבנה מפתח 3: חזרה
• המספר הכולל של דוחות הסיכום לשעה = 24 דוחות סיכום למבנה המפתח 1 + 12 דוחות סיכום למבנה המפתח 2 + ... = ... לשעה לכל מפרסם

סיכום המשוב

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

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