تست A/B ، معجزه‌ای که باید اتفاق بیافتد!
مایکروسافت و دیگر شرکت‌های پیشرو (از جمله آمازون، فیسبوک و گوگل) هر ساله بیش از ۱۰ هزار آزمایش کنترل شده‌ی آنلاین از نوع تست A/B انجام می‌دهند و در این آزمایش‌ها میلیون ها کاربر را درگیر می‌کنند. بدون این آزمایش‌ها ممکن است بسیاری از پیشرفت‌ها هرگز اتفاق نیفتند، یا بسیاری از ایده‌های بد باعث اتلاف منابع شوند.
به طور مثال تیم تجزیه و تحلیل و آزمایش مایکروسافت بیش از ۸۰ نفر نیروی متخصص دارد که روزانه بر صدها آزمایش کنترل شده آنلاین روی محصولات مختلف تمرکز دارند. هر آزمایش صدها هزار کاربر و گاهی حتی ده‌ها میلیون کاربر را در معرض ویژگی یا تغییر جدید قرار می‌دهد.
قطعا نمی‌توان حجم نیرو و توانایی این ابرکمپانی‌ها را با استودیوهای بازی‌سازی کوچک، یا حتی کمپانی‌های بزرگ صنعت بازی مقایسه کرد؛ اما می‌توان با توجه به این تجربیات و الگو قرار دادن این کمپانی‌ها، کارهای مشابهی را در مقیاس کوچک‌تر انجام داد.
در این مقاله راجع به ساده‌ترین نوع آزمایش کنترل شده، یعنی آزمایش A / B با شما صحبت خواهیم کرد که حتی تیم‌های مستقل کوچک هم از پس انجامش برمی‌آیند.
در این مقاله شما را با بایدها و نبایدهای تست A / B به صورت کلی آشنا می‌کنیم و در مقاله‌ی بعدی قدم‌های پیاده‌سازی این نوع تست را مرحله به مرحله بررسی خواهیم کرد.
تست A/B چیست؟
در آزمایش A/B، آزمایشگر دو تجربه را طراحی می‌کند:
– تجربه‌ی اول یا “A”، «کنترل» نامیده می‌شود. کنترل، معمولاً سیستم فعلی است و بدون تغییر به گروه اول کاربران ارائه می‌شود. این گروه به “گروه قهرمان” معروف هستند.
– تجربه‌ی دوم یا “B”، که «درمان» (Treatment) در نظر گرفته می‌شود، اصلاحاتی هستند که سعی در بهبود چیزی دارند. گروه دوم از کاربران که این اصلاحات را تجربه می‌کنند، به “گروه چالشگر” معروف هستند.
اصلاحات می‌توانند هر نوع تغییری باشند؛ مثل:
– یک فیچر جدید: اصولا باید هر فیچر جدیدی را قبل از اینکه به تمام کاربران ارائه دهید، با یک آزمایش کنترل‌شده بر روی گروه محدودی از کاربران تست کنید و تاثیرش را اندازه‌گیری نمایید.
– تغییر در رابط کاربری: خیلی وقت‌ها تغییر کوچکی که در رابط کاربری می‌دهید، منجر به تغییرات بزرگی در رفتار کاربران می‌شود.
– تغییر در پشت صحنه: منظور تغییراتی غیر ظاهری است که بر روی رفتار کاربران در بازی، تاثیر مستقیم می‌گذارد؛ مانند بهبودی که در یک الگوریتم در طراحی بازی می‌دهید.
– یک مدل درآمدزایی متفاوت: می‌توانید با کمترین ریسک و هزینه، مدل‌های درآمدزایی مختلف را بر روی گروه‌های کوچک کاربران امتحان کنید.
روند تست به این صورت است که کاربران را به طور تصادفی به این گروه‌ها با تجربه‌های متفاوت اختصاص می‌دهید، متریک‌های اصلی آن‌ها را محاسبه می‌کنید و در نهایت با یکدیگر مقایسه می‌کنید. سپس نتایج را تحلیل کرده و تغییرات گروه برنده را بر روی تمام کاربران‌تان اعمال می‌کنید.
اما تست A/B لزوما تنها با دو تجربه اجرا نمی‌شود.
آزمون‌های کنترل شده را می‌توانید به صورت‌های زیر نیز طراحی و اجرا کنید:
– یک متغیره اما با بیش از یک درمان (حالت‌های بیشتر A / B / C / …)
– چند متغیره که اصلاح متغیرهای مختلف را به طور همزمان ارزیابی می‌کند (از هر متغیر دو یا چند حالت درمان وجود داشته باشد)
باید توجه کنید که برای هر نوع تستی که طراحی می‌شود، باید حتما یک گروه کنترل در نظر بگیرید. اگر یک تست، گروه کنترل نداشته باشد، ممکن است به این نتیجه برسید که تغییری که اعمال کرده‌اید تأثیر زیادی داشته است و متوجه نشوید که افزایش متریک‌ها به دلیل متغیرهای دیگری است که دور از چشم شما در دوره‌ی مشاهده‌ی تست تغییر کرده‌اند.
همچنین گنجاندن متغیرهای زیاد در آزمون‌ها نیز، یادگیری شما را درباره‌ی علیت دشوار می‌کند. با چنین آزمایشات پر متغیری، تفکیک نتایج و تفسیر آن‌ها دشوار می‌شود. در حالت ایده‌‌آل، یک آزمایش باید به اندازه‌ی کافی ساده باشد تا روابط علت و معلولی به راحتی درک شوند.
نکته منفی دیگر در طراحی‌های پیچیده‌ی تست‌ها این است که متغیرها و حالت‌های زیاد، آزمایشات شما را در برابر اشکالات فنی بسیار آسیب‌پذیرتر می‌کنند.
استفاده‌ی درست از تستهای کنترل‌شده، به استودیوها و تیم‌های بازی‌سازی فرصتی ارزشمند برای ارزیابی سریع بسیاری از ایده ها، با دقت زیاد و در عین حال هزینه ناچیز می‌دهد. چنین توانایی‌ای می‌تواند یک مزیت مهم رقابتی باشد، مشروط بر اینکه بدانید چگونه از آن استفاده کنید.
ایده های کوچک را دست کم نگیرید!
معمولاً آدم‌ها تصور می‌کنند که هرچقدر سرمایه‌گذاری بیشتری انجام بدهند، تأثیر بیشتری نیز خواهند دید. اما این طرز فکر در دنیای کسب‌وکارهای آنلاین به ندرت صحیح است. در این‌جا موفقیت بیشتر، به دست آوردن تغییرات کوچک و درست است.
بله، اگرچه همه، ایده‌های بزرگ را تحسین می‌کنند، اما به یاد داشته باشید که در واقعیت، بیشترین پیشرفت با اجرای صدها یا هزاران پیشرفت جزئی بدست می‌آید.
به طور مثال؛ برای بهبود تجربه‌ی کاربری در یک پروژه و رسیدن به تاثیرات بزرگ روی متریک‌ها، همه به دنبال تغییرات بزرگ و هزینه‌بر هستند. اما گاهی یک تغییر خیلی کوچک مثل تغییر رنگ یک نوشته یا تغییر جای یک دکمه، می‌تواند تاثیر چشمگیری روی رفتار کاربران و در نتیجه پیشرفت پروژه بگذارد.
همان‌طور که سرمایه‌گذاری‌های بزرگ ممکن است بازدهی کم و ناچیزی داشته باشند، سرمایه‌گذاری‌های کوچک نیز می‌توانند بازده بزرگی را به همراه بیاورند.
قبل از پیاده سازی، آزمایش کنید
اکثر تیم‌ها بر این باورند که باید ایده‌هایی را که به نظرشان خوب و تاثیرگذار است، به سرعت بر روی پروژه‌شان پیاده کنند. البته که سرعت عمل همیشه مفید است، اما به چه قیمتی؟ آیا هزینه‌ای که صرف اجرای یک ایده می‌شود، می‌تواند به همان مقدار متریک‌های پروژه را بهبود ببخشد؟ آیا باید چند نفر یا حتی چند تیم روزها یا حتی ماه‌ها بر روی پیاده‌سازی این ایده کار کنند؟
برای پاسخ به این سوالات بهتر است یک مثال جالب بزنیم:
ممکن است کمپانی شما یا تیم کوچک مستقل شما به این نتیجه برسد که برای پیشرفت پروژه‌تان، لازم است تیم فنی به دنبال راهکاری برای کمتر کردن زمان اجرای یک فیچر بگردد. مثل کمتر کردن زمان انتظار کاربر برای Map Loading در بازی، یا کاهش زمانی که MatchMaking در هر دست بازی طول می‌کشد.
شرکت مایکروسافت نیز زمانی با این مساله روبه‌رو شد که به دنبال کاهش زمان لازم برای نمایش نتایج جستجو در موتور جستجوی بینگ بود. احتمالا متوجه هستید که حتی کاهش یک میلی ثانیه برای جستجو، نیازمند کار زمانبر چندین تیم خواهد بود! پس سوالات بالا یکی یکی به سراغشان آمد. آیا در حال حاضر ارزشش را دارد؟
رویکرد مایکروسافت در مواجهه با این مساله فوق‌العاده بود. این شرکت تصمیم گرفت یک سری آزمایشات و تست A/B را انجام بدهد که در آن به جای کم کردن زمان نمایش نتایج، با ایجاد تاخیرهای مصنوعی زیاد شدن زمان نمایش نتایج را تست کند. داده‌های حاصل از این تست نشان داد كه هر اختلاف 100 ميلی‌ثانيه‌ای، در درآمد کل ۰.۶ درصد تاثير دارد. شاید ۰.۶ درصد برای شما عدد کوچکی به نظر برسد اما با درآمد سالانه‌ی بینگ در آن زمان که بیش از 3 میلیارد دلار بود، 100 میلی ثانیه سرعت بخشیدن به نمایش نتایج توانست 18 میلیون دلار افزایش درآمد سالانه برایشان به بار بیاورد!
حال بیایید روی دیگر سکه را ببینیم! اگر مایکروسافت پس از انجام این آزمایش ساده اما هوشمندانه، با تحلیل و محاسبه‌ی سودش متوجه می‌شد که در شرایط فعلی‌اش کم کردن زمان نمایش نتایج تاثیر چشمگیری روی درآمد پروژه نخواهد گذاشت، می‌توانست بدون صرف هیچ هزینه‌ی اضافی‌ای، جلوی این تصمیم اشتباه را بگیرد.
نتیجه‌گیری، ساده نیست!
نتیجه‌گیری همیشه سخت‌ترین قسمت فرایند تست A / B است! مهم نیست که ایده‌ی خوبی پیدا کرده‌اید، یا تست را به صورت درست پیاده‌سازی کرده‌اید، تا زمانی که نتوانید نتایج قابل اعتمادی از آزمایش‌تان بگیرید، هیچ‌چیز ندارید! گرفتن اعداد و آمار آسان است؛ قسمت سخت داستان، تحلیل، ریشه‌یابی و اعتماد به این اعداد است! حتما باید برای صحت‌سنجی سیستم آزمایش‌تان زمان و کار جدی اختصاص دهید.
یک روش مفید برای اطمینان حاصل کردن از نتایج یک گروه از تست، اجرای تستهای دقیق A / A است:
تست A / A همانند تست A/B اجرا می‌شود ولی برای تست کردن یک گروه علیه خود است. اگر حدود ۹۵ درصد از مواقع سیستم به یقین هیچ تفاوت آماری معنی‌داری را نشان ندهد، می‌توانید اطمینان حاصل کنید که تغییراتی که مشاهده کرده بودید اتفاقی یا تحت تاثیر عامل دیگری نبوده است. این رویکرد ساده به آزمایشگرها کمک می‌کند تا آزمایش‌های با شرایط نامعتبر یا کاربردهای نادرست فرمول‌ها را به راحتی شناسایی کنند.
برای تحلیل نتایج تست‌ها ممکن است نیاز داشته باشید کاربرهای با رفتارهای غیرطبیعی را از گروه‌ها خارج کنید (مثل Whales یا نهنگ‌ها که خریدهای بیشتر از حد نرمال در بازی انجام می‌دهند).
همچنین تا جای ممکن، خطاهای مجموعه (از پیاده‌سازی تست گرفته تا جمع‌آوری داده‌ها) را در آغاز تست بررسی کنید تا به سریع‌ترین حالت ممکن رفع‌شان کنید.
به یاد داشته باشید:
- تستهای A/B همیشه موفق نیستند و حتی بهترین متخصصان هم خیلی وقت‌ها در تحلیل و انتخاب‌شان شکست می‌خورند.
در همین ابرکمپانی‌هایی که مثال‌های موفق‌شان را در این مقاله آوردیم، تنها حدود ۱۰ الی ۲۰ درصد از آزمایش‌هایشان نتایج مثبتی ایجاد می‌کند.
وقتی وارد بازی تستهای کنترل شده می‌شوید، لازم است بدانید نهایتا یک سوم از آزمایش‌هایتان قرار است اثربخش باشد، یک سوم نتایج خنثی خواهد داشت و از یک سوم دیگر نتایج منفی خواهید گرفت.
همه‌ی این‌ها نشان می‌دهد که شرکت‌ها و تیم‌های بازی‌ساز باید برای پیدا کردن یک شاهزاده، قورباغه‌های زیادی را ببوسند!
- حواستان به دستاوردهای کوتاه‌مدت باشد.
خیلی وقت‌ها نتایج تست در کوتاه مدت تاثیر مثبتی را نشان می‌دهند، اما ممکن است در دراز مدت روی پیشرفت پروژه‌تان تاثیر منفی بگذارند.
مثلا با یک تست روی درآمدزایی بازی‌تان، در کوتاه مدت سود قابل توجهی مشاهده می‌کنید و تصمیم می‌گیرید تغییرتان را روی تمام کاربران پیاده کنید؛ اما اگر کمی صبر کنید و متریک‌های بلند مدت‌تان را بررسی کنید، ممکن است نتایج ناخوشایندی از جنس پایین آمدن نرخ بازگشت و از دست دادن کاربران مشاهده کنید.
- گاهی اوقات برای انتخاب گروه‌های برنده در تست لازم نیست حتما ”چرا و چگونه” ی رفتار کاربران را درک کنید؛ زیرا گاهی تشخیص انگیزه‌های کاربران بسیار دشوار است. همین که مطمین شوید کاربران‌تان چه چیزی را انتخاب کرده‌اند، کافی‌ست.
در نهایت به یاد داشته باشید تستهای کنترل شده می‌توانند زمانی که جواب‌ها برایمان آشکار نیستند، ما را در جهت صحیح راهنمایی کنند. خصوصا زمانی که افراد در یک تیم عقاید متناقضی دارند و یا از ارزش ایده‌های‌شان مطمئن نیستند، این تست‌ها به کمک می‌آیند.
اگر واقعاً می خواهید ارزش یک آزمایش را درک کنید، تفاوت بین نتیجه‌ی مورد انتظار و نتیجه‌ی واقعی آن را بررسی کنید.
اگر فکر می‌کردید چیزی قرار است اتفاق بیافتد و اتفاق افتاد، پس چیز زیادی یاد نگرفته‌اید. اگر فکر می‌کردید اتفاق میافتد اما نیافتاد، پس چیز مهمی را آموخته‌اید. و اگر فکر می‌کردید یک تغییر جزئی اتفاق میافتد و نتایج حیرت‌آوری مشاهده کردید که منجر به دستیابی به موفقیت شد، برنده شده‌اید!
مقالات مرتبط:
از آنالیتیکز بازی موبایلمان چه بخواهیم؟
مونا مقدم، گیم آنالیست و متخصص هک رشد