اختبار A/B | STAT-101

التجريب على نطاق واسع

كل مرة بتفتح صفحة ويب، أو تدوس على زرار، أو تشوف عنوان خبر، فيه احتمال كبير إنك جزء من تجربة. شركات التكنولوجيا بتعمل آلاف اختبارات A/B في نفس الوقت — بتقارن النسخة A (الـ control) بالنسخة B (الـ variant) عشان تعرف أنهي واحدة بتطلّع نتايج أحسن. Netflix بتختبر صور الـ thumbnails. وAmazon بتختبر ألوان الزراير. وGoogle بتختبر درجة اللون الأزرق في لينكات البحث. ده الـ experimental design زي ما بيتمارس على نطاق الإنترنت.

اختبار A/B هو ببساطة randomized controlled experiment متطبّقة على منتج رقمي. كل المبادئ من الدرس اللي فات بتنطبق هنا — الـ randomization، ومجموعات الـ control، والـ power analysis — بس مع مجموعة معيّنة من الأعراف والمقاييس وأشكال الفشل الخاصة بالسياق الرقمي.

الفكرة الجوهرية

قسّم المستخدمين عشوائي لمجموعتين. ورّي المجموعة A التجربة الحالية. وورّي المجموعة B التجربة المعدّلة. وقيس هل الفرق في النتايج أكبر من اللي الصدفة لوحدها تقدر تفسّره.

اختبار A/B = randomized controlled experiment متطبّقة على قرارات المنتج

الإعداد: الفرضية والـ metric

كل اختبار A/B بيبدأ بـ فرضية متحددة كويس. الفرضية الغامضة زي “التصميم الجديد هيبقى أحسن” مينفعش تتختبر. والفرضية الدقيقة بتحدد: إنت بتغيّر إيه، وبتقيس أنهي نتيجة، ومتوقع تتحرك في أنهي اتجاه. مثلًا: “لو نقلنا زرار الـ call-to-action فوق الـ fold هيزوّد الـ click-through rate.”

اختيار الـ primary metric (المقياس الأساسي) مهم جدًا. تقدر تقيس تقريبًا أي حاجة — الضغطات، والمشتريات، ومدة الـ session، والزيارات اللي بترجع، والإيرادات لكل مستخدم — بس لازم تلتزم بـ primary metric واحد قبل ما تشغّل الاختبار. وإنك تشغّل الاختبار وبعدين تختار أنهي metric اتحرك ده شكل من أشكال الـ p-hacking وبيكبّر معدل الـ false positives.

الـ metrics الكويسة حساسة (بتتغيّر بشكل واضح لما العلاج ينجح)، وفي وقتها (ينفع تتقاس جوه شباك الاختبار)، وماشية مع أهداف البيزنس. والـ metric اللي سهل تحرّكه بس مالوش علاقة بالقيمة الحقيقية هو vanity metric — ممكن يخلّيك تطلّع تغييرات بتضر على المدى البعيد.

الـ sample size: إمتى يبقى كفاية

قبل ما تطلق اختبار A/B، لازم تحدد كل مجموعة محتاجة كام مستخدم. وده محتاج نفس الـ power analysis من الدرس اللي فات، متظبّط على الـ metrics اللي بتستخدمها.

للنتيجة الثنائية (المستخدم ضغط ولا لأ؟)، الكميات المهمة هي: الـ baseline conversion rate p، والـ minimum detectable effect Δ (أصغر تحسين يستاهل الاهتمام)، ومستوى الـ significance α (عادةً 0.05)، والـ power اللي عايزها 1−β (عادةً 0.80).

الـ sample size للنسب (لكل مجموعة)

n = \frac{(z_{\alpha/2} + z_{\beta})^2 \bigl[p_1(1-p_1) + p_2(1-p_2)\bigr]}{\Delta^2}

