كيف تتوقف عن القلق وتبدأ في الإيمان باختبارات أ / ب

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

نحن في Badoo لا نثق بالمشاعر ، لكننا نؤمن بالأرقام. في المجموع ، تضم خدماتنا أكثر من 500 مليون مستخدم ، وكتبنا إطار عمل الاختبار لفترة طويلة. خلال ست سنوات ، اجتاز 2962 اختبارًا ، وأثبت اختبار A / B أهميته وموثوقيته وفعاليته.



ولكن في هذه المقالة لن أتحدث عن كيفية عمل نظامنا. مقال واحد لا يكفي لهذا. بالإضافة إلى ذلك ، هناك العديد من الأشياء التي تخص شركتنا ولن تناسب الآخرين. اليوم سأتحدث عن تطور أفكارنا حول اختبارات أ / ب: أي نوع من أشعل النار التي خطوناها في العملية وكيف تحققنا من صحة الاختبارات. هذه المقالة مخصصة لأولئك الذين لم يبدأوا الاختبار بعد ، ولكن فكروا في الأمر ، وكذلك لأولئك الذين ليسوا متأكدين من نظام الاختبار الخاص بهم.

ما هو اختبار أ / ب؟


تخيل موقفًا: سيتم إطلاق ميزة جديدة ، ومدير المنتج لدينا ليس مستعدًا للمخاطرة بدخل صغير ولكنه مستقر للمنتج. بعد بعض المداولات ، يقترح إطلاق الميزة من خلال اختبار A / B ومعرفة ما إذا كانت ستقلع ولن يذهب المستخدمون إلى المنافسين. 

لم نجري اختبارات A / B من قبل ، لذا فإن أول ما نتعلمه هو ما هي عليه. تقول ويكيبيديا: "اختبار A / B هو طريقة بحث تسويقية ، وجوهرها هو أن مجموعة عناصر التحكم تتم مقارنتها بمجموعة من مجموعات الاختبار التي تم فيها تغيير مؤشر واحد أو أكثر من أجل معرفة أي تغيير هدف تحسين". اتضح أننا بحاجة إلى إجراء دراسة يجب أن تكون فيها مجموعة تحكم ومجموعة اختبار واحدة على الأقل ومؤشر هدف.

بالنسبة للمجموعة التجريبية ، سنعرض نسخة بديلة من صفحة الدفع. عليه ، نريد تغيير النص ، وتسليط الضوء على الخصم ، واستبدال الصورة - وكل هذا للمستخدمين من أوراسيا ، حتى يشتروا المزيد. وبالنسبة للمستخدمين من أمريكا ، لا نريد تغيير أي شيء. 

سيكون لدينا أهداف. لنأخذ الأساسيات:

  • ARPU (متوسط ​​الإيرادات لكل مستخدم) - الربح الذي سنحصل عليه في المتوسط ​​من المستخدم ؛ 
  • عدد النقرات على عناصر CTA (عبارة تحث المستخدم على اتخاذ إجراء) - الأزرار والروابط في صفحة الدفع. 

مهمة فنية


من المخطط تغيير ثلاثة عناصر في الصفحة في نفس الوقت: النص والزر والصورة بمعلومات الخصم.



سيكون من الصعب جدًا فهم أي من هذه التغييرات أثرت على النتيجة إذا تم اختبارها في وقت واحد. ربما يقوم النص الجديد بصد المستخدمين ويؤدي إلى انخفاض في عدد عمليات الشراء ، ولكن إبراز الخصم سيزيده: ونتيجة لذلك ، نحصل على صفر. سيتم إهدار موارد التنمية وسيتم رفض فرضية العمل. 

لذلك ، لن نقوم بذلك. سنترك تغييرًا واحدًا فقط للاختبار - تخصيص الخصومات. 


الاختبار الأول


