اختبار أ/أ يُبقي تجربة الزائر متطابقة بين المجموعتين لمراجعة إعداد القياس. [1] نشرح هنا تكرار الأحداث وفقدها بسجلات مؤلفة، ثم نميز هذه الأعطال من الضجيج الإحصائي، دون اختبار زوار حقيقيين.
الخلاصة السريعة
استخدم اختبار أ/أ لفحص إعداد التجربة والقياس قبل تفسير أثر تغيير تسويقي. تطابق الصفحة لا يفرض تطابق الأرقام في كل عينة، ولا يضمن وحده سلامة التسجيل.
- تتلقى المجموعتان التجربة نفسها؛ تشرح Statsig استخدام الاختبار لمراجعة وصول التعرضات وحساب المقاييس قبل اختبار أ/ب. [1]
- في مثالنا المؤلف، لكل مجموعة 1200 معرف، ونفصل معرف المستخدم عن معرف الحدث ونحدد ما الذي يعدّه المقياس.
- إرسال كل نقرة مرتين في المجموعة ب يرفع صفوف الأحداث من 240 إلى 480، لكنه لا يرفع عدد الناقرين الفريدين عن 240.
- في مثال منفصل، تسجيل 96 حدث نموذج من أصل 120 قبولًا يجعل المعدل الظاهر 8% بدل 10%؛ السجلات المفقودة تفسر الفرق المصنوع.
- عند افتراض عشرين اختبارًا مستقلًا بخطأ إيجابي قدره 5% لكل منها، يكون احتمال ظهور إشارة واحدة على الأقل نحو 64.15%، وليس صفرًا.
- محاكاة إعادة توزيع بيانات محفوظة لا تعيد اختبار إرسال الحدث من متصفح الزائر؛ لكل مسار سؤال مختلف.
- احفظ تعريفات المقاييس وأدلة الخلل والإصلاح، ثم تحقق من المسار المعدل قبل الانتقال إلى تغيير الصفحة؛ لا تختَر فائزًا من أ/أ.
ما الذي يبقى متطابقًا في اختبار أ/أ؟
تصف Statsig اختبار أ/أ بأنه تقسيم للزيارات إلى مجموعتين تتلقيان التجربة نفسها، بغرض مراجعة إعداد الاختبار ووصول بيانات التعرض وحساب المقاييس. الفرق عن اختبار أ/ب هنا هو غياب التغيير المقصود في المنتج بين المجموعتين؛ فلا نعرض زرًا جديدًا لطرف ونقارن أثره بالطرف الآخر. [1]
تخيل صفحة تطلب تسجيل الاهتمام بدورة تدريبية. في أ/أ يبقى العنوان والوصف والنموذج والزر كما هي في المجموعتين. قد يحتفظ نظام التجربة بتسميتين داخليتين ليتابع مسار كل مجموعة، لكن هذه التسميات ليست عرضين تسويقيين مختلفين للزائر. إذا غيّرت نص الزر أو ترتيب الحقول في إحداهما، فقد أضفت فرقًا فعليًا، ولم تعد تختبر الحالة المتطابقة التي نتحدث عنها هنا.
المقصود من المقارنة في مثالنا ليس إعلان أن اللون نفسه أقنع مجموعة أكثر من الأخرى. نريد أن نعرف هل تصل الوقائع التي نحددها إلى التقرير بالتعريف الذي اخترناه. إن ظهر فرق، فسيكون أمامنا سؤال عن مصدره بدل قصة جاهزة عن نجاح تصميم. وقد يتعلق الفرق بتباين العينة أو بإعداد المقياس أو بمسار التسجيل؛ لا يحدد اسم الاختبار وحده أي هذه الاحتمالات وقع.
كذلك لا تكفي صورتان متشابهتان لإثبات تطابق التجربة التقنية كاملة. قد تبدو الصفحة واحدة بينما ينفذ أحد المسارين استدعاء تسجيل إضافيًا. لهذا سنفصل في أمثلتنا بين ما فعله المستخدم، وما أُرسل من أحداث، وما حسبه التقرير. صورة الغلاف توضح فكرة تخطيطين متشابهين فقط؛ ليست لقطة من منصة اختبار ولا دليلًا على أن منظومة فعلية مرت بمراجعة تقنية.
اكتب تعريف الحدث والمقياس قبل قراءة النتائج
سننشئ مثالًا تعليميًا فيه مجموعتان، لكل منهما ألف ومئتا معرف مختلف. نفترض أن كل معرف ينتمي إلى مجموعة واحدة طوال الفترة، وأن كل مجموعة ترى الصفحة نفسها. هذه أعداد اخترناها لبناء سجل واضح، وليست نتائج توزيع عشوائي أجريناه. وفي مثال النقر الأول نحدد مسبقًا أن مئتين وأربعين مستخدمًا في كل مجموعة نقر كل منهم مرة واحدة فعلًا، بينما لم ينقر الباقون.
نحتاج إلى تمييز هوية المستخدم من هوية النقرة. للمستخدم اسم رمزي ثابت في الملف المؤلف، ولكل نقرة فعلية معرف حدث مستقل. إذا أعاد النظام إرسال النقرة نفسها، نفترض في هذا السيناريو أن الإرسالين يحملان معرف الحدث نفسه. أما لو نقر المستخدم مرة ثانية فعلًا، فهذه نقرة أخرى بمعرف آخر. لا يجوز اعتبار كل أحداث الشخص مكررة لمجرد أنها ترتبط بالمعرف نفسه.
عرّف أيضًا نوع المقياس الذي تقارنه. «عدد النقرات لكل مستخدم» يقسم عدد النقرات المحسوبة على عدد المستخدمين، بينما «نسبة المستخدمين الذين نقروا» تعد الأشخاص الذين لديهم نقرة واحدة على الأقل ثم تقسمهم على المستخدمين. في سجلنا السليم يتساوى الرقمان لأن كل ناقر نقر مرة واحدة فقط. هذا التساوي خاص بالبناء الذي اخترناه، وقد يختفي إذا سمحنا بنقرات فعلية متعددة للشخص.
اكتب في بطاقة المثال اسم التجربة والفترة ومعرف المجموعة والوحدة المعدودة وتعريف الحدث. وبالنسبة لمقياس نموذج التسجيل، حدد هل المقصود محاولة ضغط زر الإرسال أم قبول النموذج بنجاح. سنختار في المثال الثاني القبول الناجح، ونفصله عن النقر. إذا قارنت محاولات في جانب بقبولات في الجانب الآخر، فالمشكلة تبدأ من تعريفين مختلفين قبل أن تصل إلى أي اختبار إحصائي.
تتبّع نقرة تُرسل مرتين بدل افتراض تحسن التفاعل
في السيناريو الأول تصل نقرات المجموعة أ مرة واحدة، فيسجل الملف مئتين وأربعين صفًا. أما المجموعة ب، فنضيف إلى مسارها عيبًا مؤلفًا: يُرسل كل حدث نقرة مرتين بالمعرف نفسه، فيصل أربعمئة وثمانون صفًا. لم يزد عدد الأشخاص الذين نقروا، ولم تحدث نقرة ثانية فعلية. زدنا عدد رسائل الحدث المرسلة فقط، كي نختبر كيف ينعكس ذلك على مقياسين مختلفين.
إذا قسم التقرير صفوف النقر الخام على المستخدمين، فسيعرض للمجموعة أ مقدارًا قدره عشرون من مئة، وللمجموعة ب أربعون من مئة. قد يبدو الرقم الثاني ضعف الأول، لكنه في سجلنا يقيس أثر الإرسال المكرر. أما عد المستخدمين المختلفين الذين لهم نقرة، فيعطي مئتين وأربعين في كل طرف، وتكون نسبتهم عشرين في المئة في المجموعتين. لذلك يجب قراءة اسم المقياس وطريقة حسابه معًا.
راجع معرفات الأحداث في ب: هناك مئتان وأربعون قيمة مختلفة، ولكل قيمة صفان. بعد حساب حدث واحد لكل معرف نقرة في هذا المثال، يعود عدد النقرات إلى مئتين وأربعين. هذا ليس إذنًا عامًا لحذف كل صف متشابه في بيانات حقيقية؛ لقد أعطينا كل إعادة إرسال هوية الحدث الأصلي صراحة. إن كانت هوية الحدث غير موثوقة أو كانت الصفوف تمثل نقرات مختلفة، فلا يصح تطبيق الاستنتاج نفسه دون فحص.
ولنفترض أننا حددنا في القصة أن سبب التكرار هو استدعاء التسجيل من موضعين في مسار ب. الإصلاح الذي نختبره هو منع الاستدعاء المكرر، ثم إرسال سلسلة أحداث جديدة والتحقق من وصول كل هوية مرة واحدة. لا نغير تعريف المقياس إلى عد الأشخاص لمجرد إخفاء المشكلة إذا كان المطلوب أصلًا عد النقرات. قد يبقى مقياس الأشخاص صحيحًا في المثال، ومع ذلك يظل عيب الإرسال موجودًا ويؤثر في تقارير أخرى.
افصل فقد حدث النموذج عن انخفاض القبول الفعلي
نبدأ الآن سيناريو مستقلًا، ولا نجمعه مع عيب النقر السابق. لدينا ألف ومئتا معرف في كل مجموعة، ومئة وعشرون قبولًا ناجحًا للنموذج في كل طرف. نعرّف سجل القبول المرجعي في هذا المثال بأنه يحتوي معرّف قبول فريدًا لكل عملية ناجحة، ونبني البيانات على هذه الحقيقة. وفي مسار ب نحذف عمدًا أربعة وعشرين حدث قبول من سجل التحليلات، بينما تبقى عمليات القبول نفسها في السجل المرجعي.
يعرض تقرير التحليلات للمجموعة أ مئة وعشرين على ألف ومئتين، أي عشرة في المئة. ويعرض للمجموعة ب ستة وتسعين على ألف ومئتين، أي ثمانية في المئة. الفرق نقطتان مئويتان، ويعادل انخفاضًا نسبيًا قدره عشرون في المئة مقارنة بالعشرة. لكن القبول الفعلي في البناء المؤلف متساوٍ؛ الذي خسرناه هو أربعة وعشرون حدثًا من سلسلة القياس، لا أربعة وعشرون شخصًا تراجعوا عن التسجيل.
| العد | أ | ب |
|---|---|---|
| القبول المرجعي | 120 | 120 |
| أحداث التحليلات | 120 | 96 |
| المعدل الظاهر | 10% | 8% |
يمكن تتبع الفرق بمقارنة معرفات القبول المرجعية بمعرفات أحداث التحليلات، فتظهر القيم الأربع والعشرون المفقودة في ب. لا تعوّضها بضرب كل أرقام ب في معامل حتى تتساوى المعدلات؛ هذا يخفي مكان الانقطاع. في بيانات حقيقية تحتاج أولًا إلى إثبات أن المصدر المرجعي يعد الواقعة نفسها في الفترة نفسها، وأنه لا يتضمن عمليات مكررة أو مرفوضة. المرجع ليس صحيحًا لمجرد أنه موجود في خادم.
بعد معرفة سبب الفقد في المثال، نفرق بين إعادة بناء تقرير الماضي وبين التحقق من إصلاح المسار للمستقبل. إضافة الأحداث المعروفة من المرجع قد تصلح العد التاريخي إذا كانت طريقة الاستدراك مناسبة، لكنها لا تثبت أن المتصفح سيرسل الحدث التالي. لذلك نحتفظ بالسجل الأصلي ودليل المطابقة، ونختبر أحداثًا جديدة عبر المسار المعدل. لا نعلن نجاح صفحة ب أو فشلها من الفرق الذي صنعناه في التسجيل.
لماذا لا يعني كل فرق إحصائي وجود عطل؟
يوضح NIST أن مستوى دلالة قدره خمسة في المئة يتعلق برفض فرضية العدم وهي صحيحة عند تكرار الاختبار وفق شروطه. كما يعرّف قيمة الاحتمال بأنها احتمال نتيجة إحصائية بالغة التطرف على الأقل كالمرصودة، بشرط صحة فرضية العدم، ويوصي باختيار قاعدة القرار مسبقًا. ليست القيمة احتمال أن البرنامج معطّل. [2]
لنصنع تمرينًا احتماليًا منفصلًا: عشرون اختبارًا مستقلًا، جميع فرضيات العدم فيها صحيحة، ولكل اختبار احتمال خمسة في المئة لإشارة إيجابية خاطئة. العدد المتوقع للإشارات هو عشرون مضروبة في خمسة من مئة، أي إشارة واحدة في المتوسط. لا تعني كلمة «المتوقع» أن كل مجموعة من عشرين اختبارًا ستحتوي إشارة واحدة بالضبط؛ فقد تظهر صفر أو واحدة أو أكثر في مجموعة بعينها.
في فرض الاستقلال الذي اخترناه، احتمال ألا تظهر أي إشارة يساوي خمسة وتسعين من مئة مرفوعة للقوة العشرين، أي نحو خمسة وثلاثين فاصلة خمسة وثمانين في المئة. نطرح ذلك من الواحد لنحصل على احتمال ظهور إشارة واحدة على الأقل، وهو نحو أربعة وستين فاصلة خمسة عشر في المئة. هذا حساب يخص عشرين اختبارًا مستقلًا بتلك الشروط، ولا يثبت النسبة نفسها لعشرين مقياسًا مترابطًا في لوحة حقيقية.
لذلك لا تجعل ظهور خانة واحدة ذات دلالة في اختبار أ/أ حكمًا آليًا بعطل، ولا تجعل غيابها شهادة شاملة للمنظومة. راجع الفرضيات وتعريف المقياس ومسار البيانات ونمط النتائج المتكررة وفق خطة التحليل. وفي أمثلة التكرار والفقد السابقة عرفنا السبب لأننا بنينا سجلاته صراحة؛ لم نستنتجه من قيمة احتمال. كذلك لا تعِد فحص النتيجة في أوقات تختارها بعد رؤيتها ثم تتعامل مع كل قراءة كأنها الاختبار المحدد مسبقًا نفسه.
ما الفرق بين المسار المباشر والمحاكاة؟
تميز وثائق Statsig بين اختبار مباشر تمر فيه الأحداث من التطبيق، واختبار غير مباشر يعيد توزيع عينة بيانات محفوظة ويحسب مقاييسها. يساعد الثاني على مراجعة المحرك الإحصائي، بينما يفحص المسار المباشر وصول البيانات عبر التكامل الفعلي. لا تستبدل نتيجة أحدهما بالسؤال الذي صُمم الآخر للإجابة عنه. [1]
لربط ذلك بمثالنا، تخيل أنك أخذت جدول القبول المرجعي الصحيح، ثم وزعت صفوفه في ملف محاكاة. قد تكون الحسابات التي تجريها على هذا الملف متسقة تمامًا، لكنك لم تمرر حدثًا واحدًا عبر الجزء الذي أسقط أربعة وعشرين حدثًا من ب. نجاح العملية على الجدول لا يصلح ذلك المسار تلقائيًا. لقد اختبرت عمليات حسابية بعد وصول البيانات، بينما وقع العيب في المثال قبل اكتمال وصولها.
والعكس مهم أيضًا: وصول كل حدث تجريبي مرة واحدة إلى المستودع لا يثبت أن استعلام التقرير يختار المقام الصحيح أو الفترة الصحيحة. تستطيع أن تبني من الأحداث السليمة مقياسًا خاطئًا إذا عددت صفوفًا بدل مستخدمين، أو ضممت سجلات من أيام أخرى إلى مجموعة واحدة. في مراجعتنا نحتفظ باختبار إرسال محدود واضح، وفحص حساب مستقل للنتيجة، ثم نربط هوية الحدث بين المرحلتين.
لا تختصر اختبار أ/أ في تشغيل أداة وإطفائها بعد أن تبدو الأرقام هادئة. عرّف أي طبقة تريد فحصها: وصول الحدث، أو تعيين المجموعة، أو حساب المقياس، أو معايرة القرار الإحصائي. ثم اختر الدليل الذي يجيب عن ذلك السؤال. يمكن لفحص صغير مكتمل الوصف أن يثبت وصول سلسلة أحداث معينة، لكنه لا يثبت أن كل متصفح وكل ظرف استخدام قد غُطي بمجرد نجاح تلك السلسلة.
ماذا تحفظ قبل الانتقال إلى اختبار أ/ب؟
في نهاية أمثلتنا، نكتب نتيجة محددة لكل عيب: في سيناريو النقر وجدنا مئتين وأربعين هوية حدث في ب أُرسلت كل منها مرتين؛ وفي سيناريو النموذج وجدنا أربعة وعشرين قبولًا مرجعيًا غابت أحداثها عن التحليلات. لا ندمج النتيجتين في وصف مبهم مثل «القياس غير دقيق». لكل واحدة منهما دليل مختلف، وإصلاح مختلف، وسلسلة تحقق جديدة تناسب موضع الخلل الذي حددناه.
احفظ نسخة تعريف المقياس والفترة ووحدة المقارنة، ومعها السجل الاصطناعي أو عينة التحقيق المناسبة ودليل المطابقة. سجّل ما تغيّر في الإصلاح وتاريخ التحقق ونتيجته، وافصل البيانات المعاد بناؤها عن الأحداث التي وصلت فعلًا بعد الإصلاح. بهذه المعلومات يستطيع من يراجع التقرير معرفة هل شاهدتم عودة التسجيل الصحيح، أم أعدتم حساب جدول قديم بطريقة جديدة فقط.
بعد ذلك يمكن التخطيط لاختبار أ/ب يغيّر عنصرًا مقصودًا في تجربة الزائر، مع بقاء متطلبات جودة البيانات قائمة. أ/أ لا يمنح إذنًا دائمًا بتجاهل التسجيل؛ فقد يدخل التغيير الجديد مسارًا لم يكن موجودًا في الاختبار السابق. وإذا تغير تعريف الحدث أو موضع استدعائه، فهذه معلومة تستحق فحصًا يتناسب معها، لا مجرد افتراض أن نتيجة المراجعة القديمة ما زالت تغطي كل التفاصيل.
المخرج المفيد من هذا العمل هو وصف واضح لما تحقق وما بقي خارج الفحص، لا اختيار مجموعة فائزة رغم تطابق التجربة. في أمثلتنا فصلنا السلوك عن رسائل التسجيل، وفصلنا الرسائل عن تعريف المقياس، وفصلنا الخطأ المؤلف عن الضجيج الإحصائي الممكن. استخدم الفواصل نفسها عند قراءة تقريرك، واسأل عن الدليل وراء كل استنتاج قبل ربط رقم في اللوحة بقرار تغيير الصفحة.
المصادر ومتابعة القراءة
- Statsig: تشغيل اختبار أ/أ (يفتح في نافذة جديدة)docs.statsig.com
- NIST: القيم الحرجة وقيم الاحتمال في الاختبارات (يفتح في نافذة جديدة)itl.nist.gov
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.