p̄ = (p₁ + p₂)/2 هي النسبة الـ pooled؛ وz_α/2 وz_β هما الـ critical values للـ significance والـ power؛ وΔ = p₂ − p₁ هو الـ minimum detectable effect.

غلطة مشهورة إنك تحط الـ minimum detectable effect صغير أوي — تحاول تلقط تحسين 0.01% والـ baseline هو 5%. وده محتاج sample sizes ضخمة ومدة اختبار طويلة. بدل كده، اسأل: إيه أصغر تأثير هيأثر فعلًا على قرارنا إننا نطلّق التغيير؟ والتأثيرات الأصغر من كده متستاهلش تتلقط.

تشغيل الاختبار: الـ randomization والمدة

وحدة الـ randomization مهمة. تقدر تعمل randomization على مستوى كل page view، أو كل session، أو كل user ID. والـ randomization بالـ user ID (بحيث كل مستخدم يشوف دايمًا نفس الـ variant) عادةً هي الصح: بتمنع إن نفس المستخدم يتعرض للنسختين، وده بيلوّث المقارنة.

آلية التوزيع لازم تبقى عشوائية بجد. طريقة منتشرة إنك تعمل hash للـ user ID والـ experiment ID مع بعض، وبعدين تاخد الناتج modulo 100 عشان توزّع نسب الـ buckets. وده بيضمن توزيع deterministic بس عمليًا عشوائي وثابت بين الزيارات.

مدة الاختبار بتتحدد بحساب الـ sample size ومعدل الـ traffic، بس فيه قيدين زيادة. الأول، شغّل الاختبار أسبوع كامل على الأقل عشان تمسك تأثيرات يوم الأسبوع — سلوك المستخدمين بيختلف بين أيام الشغل والويك إند. والتاني، شغّله وقت كفاية عشان تمسك الـ novelty effects: المستخدمين أحيانًا بيتفاعلوا بشكل مختلف مع التغييرات بس عشان هي جديدة، والتأثير ده بيختفي بعد كام يوم.

ليستة مراجعة المدة

1. طويلة كفاية عشان تجمع الـ sample size المطلوب.

2. أسبوع كامل على الأقل (7 أيام) عشان تحسب حساب تأثيرات يوم الأسبوع.

3. طويلة كفاية عشان تشوف السلوك الثابت بعد ما الـ novelty effects تختفي.

4. قصيرة كفاية عشان سياق البيزنس ميتغيّرش بشكل واضح أثناء الاختبار.

تحليل النتايج: الـ t-test والـ chi-squared test

أول ما الاختبار يخلص، بتقارن المجموعتين. واختيار الاختبار معتمد على نوع الـ metric.

للـ continuous metrics (متوسط الإيرادات لكل مستخدم، مدة الـ session)، استخدم الـ two-sample t-test. ده بيختبر هل متوسطات المجموعتين مختلفة أكتر من المتوقع بالصدفة.

وللـ binary metrics (الـ conversion rate، والـ click-through rate)، استخدم الـ two-proportion z-test أو اللي يكافيه الـ chi-squared test للاستقلالية. والـ test statistic هو:

الـ two-proportion z-test

z = \frac{\hat{p}_1 - \hat{p}_2}{\sqrt{\bar{p}\,(1-\bar{p})\!\left(\frac{1}{n_1}+\frac{1}{n_2}\right)}}

p̂₁ وp̂₂ هما الـ conversion rates اللي اتشافت في الـ control والـ variant؛ وp̄ هي النسبة الـ pooled؛ وn₁ وn₂ هما حجمين المجموعتين. ارفض H₀ لما |z| > z_α/2.

قول النتيجة بـ confidence interval للفرق، مش بس p-value. نتيجة significant بتقول “الـ variant حسّن الـ conversion rate بنسبة 0.001% (confidence interval 95%: 0.0002%–0.002%)” بتدّي معلومات أكتر بكتير من “p = 0.03.” الـ confidence interval بتقولك المدى المعقول لحجم التأثير الحقيقي، وده اللي فعلًا بيحدد هتطلّق ولا لأ.