الخطة هي: نقسم المستخدمين إلى مجموعتين متساويتين وننتظر النتيجة. عندما نتلقى ذلك ، سنقوم بمقارنة المؤشرات في مجموعات التحكم والاختبار. 

كل شيء يبدو بسيطًا جدًا: نقسم المستخدمين إلى أزواج وغريب ثم ننظر إلى الإحصائيات. 

نكتب الرمز:

if (userId % 2 == 1) {
    showNewAwesomeFeature();
}

نتطلع إلى أسبوعين: النتائج مذهلة! زيادة متوسط ​​العائد لكل مستخدم بنسبة 100٪! ينقر الأشخاص ، ويدفعون ، ويطلب مدير المنتج طرح التغيير بسرعة على الإطلاق. 



نشغلها ، يمر أسبوعان آخران ، ولكن لا توجد نتائج. لم يزد إجمالي الربح. 

ما الذي نفعله بشكل خاطئ؟

نختار مجموعة اختبار


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

الخلاصة: حدد دائمًا في مجموعة الاختبار فقط المستخدمين الذين تم تنفيذ التغييرات من أجلهم.

لنصلح رمزنا:

if (user.continent === ‘eurasia’ && userId % 2 == 1) {
    showNewAwesomeFeature();
}

الآن يجب أن يعمل كل شيء كما يجب! قم بإجراء الاختبار. نحن ننتظر لبضعة أسابيع.



حدث! ARPU بنسبة 80٪! اطرح التغيير لجميع المستخدمين. 

و ... بعد نفس الفترة الزمنية ، لا تبدو الرسوم البيانية مرة أخرى بالطريقة التي خططنا لها.

حساب الدلالة الإحصائية


لا يمكن إيقاف الاختبار ببساطة "بعد أسبوعين": قد تكون النتائج التي تم الحصول عليها غير دقيقة. كلما قل المقياس الذي نتبعه ، وكلما قل عدد الأشخاص المشاركين في الاختبار ، زادت احتمالية أن يكون عشوائيًا.  

يمكن حساب هذا الاحتمال. القيمة التي تدل عليها تدعى القيمة p. سأخبرك كيف يعمل.

عند إجراء أي اختبار ، هناك فرصة للحصول على نتائج عشوائية. على سبيل المثال ، قد يتم توزيع المستخدمين الذين زاروا الموقع بشكل غير متساوٍ - وسيقع الجمهور المدفوع بالكامل في إحدى المجموعات. في الاختبارات الحقيقية ، لا يكون الفرق في المقاييس كبيرًا جدًا: من الصعب أو حتى المستحيل ملاحظة مشكلة في الرسوم البيانية ، ولا يمكن الاستغناء عن الاختبارات الإحصائية. على وجه الخصوص ، نحن بحاجة إلى إصلاح الاحتمالأخطاء من النوع الأول والثاني - وبعبارة أخرى ، احتمال العثور على تغييرات في حالة عدم وجودها ، وعلى العكس من ذلك ، عدم العثور عليها إذا كانت موجودة. بناءً على قيمة المقياس والاحتمالات المحددة ، نحتاج إلى عدد مختلف من المستخدمين.

يمكنك حسابها باستخدام الآلة الحاسبة عبر الإنترنت : حدد القيم الحالية والمستهدفة للمقاييس المراقبة - تحصل على العدد المطلوب من المستخدمين للاختبار ، والعكس صحيح.


حساب التحويل بنسبة 10٪ والتغييرات بنسبة 0.2٪ بالنسبة للقيمة الحالية.

لقد تلقينا الآن جميع البيانات اللازمة ونفهم متى نوقف الاختبار. لا يوجد المزيد من العقبات.

دعونا نجري اختبار أ / ب ونلقي نظرة على النتائج.



هذه المرة ، تكون النتائج أشبه بالحقيقة ، لكنها لا تزال ممتازة: نمو متوسط ​​العائد لكل مستخدم بنسبة 55٪. 

