اختبارات A / B على Android من الألف إلى الياء

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

مفهوم اختبار A / B

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

التنفيذ

1. تقسيم المستخدمين إلى مجموعات

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

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

في Firebase Console ، في المجموعة Grow ، توجد علامة تبويب "التكوين عن بُعد" حيث يمكنك إنشاء التكوين الخاص بك الذي سيوفره Firebase لمستخدمي تطبيقك.


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



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



ملاحظة عادةً ما تسمى المجموعة الضابطة المجموعة أ ، وتسمى المجموعة التجريبية ب. كما ترى في لقطة الشاشة ، في Firebase تسمى المجموعة التجريبية الافتراضية "المتغير أ" ، والتي تقدم بعض الارتباك. لكن لا شيء يمنع تغيير اسمه.

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

2. الرمز

لن نتطرق مباشرة إلى التكامل مع Firebase Remote Config - يتم وصفه بالتفصيل هنا .

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

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

إذا تحدثنا عن MVP في طبقة العرض التقديمي ، فستبدو كما يلي:



يبدو أن التسلسل الهرمي الطبقي الأكثر مرونة وشفافية هو:



ستحتوي BaseOrderStatusFragment على جميع وظائف التطبيق الحالي ، باستثناء الطرق التي لا يمكن وضعها في فئة مجردة بسبب قيود الهندسة. سوف تكون موجودة في OrderStatusFragment.

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

ملاحظة: إذا سمحت البنية والحالة الخاصة ، يمكنك الاستغناء عن إنشاء فئة أساسية وترث AbOrderStatusFragment مباشرة من OrderStatusFragment.

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

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

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

حسنًا ، وبالطبع ، من المهم عدم نسيان إلقاء قيمة المعلمة من التهيئة في معلمات حدث التحليلات ، حتى تتمكن من مقارنة المقاييس

تحليل النتائج

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

مطبات

1. خطأ في الحصول على التكوين عن بعد

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

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

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



ملاحظة بيانات آخر 30 يومًا. العدد الإجمالي للطلبات 673 529 . يحتوي العمود الأول ، بالإضافة إلى طلبات الشبكة ، على استلام التكوين من ذاكرة التخزين المؤقت ، وبالتالي يتم إخراجه من نموذج التوزيع العام.


2. التخريش التحديث البعيد التكوين

يجب أن تفهم أن Firebase يخزّن طلبًا للتكوين عن بُعد. العمر الافتراضي لذاكرة التخزين المؤقت هو 12 ساعة. يمكن تعديل الوقت ، ولكن لدى Firebase حدًا لتكرار الطلبات ، وإذا تم تجاوزه ، فسيقوم Firebase بحظرنا وسيرجع خطأ في طلب التكوين. ممكن لعدد محدود من الأجهزة).

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

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

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS FirebaseRemoteConfig.getInstance().fetch(cacheExpiration) 

نظرًا لعدم إصدار التحديثات في كثير من الأحيان ، فلن نتجاوز الحدود
اقرأ المزيد عن هذه القضايا هنا .

الاستنتاجات

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

حظاً طيباً للجميع ، واختبار أ / ب ناجح وزيادة بنسبة 100.5٪ في التحويلات.