מסגרת בדיקות A/B חסינת לקוחות: 7 שלבים שעובדים על כל חשבון

סיכום

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

יום שני, 9:47 בבוקר. לקוח שולח אימייל ומבקש "בדיקת A/B מהירה" לעמוד התמחור שלו. יש לך שלושה חשבונות נוספים בתהליך, כל אחד עם מערך אנליטיקס שונה, שרשרת אישורים שונה והגדרה שונה של "ניצחון". הבדיקה המהירה תצטרך שלושה שבועות כדי להגיע למובהקות סטטיסטית. אתה כבר יודע את זה. אז אתה מאריך את לוח הזמנים, מציב ציפיות ומריץ את הבדיקה. ואז אתה מבלה חצי שבוע בהגנה עליה.

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

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

בדיקת A/B, כפי שהיא מוגדרת במילון המונחים של Optimizely, מפצלת את הקהל שלך באופן אקראי ומציגה לכל קבוצה גרסה שונה של עמוד. הפיצול האקראי הזה מייצר נתונים. אבל הנתונים אומרים משהו רק אם אתה יודע מה אתה מודד. רוב הלקוחות אומרים שהם רוצים "יותר המרות" — אבל המרות יכולות להיות הרשמות, רכישות, בקשות הדגמה, או אפילו גלילה עד התחתית. אם אתה לא קובע מדד אחד, כל תוצאה שתחזיר תהיה פתוחה לפרשנות מחודשת.

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

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

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

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

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

2. חפש חיכוך, לא העדפות

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

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

מקורות חיכוך נפוצים לבדיקה:

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

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

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

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

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

3. כתוב השערה שמנבאת למה, לא מה

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

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

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

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

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

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

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

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

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

4. תמחר את הבדיקה לפי לוח השנה של הלקוח, לא לפי ספר הסטטיסטיקה שלך

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

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

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

דוגמה מעשית: עמוד ההרשמה לניסיון של לקוח SaaS מקבל זרם מבקרים מתון אך קבוע. אתה רוצה לזהות שיפור משמעותי, והערכת גודל המדגם אומרת שהבדיקה תצטרך הרבה יותר מבקרים מאשר התנועה של הלקוח תספק בזמן הפנוי. הלקוח צריך תשובה תוך שישה שבועות לישיבת הדירקטוריון. אז אתה מרחיב את הפיצול מ-50/50 ל-90/10 — אבל זה עדיין לא יספיק. במקום זאת, אתה מוריד את האפקט המינימלי שניתן לזיהוי כדי לתפוס רק ניצחונות גדולים. עכשיו הבדיקה אפשרית במסגרת הזמן, ואמרת ללקוח בדיוק מה הבדיקה יכולה ומה היא לא יכולה לתפוס. זה המהלך המקצועי.

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

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

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

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

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

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

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

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

6. קרא את התוצאה כסיפור, לא כפסיקה

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

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

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

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

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

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

7. הפוך כל תוצאה לכלל שניתן לחזרה

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

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

רשימת בדיקה לערך בספר משחק:

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

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

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

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