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

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

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

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

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

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

מה זה A/B Testing

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

כל טסט בנוי משלושה שלבים:

1. הזדמנות - אנחנו מוצאים נקודה שמפריעה למשתמשים.
2. היפותזה - אנחנו מעלים השערה איך אפשר לפתור את אותה נקודה.
3. טסט - אנחנו מנסים את ההיפותזה שלנו במציאות.

נפרט על כל שלב:

• ההזדמנות

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

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

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

בסדרת יסודות Performance Marketing תוכלו ללמוד על ה-Funnel ולקבל כלים שימושיים לשיווק דיגיטלי.

• היפותזה

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

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

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

• מגדירים טסט

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

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

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

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

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

אתגרים בבניית טסטים

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

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

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

A/A Testing -אחד האתגרים הגדולים שיש לנו כשאנחנו מבצעים טסטים, היא לבדוק האם קבוצות שונות של משתמשים מתנהגות אחרת, גם בלי קשר לטסט שביצענו. כשאנחנו מבצעים טסט, אנחנו רוצים לדעת בוודאות שהשינוי שראינו במדדים הגיע מהשינוי שאנחנו עשינו, ולא מסיבות חיצוניות.

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

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

לסיכום

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

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

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