نوقف الاختبار ، نطبق مجموعة الاختبار على الإطلاق. و ... المقاييس تنخفض مرة أخرى. لماذا ا؟ 

تحقق من عدد المستخدمين


دعنا نكتشف عدد المستخدمين الذين زاروا موقعنا بالفعل أثناء الاختبار. استنادًا إلى السجلات ، 10٪ فقط من مجموعات الاختبار لدينا ، لكننا لم نأخذ ذلك في الاعتبار. 

إذا كان DAU (عدد المستخدمين الفريدين في اليوم) هو 1000 شخص ، فهذا لا يعني أنه في غضون عشرة أيام سيكون لديك 10000 مستخدم في الاختبار. قم دائمًا بتسجيل النتائج الحقيقية للاختبار (نتائج الاختبار) واحسبها فقط.

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

أطلقنا اختبار A / B.

النتائج ممتازة. نكسب المزيد من المال مرة أخرى! نقوم بتشغيل اختبارنا للجميع - وحدث خطأ ما مرة أخرى: بعد أسبوعين ، تكون المقاييس أقل مرة أخرى مما كان متوقعًا. 

هل تذكر أننا بدأنا في إرسال النتائج لجميع المستخدمين الذين زاروا الموقع؟ لا تفعل ذلك مطلقا. يجب إرسال الزيارات فقط إلى المستخدمين الذين تفاعلوا مع الجزء المختبر من المورد. وكلما كنت تعرفها بدقة أكبر ، كان ذلك أفضل. 

لحسن الحظ ، من السهل التحقق من ذلك. للقيام بذلك ، يمكنك إجراء اختبار A / A / B. يبدو أنه اختبار A / B ، ولكن في هذه الحالة لديك مجموعتان تحكم ومجموعة اختبار واحدة. لماذا هذا مطلوب؟ إذا تم اختيار وقت إرسال النتيجة بشكل غير صحيح ، فسيقع المستخدمون الذين لم يتفاعلوا مع الجزء المختبر من الموقع في الاختبار. في هذه الحالة ، ستكون هناك اختلافات كبيرة في المقاييس في المجموعتين أ و أ ، ويمكنك أن تفهم على الفور أن هناك خطأ ما. 

أطلقنا اختبار A / A / B. 

في المجموعة ب ، اترك 50٪ من المستخدمين ، وقم بتقسيم الـ 50٪ المتبقية بالتساوي بين المجموعتين أ و أ (نسميهم control و control_check). نعم ، سيتعين على النتائج الانتظار لفترة أطول ، ولكن من خلال ما إذا كانت نتائج المجموعتين A و A تتقارب ، ستفهم ما إذا كانت النتيجة قد تم إرسالها بشكل صحيح.



النتائج متواضعة (نمو 20٪ فقط) لكنها واقعية. لنبدأ التغيير على الإطلاق. 

كل شيء يعمل بشكل مثالي! 

ولكن بعد شهر ، انخفضت المقاييس مرة أخرى.

اختبار ما يمكننا السيطرة عليه


اتضح أن فوترة الجهات الخارجية أجرت أيضًا اختبار A / B ، مما أثر بشكل مباشر على نتائجنا. لذلك ، اتبع دائمًا نتائج الإنتاج وحاول اختبار ما تتحكم فيه بالكامل.

مجموع


يمكن أن تساعد اختبارات A / B المنتج على النمو. ولكن من أجل الثقة في الاختبارات ، من المهم إجراءها بشكل صحيح والتحقق دائمًا من النتائج. سيسمح لك هذا النهج باختبار منتجك واختبار الفرضيات قبل أن تسقط جميع المقاييس.

  • تحقق دائمًا من المجموعة المستهدفة.
  • إرسال الزيارات.
  • أرسل الضربات الصحيحة.
  • اختبر ما يمكنك التحكم فيه بالكامل.
  • /-!

All Articles