اختبار A/B البايزي

الطريقة الـ frequentist اللي فوق ليها نظير: اختبار A/B البايزي. بدل ما تحسب p-value وتقارنها بعتبة، الطريقة البايزية بتعمل model للـ conversion rates كـ random variables ليها prior distributions، وبتحدّثها بالبيانات اللي اتشافت، وبتحسب الـ posterior probability إن الـ variant B أحسن من الـ control A.

الميزة الأساسية هي سهولة التفسير. “فيه احتمال 97% إن الـ variant B الـ conversion rate بتاعه أعلى” جملة أغلب الـ product managers يقدروا يفهموها بالبديهة. في المقابل، الـ p-value الـ frequentist 0.03 كتير بتتفسّر غلط على إنها نفس الجملة دي — بس هي مش كده. هي احتمال إنك تشوف بيانات متطرفة بالشكل ده لو الـ null hypothesis صح، وده ادعاء مختلف بشكل دقيق بس مهم.

الاختبارات البايزية كمان بتتعامل مع مشكلة الـ continuous monitoring (المتابعة المستمرة) بشكل أشيك. في الإطار الـ frequentist، إنك تبص على النتايج في نص التجربة وتقف بدري بيكبّر معدل الـ false positives. وفي الإطار البايزي، تحديث الاعتقادات مع وصول البيانات طبيعي فلسفيًا، مع إن التطبيق المظبوط لسه محتاج تفكير في الـ stopping rules.

الـ prior distribution

p \sim \mathrm{Beta}(\alpha,\,\beta)

prior Beta(α, β) للـ conversion rate p. α − 1 نجاح قبْلي، وβ − 1 فشل قبْلي.

الـ posterior distribution

p \mid \text{data} \sim \mathrm{Beta}(\alpha + s,\; \beta + n - s)

بعد ما تشوف s نجاح في n محاولة، الـ posterior هو Beta(α + s, β + n − s).

الغلطات المشهورة

الـ peeking (البص بدري) هو أشهر غلطة. بتطلق اختبار، وبتبص على النتايج كل يوم، وبتقف أول ما تشوف p < 0.05. وده غلط إحصائيًا. تحت الـ null hypothesis، الـ p-value هتنزل تحت 0.05 حوالي 5% من الوقت بالصدفة — بس لو بصّيت عليها كتير، بتزوّد جامد فرصة إنك تقع عليها وهي false positive. والمحاكاة بتوري إن البص كل يوم في تجربة مدتها أسبوعين ممكن يرفع معدل الـ false positives من 5% لأكتر من 25%.

الـ multiple metrics بتعمل مشكلة شبهها. لو اختبرت 20 metric وأعلنت الكسب لما أي واحد فيهم يوصل p < 0.05، يبقى متوقع false positive واحد بالصدفة وبس. طبّق تصحيح زي Bonferroni (اقسم α على عدد الاختبارات) أو Benjamini-Hochberg لما تختبر metrics كتير.

الـ network effects والـ interference بيطلعوا لما المستخدمين يأثروا على بعض. لو مستخدمين الـ variant B عزموا صحابهم، والصحاب دول ممكن يكونوا في الـ control، يبقى المجموعتين مبقوش مستقلين. واختبار A/B القياسي بيفترض مفيش interference بين الوحدات — وده اسمه الـ Stable Unit Treatment Value Assumption (SUTVA). ولما الـ SUTVA تتكسر، بتلزم تصميمات cluster randomization أو holdout.

الـ sample ratio mismatch (SRM) بيحصل لما أحجام المجموعات اللي اتشافت تختلف بشكل واضح عن اللي كان متخطط. لو وزّعت 50-50 وطلعت في الآخر 47-53، يبقى فيه حاجة غلط في الـ randomization أو في الـ logging pipeline. اتأكد دايمًا من الـ SRM قبل ما تفسّر النتايج — ده علامة على عطل ممكن يخلّي أي نتيجة مالهاش معنى.

