A/B Testing

מה זה A/B Testing?

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

מה מיוחד ב-A/B Testing?

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

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

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

איך עושים את זה נכון? מדריך השלבים ל- A/B Testing

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

1. הגדרת יעדים – נבחן את הפרויקט שלנו באמצעות שיעורי ההמרה (ולא מתוך אינטואיציה), מתוך זה ננסה להבין מה לא עובד לנו טוב ונגדיר את אזור המחקר שאותו אנו רוצים לשפר.
2. אסיפת נתונים – התבוננות בהתנהגות המשתמש לצורך איסוף נתונים שיעזרו לנו להחליט איזה אזור צריך שיפור. 
3. יצירת השערה – לאחר הגדרת היעדים ואסיפת נתונים מהמשתמש, נוכל להתחיל להעלות השערות או רעיונות שלדעתנו יכולים לשפר את הגרסה הנוכחית. זה יכול בהחלט להיעשות בסיעור מוחות עם כל הצוות יחד. ברגע שיש לנו רשימת רעיונות, נתעדף אותם במונחים של ההשפעה הצפויה והקושי ליישום, נבחר את ההשערה המובילה ונבדוק אותה מול הפתרון הנוכחי.
4. יצירת וריאציה – יצירת וריאציה של העיצוב השונה. זה יכול להיות שינוי צבע כפתור, שינוי הטקסט, החלפת סדר האלמנטים בדף, הסתרת אלמנטים ניווטיים, או כל דבר אחר מותאם אישית.
5. הפעלת הבדיקה – נתחיל את הבדיקה על ידי גיוס קבוצת משתמשים הזהה לאופי המשתמש שלנו. נחלק את קבוצת המשתמשים הזו באופן אקראי לשתי קבוצות המקבלות כל אחת גרסה שונה.
6. ניתוח התוצאה – לאחר הבדיקה ניתן לראות את ההבדל בין הביצועים של שתי הגרסאות. גם כאשר הנתונים מראים שלא נעשה שיפור משמעותי, עדיין ניתן לציין בבטחון ובבהירות מה עובד ומה לא.
7. יישום הגירסה – אם הבדיקה הצליחה, כל שנותר הוא לקבל החלטה האם להתעדכן בגרסה החדשה או להיצמד לגרסה המקורית.

A/B Testing לפני פיתוח

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

כלים לניתוח התוצאות

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

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

החלטה מבוססת נתונים

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