حقایق و شنیده‌ها در مورد A/B Testing

سلام

اگه دستی توی UI/UX داشته باشید یا کار مارکتینگ کرده باشید و یا با تیم طراحی محصول تعامل داشته باشید، احتمالا اسم A/B Testing رو شنیدید. توی این مقاله قصد دارم یه کم دقیق‌تر از منظر یه دولوپر به قضیه نگاه کنم.

اول یه تعریف کلی از اِی‌بی تستینگ بکنم و بعد برم سراغ اصل ماجرا

اِی‌بی تستینگ یک جور آزمایشه که طی اون دو یا چند نسخه از یک سایت (یا اپ یا ...) تهیه میشه، معمولا این دو نسخه دقیقا شبیه همدیگه هستن و صرفا یک پارامتر توشون متفاوته (تست‌هایی هم داریم که چندین پارامتر متفاوت توشون دیده میشه، ولی توی این مقاله تعداد پارامترها موضوع کلیدی‌ای نیست.). ساده‌ترین حالت اجرای تست به این صورته که هر کدوم از این نسخه‌ها برای درصدی از کاربران نمایش داده‌میشه و اندازه‌گیری میشه که کاربران از کدوم نسخه راضی‌تر بودن، یا با کدومش تونستن راحت‌تر کار بکنن. برای توضیحات بیشتر ارجاعتون میدم به لینک زیر:

از اون‌جایی که این آزمایش خیلی برای تست ظاهر سایت و یا محتوای ایمیل‌مارکتینگ و موارد مشابه به کار می‌ره، عملا این تست بیشتر به درد آدم‌های غیر فنی می‌خوره، و به همین دلیل اگه سرچ بکنید A/B Testing اولین چیزهایی که می‌بینید سایت‌هایی شبیه Google Optimize هستن که به سادگی قابل استفاده هستند، کافیه یک کد جاوااسکریپت رو توی سایتتون قرار بدید و دیگه هیچ نیازی به کدنویسی نیست. با Visual Editorای که در اختیار شما قرار داده می‌شه، شما می‌تونید توی گوگل‌اپتیمایز، آزمایش‌های جدیدی ایجاد کنید و هر قسمتی از سایت که دوست دارید رو تغییر بدید (به سادگی درگ‌اند‌دراپ).

ولی به جرات می‌تونم بگم این یه حقه‌ی تبلیغاتی بیشتر نیست، چون این روش اصلا کارامد نیست :) چرا؟ علتش واضحه. فرایند لود شدن یک وبسایت که یک تست گوگل‌اپتیمایز روش قراره اجرا بشه رو در نظر بگیرید.

1. سایت لود میشه
2. اسکریپت‌ها و عکس‌ها و ... لود می‌شن
3. اطلاعات آزمایش در حال اجرا از گوگل گرفته می‌شه
4. تغییرات ظاهری روی صفحه اعمال میشه

خب مشکل چیه؟ مشکل اینه که تا قبل از اجرای مرحله‌ی ۴، کاربر سایت اصلی رو می‌بینه، و بعد از اون آزمایش اجرا می‌شه و کاربر نسخه‌ی تغییر یافته رو می‌بینه، و خب چی از این بدتر می‌تونه باشه توی تجربه‌ی یک کاربر؟

خب گوگل هم یه راه‌حل برای این مشکل داده که به این صورته:

یه اسکریپتی به اسم Anti Flicker رو روی سایت می‌ریزید، و کارش اینه که یک پرده‌ی سفید نشون کاربر میده تا مرحله‌ی ۴ تموم بشه. خب اینجوری کاربر تغییرات ناشی از اجرای آزمایش رو نمی‌بینه و این خوبه. ولی این موضوع به چه قیمتی داره اتقاق میفته؟ به قیمت دیرتر لود شدن صفحه برای کاربر و دیدن یک پرده‌ی سفید توی مدت لود شدن سایت (که اگه کاربر اینترنت کندی داشته باشه یا VPN استفاده بکنه این زمان می‌تونه قابل توجه باشه)

خب راه حل چیه؟ اگه یه کم دقیق‌تر درباره‌ی A/B Test تحقیق بکنیم می‌فهمیم که اینا همش حقه‌ی تبلیغاتی بوده و خود گوگل هم حاضر نیست از این روش خودش استفاده بکنه. گوگل بعضا برای اینکه تصمیم بگیره که مثلا برای جستجوی «بلیط هواپیما» کدوم یک از سایت‌های «مستربلیط» و «علی‌بابا» رو گزینه‌ی اول بیاره A/B Test اجرا می‌کنه، به این صورت که برای بعضیا مستربلیط رو اول میاره و برای بعضیا علی‌بابا رو. و نهایتا با اندازه‌گیری کلیک‌هایی که روی هر کدوم شده و پارامترهای دیگه‌ای مثل Bounce Rate متوجه می‌شه که کدومشون گزینه‌ی بهتری برای اول بودن توی نتایج هستند. ولی ما هیچ وقت یه پرده‌ی سفید قبل از لودشدن کامل گوگل نمی‌بینیم، و یا تغییر سمت کلاینت توی نتایج گوگل نمی‌بینیم.

راه حل مشکلاتی که گفتم چیزیه به اسم Serverside A/B Testing. به این صورت که سمت سرور تصمیم می‌گیریم که چه نسخه‌ای از سایت رو به کاربر نشون بدیم (اگه SPA داشته باشیم می‌تونیم این مورد رو توی لاجیک کلاینت پیاده‌سازی کنیم).

ولی می‌دونیم که گوگل‌اپتیمایز آمارهای خوبی بهمون می‌ده و با گوگل‌انالیتیکز هم اینتگریت شده، پس نمی‌خوایم از دستش بدیم، با کمی سرچ متوجه می‌شیم که گوگل‌اپتیمایز از Serverside Experiment هم پشتیبانی می‌کنه، ولی خب چون اونقدر جذاب نیست و درگ‌اند‌دراپ نداره، هیچ‌کس نمی‌شناستش.

با خوندن توضیحاتی که گوگل توی این لینک داده، می‌تونید اجرای آزمایش رو توی Backend خودتون انجام بدید (لایبرری‌های خوبی برای زبون‌های مختلف بکند وجود داره تو این زمینه) و نتایجش رو وصل کنید به گوگل‌اپتیمایز و توی گوگل‌آنالیتیکز آماری که نیاز دارید رو ببینید. به همین سادگی.

جمله‌ی آخر

سعی کنیم ساده گول تبلیغات - مخصوصا توی حوضه‌ی تکنولوژی - رو نخوریم. درسته تکنولوژی پیشرفت کرده، ولی هنوز همه‌ی کارها به بهترین نحو با محیط گرافیکی و درگ‌اند‌دراپ قابل اجرا نیستن :)