A/B Testing یک روش آزمایش کنترل‌شده برای مقایسه رفتار در نسخه‌های تعریف‌شده است. خود روش به جای طراح تصمیم نمی‌گیرد؛ تیم باید فرضیه، شاخص، جمعیت و قواعد تحلیل را مشخص کند. نمایش دو نسخه و دیدن چند کلیک، آزمایش قابل اعتماد نمی‌سازد. تفاوت می‌تواند از انتخاب نمونه، ثبت ناقص داده یا تغییر هم‌زمان شرایط بیاید. نتیجه زمانی برای تصمیم مفید است که قرارداد آزمایش و محدودیت آن همراه عدد گزارش شوند.
برای مثال فرضی، تیم می‌خواهد بداند توضیح روشن هزینه پیش از شروع فرم، تکمیل درخواست را تغییر می‌دهد یا نه. نسخه فعلی و نسخه دارای توضیح مقایسه می‌شوند. هدف فقط افزایش کلیک دکمه نیست؛ ممکن است کلیک بیشتر با درخواست نامناسب یا خطای بیشتر همراه شود. این مثال برنامه مطالعه آموزشی است و نتیجه یا درصد واقعی اعلام نمی‌کند. پیش از ساخت نسخه، مشخص کنید چه رفتاری بهتر محسوب می‌شود و چه آسیبی قابل قبول نیست.
فرضیه را با تصمیم و سازوکار بنویسید
«نسخه B بهتر است» فرضیه قابل توضیحی نیست. بنویسید چه تغییری، برای کدام مخاطب و از چه راهی باید بر رفتار اثر بگذارد. اگر تصور می‌کنید ابهام هزینه مانع ادامه است، مشاهده یا داده اولیه آن را ثبت کنید. A/B Testing می‌تواند اثر یک تغییر را مقایسه کند، اما علت ذهنی رفتار را کامل نشان نمی‌دهد. مقاله UX Research برای فهم زمینه و ساخت فرضیه مفید است و جای این دو روش یکسان نیست.
تغییر باید با تصمیم قابل اقدام ارتباط داشته باشد. اگر اختلاف دیده شد، تیم باید بداند چه چیزی را منتشر، اصلاح یا کنار بگذارد. آزمایش یک مجموعه تغییر می‌تواند برای تصمیم درباره همان مجموعه مناسب باشد؛ نتیجه به تنهایی اثر هر جزء را جدا نمی‌کند. قانون «همیشه فقط یک متغیر» بیش از حد ساده است. برای نسبت دادن اثر به چند عامل، طراحی مناسب و تحلیل مربوط لازم است و نباید از یک مقایسه دو نسخه‌ای نتیجه همه عامل‌ها استخراج شود.
تخصیص تصادفی و واحد آزمایش را تعریف کنید
واحد می‌تواند کاربر، حساب، دستگاه یا محدوده دیگری باشد و انتخاب آن روی استقلال مشاهده‌ها اثر دارد. تغییر تصادفی نسخه در هر Refresh ممکن است یک فرد را به هر دو تجربه ببرد و رفتار را مخلوط کند. نسبت تخصیص نیز باید از پیش مشخص باشد؛ ۵۰/۵۰ گزینه رایج است ولی الزام همه آزمایش‌ها نیست. خطر تغییر، حجم داده و طراحی تحلیل می‌توانند نسبت دیگری بخواهند. نسبت واقعی باید با همان انتظار مقایسه شود.
راهنمای پیش از آزمایش Microsoft Research به طراحی و اعتبار اجرای آزمایش توجه دارد. Client و Server باید درباره نسخه و ثبت رویداد هماهنگ باشند. اگر یک گروه به دلیل خطای فنی کمتر وارد گزارش می‌شود، عدد مقایسه می‌تواند منحرف شود. تخصیص صرفاً یک Boolean در UI نیست؛ باید زمان قرار گرفتن در گروه و زمان مواجهه با تغییر روشن باشند.
Metric اصلی و Guardrail را جدا کنید
Metric اصلی به تصمیم مربوط باشد و صورت و مخرج آن تعریف شوند. تکمیل درخواست ممکن است نسبت درخواست معتبر به مخاطب واجد شرایط باشد، نه تعداد Submit به تعداد همه بازدیدها. تعریف دقیق برای هر دو نسخه یکسان لازم است. اگر نسخه جدید افراد بیشتری را وارد مسیر می‌کند، فقط نگاه به افراد باقی‌مانده می‌تواند نتیجه متفاوتی بسازد. انتخاب جامعه تحلیل باید از پیش روشن شود تا پس از دیدن عدد مطلوب تغییر نکند.
Guardrail اثرهای نامطلوب را پیگیری می‌کند؛ مثل خطا، لغو، زمان انتظار یا شکایت. شاخص کلیک بالا به تنهایی موفقیت نیست اگر کاربر با اطلاعات نادرست وارد شده باشد. مقاله Landing Page درباره ارتباط اقدام و پیام کمک می‌کند. چند شاخص را به یک نتیجه نمایشی تبدیل نکنید. باید معلوم باشد کدام معیار تصمیم اصلی است و کدام نشانه برای محدودیت یا توقف استفاده می‌شود.
داده ثبت‌شده باید همان رفتار را اندازه بگیرد
رویداد باید در نقطه معتبر ثبت شود. کلیک روی دکمه با ثبت موفق Server یکسان نیست. ارسال تکراری، Retry و شکست شبکه می‌توانند تعداد را زیاد کنند. شناسه رویداد و روش حذف تکرار با معنی داده هماهنگ باشند. مقاله فرم وب درباره وضعیت ارسال توضیح دارد. اگر نسخه B فقط روش ثبت رویداد را تغییر داده باشد، اختلاف Metric ممکن است از اندازه‌گیری بیاید و نه از رفتار کاربر.
کیفیت داده را پیش از تفسیر اثر بررسی کنید. راهنمای آزمایش Microsoft Sample Ratio Mismatch را به عنوان نشانه اختلاف نامتناسب میان نسبت مورد انتظار و مشاهده‌شده توضیح می‌دهد. SRM صرفاً «گروه‌ها دقیقاً هم‌اندازه نیستند» نیست؛ باید با روش آماری مناسب بررسی شود. وجود مشکل داده را با تعداد بیشتر مشاهده حل‌شده فرض نکنید؛ علت تخصیص یا ثبت باید فهمیده شود.
حجم نمونه و زمان با اثر مورد نیاز مرتبط‌اند
تعداد ثابت برای همه آزمایش‌ها وجود ندارد. نرخ پایه، اثر حداقلی مورد توجه، عدم قطعیت و روش تحلیل در نیاز نمونه اثر دارند. اگر ترافیک کم است، شاید آزمایش نتواند تصمیم را در زمان معقول روشن کند. در این حالت تحقیق کیفی یا اصلاح یک مانع روشن می‌تواند مناسب‌تر باشد. عبارت «چند روز اجرا کنیم و برنده را ببینیم» بدون تعریف روش، حجم و چرخه استفاده کافی نیست و می‌تواند نتیجه تصادفی را بزرگ جلوه دهد.
چرخه‌های روزانه، روزهای کاری، کمپین و تغییر فصل می‌توانند رفتار را عوض کنند. توقف زود هنگام با اولین عدد مطلوب، در تحلیل‌های معمول ممکن است خطای تصمیم را بالا ببرد. تحلیل Sequential قواعد خودش را دارد و با نگاه روزانه به خروجی ثابت یکسان نیست. برنامه توقف و بررسی باید پیش از نتیجه مشخص باشد. همچنین اثر تازه بودن تجربه ممکن است با رفتار پایدار فرق کند؛ محدوده زمانی نتیجه را صریح بنویسید.
عدم قطعیت را با اثر عملی بخوانید
تفاوت کوچک می‌تواند از نظر آماری قابل تشخیص باشد و برای محصول ارزش کمی داشته باشد. تفاوت بزرگ ظاهری هم با داده محدود ممکن است نامطمئن باشد. اثر مطلق و نسبی را جدا توضیح دهید. در مثال صرفاً محاسباتی، تغییر نرخ از ده به یازده درصد، یک واحد درصد افزایش مطلق و ده درصد افزایش نسبی است. این عددها نتیجه آزمایش نیستند و فقط تفاوت دو نوع بیان را نشان می‌دهند؛ گزارش باید مانع برداشت بزرگ‌تر از داده شود.
p-value احتمال درست یا غلط بودن فرضیه به معنای ساده روزمره نیست و نباید به درصد قطعیت تبدیل شود. Interval و روش تحلیل باید با تفسیر درست ارائه شوند. برای گزارش به تیم، عدد اثر، عدم قطعیت و محدودیت مهم‌اند. راهنمای پس از آزمایش Microsoft Research درباره اعتماد به تحلیل و تفسیر نتیجه توضیح دارد. نتیجه نامطمئن را شکست طراحی یا اثبات نبود هر اثر معرفی نکنید.
چند مقایسه و Segment را کنترل کنید
اگر ده‌ها Metric، گروه و دوره را جست‌وجو کنید، احتمال پیدا شدن یک نتیجه ظاهراً جالب بیشتر می‌شود. تحلیل اکتشافی می‌تواند فرض تازه بسازد، اما باید از معیار تصمیم از پیش تعریف‌شده جدا باشد. گروه‌های کوچک ممکن است درصدهای متغیر داشته باشند. نتیجه موبایل و دسکتاپ یا تازه‌کار و کاربر قدیمی با حجم و روش مناسب بررسی شود. انتخاب فقط Segment مطلوب پس از نتیجه، گزارش را به تأیید سلیقه تیم نزدیک می‌کند.
اثر متقابل کاربران هم مهم است. در بازار دوطرفه یا ابزار همکاری، تجربه یک فرد می‌تواند بر دیگری اثر بگذارد و استقلال ساده کاربران فرض مناسبی نباشد. طراحی آزمایش باید همین رابطه را ببیند. نام A/B به تنهایی همه شرایط آماری را برقرار نمی‌کند. اگر دو نسخه اطلاعات یا قیمت حساس متفاوت ارائه می‌کنند، پیامد محصول و قواعد مرتبط باید پیش از اجرا بررسی شوند؛ آزمایش نباید بهانه نمایش گمراه‌کننده یا پنهان کردن شرایط واقعی باشد.
نتیجه را به تصمیم قابل بازبینی وصل کنید
گزارش باید فرضیه، تغییر، واحد تخصیص، Metric، زمان، حجم، کیفیت داده و اثر را کنار هم داشته باشد. سپس تصمیم را جدا بنویسید: انتشار، اصلاح، ادامه مطالعه یا حفظ نسخه فعلی. نتیجه مثبت با Guardrail آسیب‌دیده لزوماً انتخاب انتشار نیست. نبود تفاوت روشن هم ممکن است اجازه دهد نسخه ساده‌تر از نظر نگهداری انتخاب شود، به شرط اینکه همین دلیل ثبت شود. مقاله Design System برای انتقال تصمیم مشترک به Componentها مفید است.
شروع عملی یک سؤال مهم و یک قرارداد آزمایش است. پیش از ساخت نسخه، کیفیت ثبت، ظرفیت نمونه و راه توقف را روشن کنید. سپس نتیجه را با عدم قطعیت و محدوده واقعی بخوانید. A/B Testing وقتی به طراحی کمک می‌کند که اثر رفتار را با روش معتبر مقایسه کند؛ داده به خودی خود همه انتخاب‌های ارزشی، فنی و محتوایی را انجام نمی‌دهد و عدد مطلوب نباید جای استدلال قابل بررسی بنشیند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!