آزمایش A/B در فروشگاه اینترنتی؛ راهنمای تصمیم‌گیری با داده
با این راهنما یک آزمایش فروشگاهی را از فرضیه تا سنجش نتیجه طراحی کنید؛ شامل انتخاب شاخص، حجم نمونه و خطاهای رایج.
وقتی فروش فروشگاه افت می‌کند، معمولاً چند راه‌حل به ذهن می‌رسد: عوض‌کردن رنگ دکمه، کوتاه‌کردن توضیحات، جابه‌جایی تصویر یا افزودن پیام اعتماد. مسئله این نیست که ایده‌ای کم داریم؛ مسئله این است که بدون سنجش معلوم نمی‌شود کدام تغییر واقعاً به تصمیم مشتری کمک کرده است.
آزمایش A/B روشی برای مقایسهٔ هم‌زمان دو نسخه از یک صفحه یا بخش آن است. بخشی از بازدیدکنندگان نسخهٔ فعلی را می‌بینند و بخشی نسخهٔ تغییریافته را؛ سپس نتیجه بر اساس هدفی که از قبل تعیین کرده‌اید سنجیده می‌شود. این روش زمانی مفید است که پرسش روشن، دادهٔ درست و زمان کافی داشته باشید. اگر بازدید فروشگاه کم باشد یا ثبت خرید قابل اعتماد نباشد، یک آزمون کوچک یا گفت‌وگو با مشتری ممکن است از اعلام زودهنگام «برنده» ارزشمندتر باشد.
در این راهنما می‌بینید چطور یک مسئلهٔ واقعی را به فرضیه تبدیل کنید، شاخص اصلی و معیارهای محافظ را انتخاب کنید، بازدیدکنندگان را منصفانه تقسیم کنید و نتیجه را بدون فریب‌دادن خودتان تفسیر کنید. روش‌ها برای فروشگاه‌های مستقل از پلتفرم کاربرد دارند.
آزمایش A/B چه چیزی را پاسخ می‌دهد؟
این آزمون به پرسشی محدود پاسخ می‌دهد: آیا نسخهٔ B در شرایط آزمایش، نسبت به نسخهٔ A نتیجهٔ بهتری برای هدف مشخص ما ایجاد می‌کند؟ برای مثال می‌توان بررسی کرد نمایش زمان ارسال کنار قیمت، نرخ افزودن به سبد را تغییر می‌دهد یا نه؛ یا اینکه عنوان روشن‌تر در صفحهٔ دسته‌بندی کلیک روی محصول مناسب را بیشتر می‌کند یا خیر.
آزمایش به‌تنهایی علت رفتار مشتری را کشف نمی‌کند. اگر نسخهٔ تازه بهتر عمل کرد، نتیجه می‌گوید در این جمعیت و این بازه، تفاوت مشاهده‌شده به نفع آن نسخه بوده است؛ اما توضیح نمی‌دهد چرا. برای فهم علت، دادهٔ قیف، گفت‌وگوی پشتیبانی، مشاهدهٔ نشست‌ها یا آزمون کاربردپذیری را هم بررسی کنید. پژوهش تجربهٔ کاربری می‌تواند چرایی رفتار را روشن کند؛ دادهٔ کمی بیشتر نشان می‌دهد چه رخ داده است. در راهنمای پژوهش تجربهٔ کاربری فروشگاهی این دو روش از هم تفکیک شده‌اند.
برای پیدا کردن مانع‌های واقعی، نظرهای خریداران و علت تردید آن‌ها را مرور کنید؛ راهنمای استفاده از نظرهای مشتریان می‌تواند به ساخت فرضیه‌های قابل بررسی کمک کند.
پیش از آزمون، از کجا شروع کنیم؟
۱. مسئله را از رفتار مشتری پیدا کنید
از ایده‌ای مثل «دکمه را سبز کنیم» شروع نکنید. ابتدا ببینید مشتری کجا مکث یا خروج دارد: بازدید صفحه زیاد و افزودن به سبد کم است؟ انتخاب روش ارسال طول می‌کشد؟ کاربران موبایل کمتر از دسکتاپ سفارش را کامل می‌کنند؟ دادهٔ قیف، جست‌وجوی داخلی، دلیل تماس‌ها و بازخورد مشتریان کمک می‌کنند مسئله را دقیق‌تر بنویسید.
برای یک صفحهٔ محصول، بررسی کنید آیا کاربر قیمت، موجودی، زمان تحویل و شرایط بازگشت را پیش از انتخاب می‌بیند. اگر شرح محصول هنوز پرسش‌های اصلی را بی‌جواب می‌گذارد، ابتدا آن را اصلاح کنید؛ راهنمای بهینه‌سازی صفحهٔ محصول می‌تواند فهرست بازبینی اولیه باشد.
۲. فرضیه را به شکل قابل آزمون بنویسید
یک فرضیهٔ اجرایی سه بخش دارد: مشکل مشاهده‌شده، تغییری که می‌خواهید انجام دهید و نتیجه‌ای که انتظار دارید. نمونه: «چون مشتری پیش از افزودن کالا به سبد از زمان تحویل مطمئن نیست، اگر بازهٔ ارسال کنار قیمت نمایش داده شود، سهم نشست‌هایی که به افزودن به سبد می‌رسند بیشتر می‌شود؛ بدون اینکه لغو سفارش یا تماس دربارهٔ ارسال افزایش پیدا کند.»
این جمله مشخص می‌کند چه چیزی تغییر می‌کند و چه چیزی تغییر موفقیت‌آمیز به حساب می‌آید. وعدهٔ نتیجهٔ قطعی ندهید؛ فرضیه باید قابل ردشدن هم باشد.
۳. یک متغیر یا یک بستهٔ هماهنگ انتخاب کنید
برای آزمون نخست، چند چیز نامرتبط را هم‌زمان عوض نکنید. اگر عنوان، تصویر، قیمت، چیدمان و دکمه را یک‌باره تغییر دهید و فروش بالا برود، نمی‌دانید کدام بخش مؤثر بوده است. یک تغییر مستقل، مثل نمایش هزینهٔ ارسال پیش از پرداخت، تفسیر ساده‌تری دارد. اگر هدف، مقایسهٔ دو طرح کامل است که اجزایشان با هم هماهنگ‌اند، نتیجه را به همان بسته نسبت دهید؛ از آن نتیجه نگیرید که هر جزء به‌تنهایی برنده بوده است.
مراحل طراحی یک آزمایش قابل اعتماد
۴. شاخص اصلی و معیارهای محافظ را از قبل ثبت کنید
یک شاخص اصلی برای تصمیم انتخاب کنید؛ مثلاً نرخ تبدیل همان صفحه یا سهم بازدیدکنندگانی که سفارش را کامل می‌کنند. برای جلوگیری از بهبود ظاهری و آسیب پنهان، چند معیار محافظ هم داشته باشید؛ مانند حاشیهٔ سود هر بازدیدکننده، نرخ لغو، مرجوعی، خطای پرداخت، زمان بارگذاری یا تماس‌های پشتیبانی.
اگر فقط کلیک روی دکمه را اندازه بگیرید، ممکن است کلیک‌ها بالا بروند اما سفارش کامل یا سود تغییری نکند. معیار باید به هدف کسب‌وکار و مرحله‌ای که تغییر در آن انجام می‌شود وصل باشد. در تغییر صفحهٔ پرداخت، نرخ تکمیل سفارش و شکست پرداخت مهم‌تر از تعداد مشاهدهٔ دکمه است؛ برای بررسی آن مسیر می‌توانید از راهنمای ساده‌سازی پرداخت کمک بگیرید.
۵. ابزار اندازه‌گیری را پیش از شروع اعتبارسنجی کنید
قبل از تقسیم ترافیک، یک سفارش آزمایشی را از ابتدا تا انتها ثبت کنید. مطمئن شوید رویداد خرید فقط یک‌بار ثبت می‌شود، مبلغ و شناسهٔ سفارش با سامانهٔ فروش هماهنگ‌اند و لغو یا مرجوعی با همان تعریف گزارش می‌شود. اگر سامانهٔ تحلیل در یکی از نسخه‌ها رویداد را جا بیندازد، مقایسه از همان ابتدا مخدوش است.
یک جدول ساده برای آزمایش بسازید: نام آزمون، مسئله، فرضیه، صفحه یا گروه صفحات، نسخهٔ A و B، زمان شروع، هدف اصلی، معیارهای محافظ، مسئول اجرا و تصمیم نهایی. این ثبت مانع می‌شود نتیجهٔ قبلی فراموش شود یا آزمایشی با همان فرضیه بی‌دلیل دوباره اجرا شود.
۶. بازدیدکنندگان را هم‌زمان و تصادفی تقسیم کنید
اگر همهٔ کاربران این هفته نسخهٔ A و همهٔ کاربران هفتهٔ بعد نسخهٔ B را ببینند، تفاوت روزهای هفته، تعطیلات، موجودی، تبلیغ یا تغییر قیمت می‌تواند به جای خود تغییر نتیجه را جابه‌جا کند. در روش A/B معمول، دو نسخه در یک زمان به نمونه‌های تصادفی نشان داده می‌شوند تا عوامل بیرونی کمتر بین گروه‌ها تفاوت داشته باشد. راهنمای رسمی گوگل آنالیتیکس نیز آزمون A/B را مقایسهٔ هم‌زمان دو یا چند نسخه با نمونه‌های تصادفی تعریف می‌کند.
تا حد امکان هر کاربر در مراجعه‌های بعدی همان نسخه را ببیند؛ وگرنه ممکن است مشتری ابتدا یک مسیر و بعد مسیر دیگری را تجربه کند. اگر ابزار آزمایش شناسهٔ پایدار و تخصیص تصادفی ارائه نمی‌کند، پیش از تفسیر نتیجه محدودیتش را بدانید.
۷. اندازهٔ نمونه و مدت آزمون را پیش از شروع تعیین کنید
مدت لازم برای نتیجهٔ قابل اتکا به نرخ پایهٔ تبدیل، مقدار تغییری که ارزش تجاری دارد، حجم ترافیک و پراکندگی رفتار بستگی دارد. پیش از شروع، نرخ پایه را از یک بازهٔ نماینده برآورد کنید و حداقل اثر مهم برای کسب‌وکار را تعیین کنید. سپس از ابزار یا محاسبه‌گر آماری معتبر برای تخمین نمونهٔ لازم استفاده کنید.
اگر ترافیک کم است، ممکن است آزمون به زمان طولانی نیاز داشته باشد. در آن شرایط نتیجهٔ «دادهٔ کافی نیست» از پیروزی ساختگی بهتر است. ایده را می‌توانید ابتدا با چند مصاحبه، بازبینی تجربهٔ کاربری یا یک اصلاح کم‌ریسک بررسی کنید؛ لازم نیست هر تصمیم کوچک را به آزمایش آماری گران تبدیل کنید.
۸. نتیجه را زودهنگام و مکرر دنبال نکنید
اگر هر روز آمار را بررسی کنید و به محض بهترشدن موقت نسخهٔ B آزمون را متوقف کنید، احتمال دارد نوسان طبیعی را با اثر واقعی اشتباه بگیرید. زمان پایان را قبل از شروع تعیین کنید و فقط زمانی زودتر متوقف شوید که خطای فنی، آسیب روشن به مشتری یا ریسک جدی دیده شود.
پس از رسیدن به نمونهٔ برنامه‌ریزی‌شده، آزمون را بی‌دلیل ماه‌ها باز نگذارید. گوگل توصیه می‌کند آزمایش فقط تا زمانی ادامه یابد که برای نتیجهٔ قابل اعتماد لازم است و بعد از پایان، عناصر آزمایش به‌موقع برداشته شوند.
۹. نتیجه را فقط در یک عدد کلی خلاصه نکنید
پس از پایان، نرخ اصلی را در هر نسخه با تعداد کاربران و سفارش‌های واقعی گزارش کنید. اندازهٔ اختلاف، عدم‌قطعیت آماری و معیارهای محافظ را کنار هم ببینید. اگر نتیجه در کل مثبت است اما نرخ لغو یا تماس پشتیبانی هم بدتر شده، تصمیم صرفاً از روی افزایش تبدیل مناسب نیست.
تحلیل بخش‌ها را تا حد ممکن از قبل تعریف کنید؛ مثلاً موبایل در برابر دسکتاپ یا مشتری تازه در برابر بازگشتی. اگر پس از دیدن نتیجه ده‌ها گروه بسازید و فقط بهترین را گزارش کنید، احتمال پیدا کردن یک تفاوت تصادفی بالا می‌رود. گروه کوچک را فقط وقتی تفسیر کنید که دادهٔ کافی و فرضیهٔ مستقلی برای آن داشته باشید.
۱۰. نتیجه را به تصمیم و یادگیری تبدیل کنید
پایان آزمون یکی از این سه تصمیم را می‌خواهد: نسخهٔ جدید با شواهد کافی پذیرفته شود؛ نسخهٔ فعلی حفظ شود؛ یا نتیجه نامشخص بماند و آزمون دیگری با طراحی بهتر لازم باشد. هر سه نتیجه قابل استفاده‌اند. اگر تغییر پذیرفته شد، آن را برای همه اعمال کنید، کد تخصیص آزمایش را بردارید و شاخص‌ها را پس از انتشار هم پایش کنید تا خطای فنی یا تغییر رفتار در مقیاس کامل را ببینید.
در دفتر آزمایش‌ها بنویسید چه فرضیه‌ای بررسی شد، چه نتیجه‌ای گرفتید و چه چیزی هنوز معلوم نیست. نتیجهٔ منفی هم ارزش دارد؛ مثلاً نشان می‌دهد مانع اصلی احتمالاً در جای دیگری از مسیر خرید است.
مثال فرضی: آیا نمایش زمان تحویل به خرید کمک می‌کند؟
فرض کنیم پشتیبانی فروشگاه بارها دربارهٔ زمان رسیدن کالا سؤال دریافت می‌کند. فرضیه این است که نمایش بازهٔ تحویل کنار قیمت، ابهام را پیش از افزودن به سبد کم می‌کند. نسخهٔ A صفحهٔ فعلی است و نسخهٔ B همان صفحه با بازهٔ ارسال روشن و قابل اصلاح برای شهر انتخاب‌شده.
شاخص اصلی، سفارش تکمیل‌شده به ازای نشست واجد شرایط صفحه است. معیارهای محافظ، لغو سفارش، مرجوعی ناشی از تأخیر، تماس دربارهٔ ارسال و سود مشارکتی هر نشست هستند. ابتدا رویدادها را آزمایش می‌کنید، تقسیم تصادفی را بررسی می‌کنید و نمونهٔ لازم را با نرخ پایه و اثر حداقلی موردنیاز برآورد می‌کنید. اگر نتیجه به اندازهٔ لازم روشن نباشد، آزمون پاسخ قطعی نداده است؛ نباید با انتخاب یک بازهٔ دلخواه یا یک گروه کوچک آن را موفق اعلام کرد.
چه زمانی A/B تست انتخاب مناسبی نیست؟
- ترافیک بسیار کم: تفاوت کوچک ممکن است با دادهٔ موجود قابل تشخیص نباشد. از مشاهدهٔ کاربردپذیری، بازخورد و اصلاح‌های مبتنی بر شواهد شروع کنید.
- اندازه‌گیری ناقص: تا وقتی سفارش و رویدادها درست ثبت نمی‌شوند، ابتدا ابزار را اصلاح کنید.
- مشکل واضح و پرخطر: اگر هزینهٔ پنهان، خطای پرداخت یا اطلاعات گمراه‌کننده پیدا کرده‌اید، برای رفع آن منتظر نتیجهٔ آزمایش نمانید.
- تغییر کم‌اثر: هزینهٔ طراحی و تحلیل ممکن است از ارزش احتمالی نتیجه بیشتر باشد. اولویت را به مانع‌های نزدیک‌تر به فروش و تجربهٔ مشتری بدهید.
نکته‌های سئو هنگام آزمایش صفحه
اگر نسخه‌ها نشانی‌های جدا دارند، آن‌ها را فقط برای آزمایش و به‌صورت موقت نگه دارید. گوگل توصیه می‌کند برای نشانی‌های جایگزین، نشانی اصلی را با پیوند canonical مشخص کنید؛ در آزمون‌های مبتنی بر تغییر مسیر، تغییر مسیر موقت ۳۰۲ مناسب‌تر از ۳۰۱ دائمی است. به خزندهٔ جست‌وجو نسخه‌ای متفاوت از کاربران نشان ندهید؛ پنهان‌سازی نسخه بر اساس هویت خزنده، تخلف از سیاست هرزنامه است.
به‌محض رسیدن به نتیجهٔ کافی، نسخهٔ منتخب را روی نشانی اصلی اعمال کنید و نشانی‌ها، برچسب‌ها و کدهای آزمایش را پاک کنید. جزئیات را در راهنمای رسمی گوگل دربارهٔ آزمایش وب‌سایت ببینید.
شاخص‌هایی که کنار نرخ تبدیل لازم‌اند
| شاخص | پرسش |
|---|---|
| نرخ تبدیل صفحه یا قیف | چه سهمی از بازدیدکنندگان اقدام موردنظر را کامل کردند؟ |
| درآمد یا حاشیهٔ مشارکت هر بازدیدکننده | تغییر ارزش اقتصادی هر نشست را بهتر کرد یا فقط کلیک را؟ |
| میانگین ارزش سفارش | تبدیل بیشتر با سبدهای کوچک‌تر همراه بود؟ |
| نرخ لغو و مرجوعی | آیا نسخهٔ تازه انتظار نادرستی ساخت؟ |
| سرعت و خطای صفحه | آیا کد آزمایش تجربهٔ فنی را بدتر کرد؟ |
| تماس‌های مرتبط با موضوع آزمون | آیا پرسش یا سردرگمی مشتری کمتر شد؟ |
اشتباه‌های رایج
- شروع از رنگ دکمه به‌جای مسئلهٔ مشتری.
- تغییر چند عامل نامرتبط و نسبت‌دادن نتیجه به یکی از آن‌ها.
- متوقف‌کردن آزمون پس از دیدن یک روز نتیجهٔ مثبت.
- استفاده از کلیک به‌عنوان تنها معیار موفقیت.
- نادیده‌گرفتن تفاوت ترافیک، موجودی، تخفیف و فصل.
- اعلام برنده در نمونهٔ کوچک یا پس از آزمودن گروه‌های متعدد.
- فراموش‌کردن پاک‌سازی کد و نسخه‌های آزمایشی بعد از پایان.
چک‌لیست پیش از راه‌اندازی
- یک رفتار مشتری و یک مانع مشخص را با داده یا بازخورد پیدا کرده‌ام.
- فرضیه می‌گوید چه تغییری چرا باید نتیجه را بهتر کند.
- شاخص اصلی و معیارهای محافظ از قبل مشخص‌اند.
- نسخه‌ها به‌طور هم‌زمان و تصادفی نمایش داده می‌شوند.
- رویداد ثبت سفارش و درآمد را با خرید آزمایشی کنترل کرده‌ام.
- حجم نمونه، اثر حداقلی مهم و زمان بررسی را پیش از شروع تعیین کرده‌ام.
- قاعدهٔ تصمیم پس از آزمون روشن است؛ از جمله احتمال نامشخص‌ماندن نتیجه.
- برای پایان، اعمال نسخهٔ منتخب و حذف عناصر آزمایش برنامه دارم.
پرسش‌های متداول
برای شروع چند نسخه لازم است؟
برای یک آزمون معمول، نسخهٔ فعلی و یک نسخهٔ تغییریافته کافی است. نسخه‌های بیشتر ترافیک را میان گروه‌های بیشتری تقسیم می‌کنند و تحلیل را دشوارتر می‌سازند.
آیا هر فروشگاه باید همیشه آزمایش A/B اجرا کند؟
خیر. آزمایش وقتی مناسب است که پرسش مهم، امکان تقسیم منصفانهٔ بازدیدکنندگان و دادهٔ کافی وجود داشته باشد. برای مسئلهٔ روشن و فوری، اصلاح مستقیم یا پژوهش کیفی ممکن است انتخاب بهتری باشد.
اگر نسخهٔ جدید برنده نشد، آزمون شکست خورده است؟
نه. ممکن است فرضیه رد شده یا داده برای نتیجه‌گیری کافی نبوده باشد. ثبت نتیجه کمک می‌کند همان ایده بدون دلیل دوباره تکرار نشود و مسئلهٔ بعدی دقیق‌تر انتخاب شود.
جمع‌بندی
آزمایش A/B ابزار تصمیم‌گیری است، نه تضمین افزایش فروش. ارزش آن زمانی شکل می‌گیرد که مسئله از رفتار واقعی مشتری آمده باشد، فرضیه قابل ردشدن باشد، نسخه‌ها منصفانه مقایسه شوند و نتیجه در کنار سود و تجربهٔ مشتری تفسیر شود.
با یک صفحه و یک تغییر مهم شروع کنید. اگر ترافیک یا داده کافی نیست، با مشاهده و گفت‌وگوی مشتری یاد بگیرید و بعد سراغ آزمون بروید. هر نتیجه را—مثبت، منفی یا نامشخص—ثبت کنید؛ به این ترتیب فروشگاه به‌جای تکرار حدس‌ها، از هر تغییر تصمیم دقیق‌تری می‌سازد.
برای مطالعهٔ بیشتر، به راهنمای رسمی گوگل آنالیتیکس دربارهٔ آزمون A/B و مقالهٔ پژوهش تجربهٔ کاربری فروشگاهی مراجعه کنید.
