أعددنا لقراء هبرا ترجمة لمقال لمايكل كامينسكي ، المدير السابق للتحليلات في هاريز. يتحدث عن الخطأ في اختبار A / B. تعليقات على المواد التي كتبها Gleb Sologub ، مدير التحليلات في Skyeng.
يعتمد مفهوم اختبار A / B على افتراض خاطئ بشكل أساسي بأن هناك حلًا واحدًا أفضل في المتوسط لجميع العملاء. يجب أن يتخلى المحللون عن افتراض أن جمهورهم متجانس ويبدأوا في تطوير أنظمة تسمح باستخدام (وتشجيع) نتائج الاختبارات بخلاف التجارب الثنائية.
خلال الأسابيع القليلة الماضية ، تم نشر مقالتين مهمتين للغاية حول التفسيرات غير القياسية لاختبارات A / B. تتعلق إحدى المقالات من مدونة هندسة Uber بحساب تأثير التأثير بواسطة الكميّات ، والآخر ( من مدونة StitchFix Data Science الممتازة باستمرار ) يدور حول استخدام خوارزميات قطاع الطرق السياقية لتحقيق التخصيص.
كلا المقالين مثيران للاهتمام ، لكن يبدو لي أن لديهما الكثير من النظريات حول تفسير وتنفيذ الاختبارات ويفتقران إلى الحقائق. أعيد صياغة رسالتي من أجل الوضوح:
يعتمد اختبار A / B التقليدي على افتراض خاطئ بشكل أساسي. في معظم الحالات ، سيكون الخيار "أ" أفضل لبعض المجموعات الفرعية ، والخيار "ب" للآخرين. اختيار A أو B في البداية يفقد مجموعة مختارة بعناية من A و B.
لسوء الحظ ، ليس من السهل تطبيق هذا النهج على الاختبار والتحسين وتطوير البرمجيات. يتطلب ذلك أدوات إحصائية جديدة وأدوات جديدة لتطوير ودعم حلول البرمجيات ، فضلاً عن تدريب أصحاب المصلحة ، إذا كنت تريد مشاركتهم في هذه العملية. في هذا المقال ، سأقدم مثالًا محفزًا ، وبعد ذلك سأتحدث عن بعض المشكلات التي ستواجهها عند إنشاء أنظمة تتكيف مع الواقع الجديد. لن أناقش البيانات الإحصائية الكامنة والمتعلقة ببناء هذه الأنواع من الأنظمة (أقرأ بشكل أفضل مقالة StitchFix وهذه المقالة من Google ) ، لكنني سأتحدث عن الفرص التي أراها على الصعيدين الاستراتيجي والمعماري.
تحفيز المثال
لإقناعك أن هذا أمر مهم ، دعونا ننظر إلى مثال صغير. على الرغم من أن هذه الأرقام وهمية ، إلا أنها تمثل تمامًا ما رأيته في أوقات لا تحصى في تقييم اختبارات A / B في الوقت الفعلي.
تبيع شركة Mattress أخرى (EOMK) مراتب على الإنترنت (يمكنك مشاهدة إعلاناتها في المترو). انهم يريدون اختبار نموذج طلب محدث الأمثل للهواتف. يشعر المصممون بقلق قليل من أنه على الرغم من أن الإصدار المحدّث أقل تعقيدًا ، إلا أنه ينقل أيضًا معلومات أقل أثناء عملية الطلب ويمكن أن يؤثر ذلك سلبًا على تحويلات المستخدمين بواسطة أجهزة كمبيوتر سطح المكتب.
يبدأ الفريق الاختبار ويحصل على النتائج التالية:
اللعنة ، لا فرق! حدسي ، عليك أن تقرر مشاركة حركة المرور على هاتفك المحمول والكمبيوتر.
واو! الإصدار الجديد ... أظهر بالضبط ما توقعه المصممون! أصبح الوضع أفضل لمستخدمي الأجهزة المحمولة وأسوأ لمستخدمي أجهزة الكمبيوتر.
إنه لأمر سيء أن اختبارنا A / B لم يظهر أي تأثير. ربما ينبغي أن نرسل مصممينا للتفكير في إصدار جديد من نموذج الطلب.
لكن انتظر! ماذا لو دعمنا إصدارًا محمولًا محسنًا للمستخدمين الذين يصلون إلى الموقع عبر الهاتف؟ وإصدار سطح المكتب الأمثل - للمستخدمين على أجهزة كمبيوتر سطح المكتب؟ ماذا لو أنشأنا صفحة مقصودة ستعمل بشكل أفضل في عطلات نهاية الأسبوع عندما يتوفر للناس المزيد من الوقت للقراءة؟ ماذا لو قمنا بإنشاء إعلان كان يعمل بشكل أفضل في كاليفورنيا بدلاً من ماساتشوستس؟
ماذا لو كانت صفحة الويب لا تناسب الجميع في وقت واحد؟
المهام
من الصعب القول ما إذا كانت هذه الفكرة واضحة أم ثورية. من الواضح أنه يبدو غبيًا تقريبًا. ولكن إذا نظرت إلى كيفية قيام معظم الشركات بتطوير منتجات البرمجيات واختبارها وتصحيحها ، فقد تبيّن أن هذا تحول أساسي إلى حد ما في طريقة التعامل مع مشكلات البرامج.
لا يزال لدى العديد من الشركات إصدار عمل واحد فقط للموقع. يمكن إجراء الاختبارات ، ولكن بمجرد أن يفوز أحد الاختبارات ، يتم تجاهل النسخة الخاسرة وتظهر النسخة الصحيحة الوحيدة ، "ملك التل".
لتغطية جميع تنوع العملاء والمستخدمين ، من الضروري تطوير حلول البرامج بطريقة مختلفة اختلافًا جذريًا. نحتاج إلى أدوات جديدة وأكثر تقدماً ، ونحتاج أيضًا إلى تدريب أصحاب المصلحة بطريقة تفكير جديدة.
اليوم ، من الصعب جدًا محاولة إدارة سيناريوهات الاستخدام باستخدام العديد من المتغيرات (إن أمكن). نظرًا لأن إدارة العديد من الخيارات باهظة الثمن ، فإن العديد من الشركات لا تحاول حتى تخصيص تجربة عملائها. بعد ذلك ، سأتحدث أكثر عن المشكلات وسأوضح طرق حلها.
أدوات البرمجة
في عالمنا الجديد الشجاع ، حيث نقدم مجموعة متنوعة من المحتوى لفئات مختلفة من المستخدمين (بنسب قد تتغير بمرور الوقت) ، نحتاج إلى أدوات لتطوير وتحليل برامجنا.
يبدو أن النتيجة الأكثر وضوحا لاستخدام مثل هذا النموذج ستكون زيادة كبيرة في حجم الكود في المشروع. بدلاً من حذف فروع الرموز القديمة بعد الاختبار ، سيتعين علينا دعمها (ربما إلى الأبد). هذا فظيع!
في الواقع ، نحتاج إلى جعل التطبيقات أكثر نموذجية حتى نتمكن من تطوير واختبار ونشر وصيانة فروع التعليمات البرمجية الجديدة باستمرار (على سبيل المثال ، الإصدارات الجديدة للاختبار).
من أجل التمكن من توجيه المستخدمين إلى فروع مختلفة من الشفرة استنادًا إلى خصائصهم (يحتمل أن يكون عدد فروع البرنامج النصي للمستخدم كبيرًا) ، من الضروري تطوير بنية تدعم هذا التفرع. نحتاج إلى آلية مركزية لصنع القرار يمكنها اختيار الطريق لهذا المستخدم. من الضروري أيضًا أن تكون مكونات المسار قابلة للتبديل بدرجة كافية لإرشاد المستخدم بحرية على طول المسار ، حتى لو تم تطويرها بشكل مستقل عن بعضها البعض ودون استخدام حالة واحدة.
أخيرًا ، بدون حالة استخدام واحدة شاملة ، نحتاج إلى أدوات حتى يتسنى لمديري المنتجات ومصمميها تخيل مسار العميل في مجموعة متنوعة من المسارات. كيف يمكننا تقديم وتقييم الميزات الجديدة؟ كيف يمكننا تتبع الخطوات التي مر بها هذا المستخدم عندما استخدم تطبيقنا؟ كيف يمكننا منع تطبيق من أن يتحول إلى كتلة عديمة الشكل من شفرة السباغيتي؟
التواصل والتدريب
سيكون من الصعب على الأشخاص البعيدين عن عملية إنشاء منتج أن يأخذوا هذه النظرة الجديدة في تطوير البرمجيات. اعتاد المديرون على الاهتمام بمسار مستخدم واحد ، والصوت الوحيد للعلامة التجارية ونفس التجربة العالمية للتفاعل مع العميل. عندما نبدأ في تخصيص تجربة المستخدم ، تختفي فرصة التحدث عن حل البرنامج من وجهة نظر واحدة فقط.
نحتاج إلى تثقيف أصحاب المصلحة حول قيمة هذا النهج الجديد ومساعدتهم على التفكير في البرمجة النصية المخصصة وصوت العلامة التجارية في هذا السياق. من الضروري تطوير طرق لتحديد الطرق الأكثر شيوعًا. امنح المديرين الأدوات اللازمة لدراسة المنتج نيابة عن مستخدم من مجموعة فرعية معينة ، حتى يتمكنوا من اكتساب خبرة في التفاعل مع منتج مخصص للمستخدمين المختلفين من وجهات نظر مختلفة.
الأدوات الإحصائية
على الأرجح ، في عالم بدون اختبار A / B ، سيتعين علينا التخلص من العديد من الأدوات التي استخدمناها تقليديًا لتحسين تطبيقات الويب. كل جهودنا لتدريب مديري المنتجات والمسوقين في إطلاق وتفسير اختبارات A / B لن تكون مهمة.
في هذا العالم الجديد ، سنحتاج إلى تطوير أساليب جديدة للبحث وتصور عينات من أحجام مختلفة. سنحتاج إلى طرق مقارنة جديدة وأكثر تقدماً حتى لا نقع في فخ المقارنات المتعددة .
الاستنتاجات
مع الأخذ في الاعتبار التنوع الحقيقي في قاعدة المستخدمين لدينا ، يمكننا تحسين التفاعل مع عدد كبير من المستخدمين ، وهو أمر ذو قيمة كبيرة. لسوء الحظ ، كما يحدث في كثير من الأحيان عند تغيير النهج لتطوير وتنفيذ التكنولوجيات ، فإن هذه المزايا غالية الثمن. أمامنا طريق طويل لنقطعه من النقطة التي نحن فيها الآن ، إلى مستقبل مثير أكثر تخصيصًا ، وأنا متأكد من أن هذه الرحلة ستكون مثيرة.
ملاحظة المؤلف:
أستبعد كل المناقشات المتعلقة بفواصل الثقة والأهمية الإحصائية للبساطة. اسف
تعليق من Gleb Sologub ، مدير التحليلات في Skyeng
يلخص مايكل الاتجاهات الحالية للتخصيص ويتخيل ما ينبغي أن يكون وسيلة وأساليب التطوير والتحليلات ، عندما يتم تخصيص جميع منتجات تكنولوجيا المعلومات بالكامل لمستخدمين محددين.
لقد تعلمنا حتى الآن كيفية التخصيص بطريقتين: أولاً ، عن طريق إنشاء سيناريوهات منفصلة لشرائح مختلفة من المستخدمين ، وثانياً ، من خلال تطوير حلول خوارزمية لعرض محتوى مخصص في خطوات فردية من المسار.
لذلك ، قامت Skyeng بالتأكيد بتحسين إصدارات الأجهزة المحمولة من الموقع ومنصة التدريب ، بالإضافة إلى إصدارات مختلفة من هذه المنتجات للمستخدمين من مختلف الأعمار. بالإضافة إلى ذلك ، أجرينا اختبارات AB وأدركنا أن المستخدمين من مختلف المناطق لديهم احتياجات مختلفة ، وبعد ذلك قدمنا تمايزًا لوصف التسويق اعتمادًا على المنطقة.
إلى أمثلة التخصيص الخوارزمي ، بالإضافة إلى تلك التي ذكرها مايكل ، يمكن للمرء أن يضيف كلًا من القوائم الطويلة والمستخدمة على نطاق واسع للمنتجات أو المحتوى الموصى به ، بالإضافة إلى النجاحات الحديثة نسبيًا في إنشاء ملصقات فردية للأفلام.
ومع ذلك ، كل هذا يمكن القيام به مع الاستمرار في استخدام أساليب التنمية القديمة والتحليلات.
في المستقبل نفسه الذي يصفه مايكل ، قد لا تكون اختبارات AB ، كما هي ، جديرة بالاهتمام ، لكنها ستحتاج إلى وحدات برمجية مذهلة وبعض أساليب التحليل الجديدة لإنشاء مجموعة لا نهائية من سيناريوهات المستخدم الفردية تمامًا.
نحن في Skyeng لدينا بالفعل فريق من الباحثين والمحللين الذين ندرس هذه الاتجاهات ونعمل على توسيعها ، ونحاول تطبيقها لتحسين منتجاتنا.