اختبار A / B للأجهزة المحمولة: 7 أخطاء كبيرة ومفاهيم خاطئة يجب تجنبها

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

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

1. قم بإنهاء التجربة قبل أن تحصل على العدد المناسب من الزيارات

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

للحصول على أدلة موثوقة ، عليك الانتظار حتى الوصول إلى المقدار المطلوب من حركة المرور لكل من المتغيرين "أ" و "ب".

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

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

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

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

2. الانتهاء من التجربة قبل مرور 7 أيام

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

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

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

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

الدرس المستفاد: بسبب القمم الضعيفة في النشاط التي تختلف لكل لعبة أو تطبيق محمول ، لا تنهي التجربة قبل انتهاء الدورة الكاملة (سبعة أيام).

3. اختبار التغييرات الصغيرة جدًا في التصميم

هناك خطأ أكثر شيوعًا في اختبار A / B للأجهزة المحمولة وهو مقارنة الاختلافات التي تبدو متشابهة تقريبًا بسبب الاختلافات الطفيفة في التصميم.

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

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

للتأكد من أنك تختبر تغييرًا كبيرًا في أ / ب ، اعرض كلا النسختين لعائلتك أو أصدقائك. دع زميلك يلقي نظرة على كل شكل لمدة 3-5 ثوان. إذا كانوا لا يعرفون الفرق ، فمن الأفضل إعادة تصميم الأصول المرئية الخاصة بك.

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

4. إعلانات البانر الخاصة بك لها نفس التصميم كأحد الأصول المرئية لمتجر التطبيقات

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

على سبيل المثال ، تجري تجارب لتطبيقك التعليمي. أنت تصمم شعارًا يحتوي على نفس العنصر ، مثل الرمز من الشكل أ ، في حين أن الشكل ب هو رمز آخر تمامًا. سيعرض الشكل (أ) معدل التحويل الأعلى ، نظرًا لأنه يحتوي على نفس التصميم ، كما شاهده مستخدمو البانر في البداية وقاموا بالنقر فوقه.

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

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

5. اختبار عدة فرضيات في وقت واحد

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

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

الدرس المستفاد: إذا اختبرت عدة فرضيات في وقت واحد ، فلن تتمكن من فهم أي منها صحيح.

6. إساءة تفسير الموقف عندما يكون هناك شكلين متشابهين ولكنك تحصل على فائز

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

على النظام الأساسي SplitMetrics ، عند مستوى الأهمية 5٪ ، في مثل هذه الحالة ، سترى أن النتيجة غير مهمة.

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

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

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

7. الانزعاج عندما يخسر التباين الجديد من الشكل الحالي

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

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

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