غالباً ما يتم وصف اختبار A / B كطريقة علمية للتحقق من صحة قرارات التصميم. يُشار في بعض الأحيان إلى اختبار الانقسام ، ويعتبر اختبار A / B عملية بسيطة يبدو أنها تظهر على السطح نتائج ملموسة:
قم بإنشاء صيغتين على عنصر التصميم ، وقم بتبديلهما عشوائياً على موقعك وتسجيل كيفية تفاعل المستخدمين لديك ، ومقارنة النتائج ، وتنفيذ أيهما أفضل أداء. يبدو الأمر معقولا.
المثال الكلاسيكي هو: الزر الأحمر مقابل الزر الأخضر ، والذي سيتم استغلاله أكثر؟ ومع ذلك ، فإن السؤال الأكثر إثارة للاهتمام هو: الزر الأخضر مقابل الزر الأخضر نفسه ، الذي سيتم استغلاله أكثر؟
ماذا يحدث عند اختبار A / B للاختلافين المتطابقين؟ اختبار A / A ، إذا صح التعبير.
من أجل اختبار صلاحية أي اختبار A / B ، نحتاج إلى اختبار يحتوي على إجابة "صحيحة". نحتاج إلى إجابة صحيحة لأننا نريد أن نعرف ، كل الأشياء متساوية ، ما مدى احتمالية أن يؤدي اختبار A / B إلى النتيجة التي يجب أن تحققها ، ولهذا نحتاج إلى معرفة النتيجة المتوقعة.
إذا اختبرنا A / B (أ / ب) زرين متماثلين ، يجب أن تكون النتيجة حرارة ميتة
لذا ، لنفترض أننا نجري اختبارًا على الزر الأخضر في مقابل الزر الأخضر نفسه ، وأن الزر مغري لدرجة أن 100٪ من المستخدمين سيقومون بالنقر عليه.
(النسبة لا تهم في الواقع ، يمكن أن تكون 14.872٪. ما يهم هو أنه لأن الأزرار متطابقة ، يجب أن يكون معدل الحذف متطابقًا أيضًا.)
إذا اختبرنا A / B (أ / ب) زرين متماثلين ، يجب أن تكون النتيجة حرارة ميتة.
إرم عملة. أي جانب سيأتي ، رأسًا أم ذيولًا؟ نحن نعلم أن هناك وجهين متطابقين ، لذا فهي فرصة 50-50.
إذا أرمنا عملتنا المعدنية مرتين ، فإننا نعلم أن هناك ثلاث نتائج محتملة: رأسيان ، أو ذيلان ، أو رأس واحد و 1 ذيول. وما إلى ذلك وهلم جرا…
دعونا نقول أن رمي العملة هو اختبار A / A لدينا. تتناسب احتمالات ارتداد الرؤوس الجانبية مع احتمالات وصول جانب ذيول ، تمامًا كما تتساوى احتمالات استخدام أي من أزرارنا الخضراء.
لذلك دعونا نكتب نصًا سريعًا في المتصفح (لأن معظم اختبارات A / B يحدث في المتصفح) لمحاكاة المستخدمين النقر على زر واحد أو آخر ، اعتمادًا على أي واحد منهم تم تقديمه.
تذكر: نحن نختبر شكلين متطابقين لأحد الأزرار ، والطريقة التي نعرف أنها متطابقة هي أننا نتعامل مع احتمال استغلالها كطريقة متطابقة. كل ما نبحث عنه هو نتيجة ثابتة (وبالتالي صحيحة).
أولاً ، نحتاج إلى جدول HTML لتسجيل نتائجنا ، وسيبدو الجدول كما يلي:
# Heads Tails Difference Margin of Error
في العمود الأول سنسجل رقم الاختبار (جميع اختبارات A / B الجيدة ، يتم تكرارها للتحقق من النتائج ، لذا سنكرر الاختبار عدة مرات). بعد ذلك سنقوم بتسجيل عدد نتائج Heads ، ثم عدد نتائج Tails . سيكون العمود بعد ذلك هو الفرق بين النتيجتين (التي يجب أن تكون صفراً). ثم سنقوم بتسجيل هامش الخطأ (والذي يجب أن يكون 0٪). أسفل الجدول ، سنطبع ملخصًا ، ومعدل جميع النتائج ، وأسوأ نتيجة.
وهنا النص:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% "; // add result to tabletotalDifference += difference; // increments the difference counterworstDifference = difference > worstDifference ? difference : worstDifference; // updates worstDifferenceif(--testRepeat == 0){var averageDifference = totalDifference / testCount, // finds average differenceaverageError = (averageDifference / bestOf) * 100; // finds the average error margindocument.getElementById("summary").innerHTML = "Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}
تم التعليق على الشفرة ، لذا إليك النقاط البارزة فقط:
أولاً قمنا بإعداد بعض المتغيرات بما في ذلك عدد المرات التي نرغب فيها لإرم العملة (bestOf) وعدد المرات التي نرغب فيها في تكرار الاختبار (testRepeat).
تنبيه المفسد: سوف نصل إلى بعض الحلقات العالية إلى حد ما ، وذلك لتجنب كسر متصفح أي شخص نقوم بتشغيل الاختبار على فاصل زمني كل 100 مللي ثانية.
داخل الدالة performCoinToss نقوم بتكرار العدد المطلوب من المرات ، كل تكرار للحلقة نستخدم الدالة العشوائية لجافا سكريبت لتوليد إما 1 أو 0 ، والتي بدورها تزيد إما headsCounter أو the tailsCounter .
بعد ذلك نكتب النتيجة من هذا الاختبار إلى الجدول.
وأخيرًا ، إذا تم تكرار الاختبار عدد المرات التي نرغب فيها ، فإننا نجد المتوسطات ، وأسوأ الحالات ، نكتبها إلى الملخص ، ونمسح الفاصل الزمني.
وهنا النتيجة . كما ترون أن متوسط الفرق هو ، سيكون مختلفًا بالنسبة لك ، ولكن أثناء كتابتي لهذا فإن متوسط الفرق هو 2.8333333333333335 ، وبالتالي فإن متوسط الخطأ هو 23.611111111111114٪.
لا يزيد الخطأ بنسبة 23٪ من الثقة ، خاصةً أننا نعلم أن الفرق يجب أن يكون 0٪. ما هو أسوأ من ذلك هو أن أسوأ حالة لي هي 8 ، وهذا هو 10-2 لصالح الرؤساء.
حسنًا ، لم يكن هذا الاختبار عادلاً. لن يدّعي اختبار A / B الحقيقي مطلقًا العثور على نتيجة نهائية من 12 مستخدمًا فقط.
يستخدم اختبار A / B شيئًا يسمى "دلالة إحصائية" يعني أن الاختبار يجب أن يعمل مرات كافية لتحقيق نتيجة قابلة للتنفيذ.
لذا ، دعنا نضاعف المتغير الأفضل ونرى المدى الذي نحتاج إليه للوصول إلى هامش الخطأ ، أقل من 1٪ - أي ما يعادل ثقة 99٪.
في أفضل من 24 (في وقت كتابة هذا التقرير) ، يبلغ متوسط الفرق 3.1666666666666665 وهو 13.194444444444445٪. خطوة في الاتجاه الصحيح! جربها بنفسك (ستختلف نتائجك).
دعونا مضاعفة مرة أخرى. هذه المرة ، بلغ متوسط الفرق 6.666666666666667 ، مع وجود هامش للخطأ من 13.88888888888889 ٪. الأسوأ من ذلك ، أسوأ حالة هي 16 ، وهذا خطأ من 33.33333333333333 ٪! تستطيع حاول هذا واحد لنفسك ايضا.
في الواقع ، لا توجد جوائز للتخمين بأننا نستطيع الاستمرار: أفضل من 96 ، أفضل من 192 ، أفضل من 384 ، أفضل من 768 ، أفضل من 1536 ، أفضل من 3072 ، أفضل من 6144 ، أفضل من 12288 ، أفضل من 24576 ، أفضل من 49152 ، أفضل من 98304 .
وأخيرًا ، عند أفضل 98304 ، سينخفض سيناريو أسوأ الحالات إلى أقل من 1٪. وبعبارة أخرى ، يمكننا أن نكون واثقين بنسبة 99٪ من أن الاختبار دقيق.
لذلك ، في اختبار A / A ، النتيجة التي عرفناها مسبقا ، أخذ حجم عينة من 98،304 للوصول إلى هامش مقبول من الخطأ.
عندما تتم مناقشة اختبار A / B ، يتذكّر أحدهم صديقًا لصديقه ، الذي اختبر A / B زرًا واحدًا على موقعه ، وحقق على الفور أرباحًا غير محتملة (تزداد قيمة الدولار الفعلية للزر في كل مرة أسمع فيها قصة).
في هذه القصص ، يتم اختبار الأزرار عادةً للنسخ المصغرة ، "تنزيل الكتاب الإلكتروني" مقابل "تنزيل الكتاب الإلكتروني المجاني". لا ينبغي أن يكون مفاجأة أن يفوز الأخير. إنه تحسن من شأنه أن يجعل أي مؤلف جيد. سيكون اختبار A / B الأكثر ملاءمة هو "تنزيل الكتاب الاليكتروني الخاص بي" مقابل "تنزيل الكتاب الاليكترونى" (أموالي على هذا الأخير).
إذا وجدت نفسك مصحوبًا بإحدى النتائج المرجوة نحو أحد الخيارات ، فهذا يشير إلى أن هناك خطأ ما في أحد الاختلافات. في كثير من الأحيان ، ستكون النتيجة الجيدة تحسنًا أقل من 5٪ ، مما يمثل مشكلة إذا كنت تختبر حوالي 1000 مستخدم (يبلغ هامش الخطأ 5٪ تقريبًا).
وكلما كان الاختبار أكثر فائدة ، كلما كان هامش الانتصار أكثر صغرًا لواحد أو آخر. ومع ذلك ، كلما كان هامش الفوز أكثر إحكاما ، كلما ازداد حجم العينة اللازم لتعطيك هامش خطأ صغير مقبول.
مارك توين ، ربما كان يقتبس من ديسرايلي ، استخدم في الماضي عبارة " الأكاذيب والأكاذيب اللعينة والإحصاءات. والذي يعني أن شيئًا أثبتته الإحصاءات ، ليس صحيحًا بالضرورة. يمكن استخدام الإحصائيات لإثبات أي شيء تريده.
سيوفر لك اختبار A / B نتيجة ، ولكنها نتيجة ستقول المزيد عنك وعن ما تتوقع أن تجده ، أكثر من اهتمامك بعملائك
أخطر شيء في اختبار A / B هو أنه يمكنه إثبات أي شيء تريده ؛ يمكن أن يؤدي إلى نتائج إيجابية خاطئة ، ويمكّننا من تمييز أنماط غير مدعومة بشكل صحيح.
علاوة على ذلك ، قد يشير اختبار A / B إلى أن الزر الأخضر يتفوق على الزر الأحمر ، ولكن ماذا عن الزر الأزرق؟ حتى اختبار A / B الناجح فقط يسمح لنا بالتأكد من صحة قرارات التصميم لدينا في سياق الاختبار نفسه.
لكي يعمل اختبار A / B على النحو المنشود ، نحتاج إلى وجود شرطين متعارضين:
للأسف ، لا تحتوي معظم المواقع على حجم عينة كبير بدرجة كافية للوصول إلى هامش خطأ صغير بما فيه الكفاية. ولأننا لا نستطيع زيادة حجم العينة لدينا (لو كنا نستطيع ذلك) ، فإن خيارنا الوحيد هو زيادة التباين في الخيارات من أجل الحصول على نتيجة واضحة ، مما يفسد الاختبار حسب تفضيلاتنا.
سيوفر لك اختبار A / B نتيجة ، ولكنها نتيجة ستقول المزيد عنك وعن ما تتوقع العثور عليه ، أكثر من اهتمامك بعملائك. عندما يتعلق الأمر باتخاذ قرارات التصميم على أي موقع بخلاف تلك التي تحتوي على كميات كبيرة جدًا من الزيارات ، فقد نقوم أيضًا بإلغاء عملة معدنية ، كاختبار A / B.