الـ sequential testing: الوقف بدري بأمان

أحيانًا بتبقى عايز تقف بدري — مثلًا، لو الـ variant بيعمل ضرر، أو لو التأثير كبير أوي لدرجة إنه باين خلاص. والحل هو الـ sequential testing (الاختبار التسلسلي)، واسمه كمان group sequential design.

الـ sequential test بيحدد من الأول جدول تحليلات مؤقتة وبيستخدم عتبات significance معدّلة عند كل بصّة. وأشهر طريقة هي حدود O’Brien-Fleming: عتبة الوقف بدري متحفظة جدًا (قيمة α صغيرة جدًا) في البصّات الأولانية، وبتخف لحد ما تقرب من الـ α الاسمية في البصّة النهائية المتخطط لها. وده بيتحكم في المعدل الكلي للـ false positives عند α بالظبط وفي نفس الوقت بيسمح بالوقف بدري لما الأدلة تبقى ساحقة.

والبديل هو الـ always-valid p-value من أبحاث الـ sequential testing، اللي بتفضل صالحة مهما كان وقت الوقف. والطرق دي بتسمح بالمتابعة المستمرة من غير ما تكبّر معدلات الـ false positives — أحسن الحالتين.

ليستة مراجعة اختبار A/B

1. التحديد المسبق — الفرضية والـ primary metric والـ sample size وخطة التحليل قبل الإطلاق.

2. الـ randomization بالمستخدم — التوزيع الثابت بيمنع التلوث جوه session المستخدم.

3. اتأكد من الـ SRM — اتأكد إن أحجام المجموعات ماشية مع التقسيم المقصود قبل ما تثق في أي نتيجة.

4. شغّل المدة كاملة — متقفش بدري إلا بـ sequential test وحدود متحددة من الأول.

5. قول الـ effect sizes والـ confidence intervals — مش بس “significant” أو “مش significant.”

6. صحّح للـ multiple comparisons — لما تختبر metrics أو variants كتير في نفس الوقت.

الدرس الجاي بيمدّ من التجارب المتحكم فيها للمشكلة الأصعب: الـ causal inference من البيانات الـ observational — تعمل إيه لما متقدرش تعمل randomization، وإزاي تقنيات زي الـ matching والـ propensity scores والـ difference-in-differences بتخلّيك توصل لاستنتاجات شبه التجريبية من البيانات المتاحة.

أهم النقط

اختبار A/B هو randomized controlled experimentation متطبّق على المنتجات الرقمية. اعمل randomization بالـ user ID، مش بالـ page view، عشان تضمن معاملة ثابتة.
حدّد من الأول الـ primary metric والـ sample size قبل الإطلاق. والـ minimum detectable effect لازم يعكس أصغر تغيير هيأثر فعلًا على قرار الإطلاق.
الـ two-proportion z-test (أو الـ chi-squared test) هو القياسي للـ binary metrics؛ والـ two-sample t-test للـ continuous metrics. وقول دايمًا الـ confidence intervals جنب الـ p-values.
اختبار A/B البايزي بيدّي جمل أقرب للبديهة عن احتمال إن الـ variant أحسن، وبيتعامل مع المتابعة المستمرة بشكل أطبع من الطرق الـ frequentist.
الـ peeking بيكبّر معدلات الـ false positives جامد. وطرق الـ sequential testing (O’Brien-Fleming، والـ always-valid p-values) بتسمح بتحليلات مؤقتة متخطط لها من غير ما تكبّر معدلات الخطأ.
اتأكد دايمًا من الـ sample ratio mismatch قبل ما تفسّر النتايج. الـ SRM بيشاور على عطل في الـ randomization أو الـ logging بيخلّي أي استنتاج مش موثوق.