כל צוות monetization מכיר את התחושה: אתם בטוחים ששינוי ב-waterfall ישפר את ההכנסות, אבל ברגע שאתם משיקים אותו לייב אתם עוצרים נשימה. מה אם זה יתפוצץ בפנים? מה אם ה-fill rate יקרוס? מה אם בדיוק גרמתם לחברה שלכם להפסיד אלפי דולרים בזמן שלוקח לשים לב ולחזור אחורה?
הפחד הזה אינו לא רציונלי — זוהי הסיבה שרוב המפרסמים משאירים את הגדרות ה-waterfall שלהם ללא שינוי במשך חודשים, ומשאירים revenue משמעותי על השולחן. הפתרון אינו להפסיק לבצע שינויים. הפתרון הוא לבדוק אותם כראוי לפני המחויבות.
למה בדיקת waterfall שונה
A/B testing של waterfall זה לא כמו בדיקת צבע של כפתור או זרימת onboarding. הכנסות מפרסום הן מטבען רועשות — הן משתנות לפי שעה, יום בשבוע, עונה ועשרות גורמים נוספים. שינוי שנראה כמו שיפור של 10 אחוז ביום שני עשוי להיות מוסבר לגמרי על ידי שונות שבועית נורמלית. ובניגוד ל-A/B tests של מוצר שבהם variant גרוע גורם לחוויית משתמש קצת פחות טובה, variant גרוע ב-waterfall יכול להיות אלפי דולרים של revenue אבוד ביום.
גישת פיצול התנועה
הדרך הבטוחה ביותר לבדוק שינויים ב-waterfall היא לפצל את התנועה שלכם בין הקונפיגורציה הנוכחית (control) והשינוי המוצע (variant). רוב פלטפורמות ה-mediation — כולל AppLovin MAX ו-Unity LevelPlay — תומכות בסגמנטציית תנועה המאפשרת לנתב אחוז מהמשתמשים לקונפיגורציית waterfall שונה.
איך להקים בדיקה נקייה
התחילו עם חלוקה 90/10: 90 אחוז מהתנועה ממשיכה ב-waterfall הנוכחי ו-10 אחוז מקבלים את הקונפיגורציה החדשה. זה מגביל את הסיכון לצד השלילי ל-10 אחוז מהתנועה תוך מתן מספיק נתונים לזהות הבדלים משמעותיים. הריצו את הבדיקה לפחות שבעה ימים כדי לתפוס את המחזוריות השבועית של ביקוש הפרסום.
מה למדוד
אל תמדדו רק eCPM. עקבו אחרי המדדים האלה עבור שתי הקבוצות: revenue כולל לאלף משתמשים פעילים יומיים (revenue per mille DAU), fill rate, eCPM ממוצע, impression לסשן ו — קריטי — שימור משתמשים. שינוי waterfall שמעלה eCPM ב-15 אחוז אבל מאריך את זמן טעינת הפרסומות ומוריד שימור של 7 ימים ב-2 אחוז הוא שלילי נטו.
שיטת קבוצת ה-holdout
עבור שינויים משמעותיים יותר — כמו הוספה או הסרה של demand source, או שינוי מבנה של כל ה-waterfall — השתמשו בקבוצת holdout. שמרו 20 אחוז מהתנועה על הקונפיגורציה הישנה באופן קבוע (או למשך הבדיקה) והשיקו את הקונפיגורציה החדשה ל-80 האחוז הנותרים. זה נותן לכם קו בסיס קבוע להשוואה, דבר שיקר במיוחד לשינויים שההשפעה שלהם עשויה לקחת שבועות להתממש.
השקות הדרגתיות
לאחר שבדיקה מראה תוצאות חיוביות ב-10 אחוז, אל תדחפו מיד ל-100 אחוז. העלו ל-25 אחוז למשך כמה ימים נוספים, אחר כך ל-50 אחוז, אחר כך ל-75, ולבסוף ל-100. כל שלב נותן לכם נקודת ביקורת לוודא שהשיפור מחזיק מעמד גם בנפחי תנועה גבוהים יותר ולתפוס בעיות שצצות רק בקנה מידה גדול — כמו demand partner שמבצע טוב בנפח נמוך אך לא יכול לשמור על fill rate כשנותנים לו יותר תנועה, או באג אינטגרציה שמתגלה רק כשעוברים סף מסוים של impression ביום.
המפרסמים שמגדילים את הכנסות הפרסום שלהם באופן עקבי אינם אלה שעושים את השינויים הנועזים ביותר — הם אלה שבודקים כל שינוי בשיטתיות ומתחייבים רק לזוכים. שיפורים קטנים ומאומתים מצטברים לרווחים עצומים לאורך זמן.
טעויות בדיקה נפוצות
בדיקת יותר מדי משתנים בבת אחת
שנו דבר אחד בכל בדיקה. אם אתם מתאימים במקביל מחירי floor, מוסיפים demand source חדש ומסדרים מחדש את עדיפות ה-waterfall, אינכם יכולים לייחס את התוצאה לאף שינוי יחיד. בודדו את המשתנים.
סיום בדיקות מוקדם מדי
להכנסות פרסום יש אפקטים משמעותיים של יום-בשבוע. בדיקה שרצה משני ועד רביעי תיתן תמונה שונה מבדיקה שכוללת סוף שבוע מלא. תמיד הריצו בדיקות לפחות שבעה ימים מלאים, ויותר טוב ארבעה עשר.
התעלמות מ-statistical significance
שיפור של 5 אחוז ב-revenue על מקטע תנועה קטן עשוי להיות רק רעש סטטיסטי. לפני הכרזה על מנצח, ודאו שההבדל מובהק סטטיסטית — רוב פלטפורמות ה-mediation מספקות confidence intervals ו-p-value, או שתוכלו להשתמש בכלים סטטיסטיים סטנדרטיים כדי לוודא. אם רווח הסמך חוצה אפס, אין לכם באמת מנצח, גם אם הממוצע נראה טוב.
אוטומציה של התהליך
שותף monetization מנוהל יכול להריץ בדיקות waterfall רציפות בשמכם, באמצעות מערכות אוטומטיות שמפצלות תנועה, מודדות תוצאות ומקדמות קונפיגורציות מנצחות — הכל בלי שצוות ההנדסה שלכם יצטרך להקים ולנהל תשתית בדיקות. זה הופך את אופטימיזציית ה-waterfall מתהליך ידני מזדמן למנוע שיפור מתמשך.