لماذا لا نجري اختبارات A/B

من المفترض أن يكون الاختبار المقارن (A/B) هو الطريقة المنطقية لاتخاذ القرارات المتعلقة بالمنتج: طرح نسختين مختلفتين، وقياس أيهما يحقق أداءً أفضل، والاحتفاظ بالنسخة الفائزة. يبدو الأمر وكأنه علم، لكنه غالبًا ما يكون غير ذلك.

المشاكل التي كنا نواجهها باستمرار

معظم اختبارات A/B على نطاقنا تتمتع بقوة إحصائية ضئيلة جدًّا بحيث لا يمكن اعتبارها ذات مغزى. الاختبارات التي هي تستمر هذه العمليات لفترة طويلة لدرجة أن شيئًا آخر في التطبيق أو في العالم يتغير في الخلفية، مما يؤدي إلى تشويه النتيجة. والمقياس الذي تقيسه لا يكون أبدًا المقياس الذي يهمك فعليًّا — فأنت تُحسّن الأداء من أجل النقرات لأن النقرات قابلة للعد، أما الأمور الأعمق التي كنت تريدها (الثقة، والاحتفاظ بالمستخدمين، والذوق) فتنجرف في اتجاه ما لم تقم بقياسه أبدًا.

ما نفعله بدلاً من ذلك

نقوم بتصميم خيارين، ونختار الخيار الأكثر صدقًا في وصف ماهية التطبيق، ونطلقه بثقة، ونصغي بعناية إلى ما ستخبرنا به التعليقات وطلبات الدعم خلال الأسابيع الستة المقبلة. نحن على استعداد لقبول أننا مخطئون أحيانًا مقابل ألا نضطر إلى أن نكون متأكدين إحصائيًا طوال الوقت.

إنه أبطأ من ناحية ما، وأسرع من جميع النواحي الأخرى.