Skip to content

🎮 Experiment Lab — Thiết Kế & Phân Tích A/B Test!

Bạn vừa được bổ nhiệm làm Lead Experimentation Analyst tại TestLab Inc. 🧪 — công ty tư vấn A/B testing cho các startup và enterprise. Mỗi tuần, clients gửi đến experiment proposals và results: "Test này thiết kế đúng chưa? Kết quả có tin được không? Nên deploy hay giữ?" 5 tình huống, mỗi tình huống: đánh giá experiment design hoặc phân tích kết quả. Chọn đúng = XP. Chọn sai = client ship feature lỗi, mất revenue, hoặc bỏ lỡ opportunity! 🚨


🎯 Mục tiêu học tập

Sau khi hoàn thành game, bạn sẽ:

  1. Đánh giá experiment design — hypothesis, sample size, duration, randomization
  2. Phân tích kết quả test — p-value, CI, effect size, practical significance
  3. Phát hiện pitfalls — peeking, multiple testing, Simpson's Paradox, selection bias
  4. Ra quyết định — deploy, giữ, hoặc redesign experiment
  5. Tư duy end-to-end — từ hypothesis → analysis → decision

📜 Luật chơi

┌──────────────────────────────────────────────────────┐
│  BẠN = Lead Experimentation Analyst 🧪               │
│  CLIENTS = 5 companies cần tư vấn A/B testing         │
│  MỖI VÒNG = 1 tình huống experiment → 4 lựa chọn     │
│  CHỌN insight + action phù hợp nhất → = XP            │
│  MỤC TIÊU = Thu thập ≥ 85 XP để đạt hạng Gold 🥇     │
└──────────────────────────────────────────────────────┘

Cách tính điểm mỗi vòng:

Thành phầnXP
Trả lời đúng+16 XP (Vòng 1–2), +18 XP (Vòng 3–4), +20 XP (Vòng 5)
Trả lời sai+0 XP
Không dùng hint+2 XP bonus ⚡
Giải thích đúng lý do+3 XP bonus 🧠

Tổng XP tối đa: 16+16+18+18+20 = 88 XP (chưa tính bonus)

Nguyên tắc quan trọng:

  • 🧪 Experiment design quyết định quality — test sai thiết kế → kết quả vô nghĩa
  • 📊 Statistical significance ≠ practical significance — p < 0.05 chưa đủ để deploy
  • 🚨 Peeking, multiple testing, selection bias — 3 kẻ thù lớn nhất của A/B test

🏆 Bảng xếp hạng & Huy hiệu

Ranks

HạngXPMô tả
🥇 Gold — Experiment Master≥ 85 XPBạn thiết kế experiment như Netflix, phân tích như Bing!
🥈 Silver — Experiment Apprentice≥ 60 XPTốt! Cần luyện thêm — đọc lại pitfalls section.
🥉 Bronze — Test Beginner≥ 35 XPHiểu cơ bản nhưng còn nhiều lỗ hổng — ôn lại Buổi 15.
💀 Game Over< 35 XPClient mất tiền vì ship feature sai — quay lại học toàn bộ!

Huy hiệu đặc biệt

BadgeĐiều kiệnMô tả
🧪 Design ExpertĐúng Vòng 1 + Vòng 2Master experiment design!
📊 Analysis ProĐúng Vòng 3 + Vòng 4Statistical analysis on point!
🛡️ Pitfall DetectorĐúng vòng có pitfall (Vòng 2, 4, 5)Phát hiện cạm bẫy trước khi mắc!
🔥 Full Streak5 vòng liên tiếp đúngPerfect experiment judgment!
🏆 Perfect ScoreĐúng tất cả 5 vòngExperiment legend!
💡 No Hints HeroKhông dùng hint cả gamePure experimentation intuition!

🎲 Chỉ số theo dõi

┌─────────────────────────────┐
│  🧪 SCOREBOARD              │
│  ─────────────────────────  │
│  XP hiện tại:    ___/88     │
│  Vòng hiện tại:  ___/5      │
│  Streak:         ___        │
│  Hints used:     ___        │
│  Design W/L:     ___        │
│  Analysis W/L:   ___        │
│  Hạng dự kiến:   ___        │
└─────────────────────────────┘

🎮 BẮT ĐẦU GAME!


🔵 VÒNG 1: "Sample size bao nhiêu là đủ?" (+16 XP)

🏷️ Category: Experiment Design

Tình huống:

PM tại ShopVN — e-commerce platform, 50,000 daily visitors — muốn A/B test checkout page mới (simplified 2-step vs current 4-step). Current checkout CVR = 8%. PM muốn detect ít nhất 5% relative lift (tức CVR target = 8.4%).

PM hỏi bạn: "Bao nhiêu sample là đủ? Traffic mỗi ngày 50K nên chạy 2 ngày là xong đúng không?"

Bạn tính:

ParameterValue
Baseline CVR8%
MDE5% relative → CVR target 8.4%
α0.05
Power80%
Calculated n/group~47,000
Total needed~94,000
Daily traffic50,000

4 lựa chọn:

RecommendationLogic
A"50K/ngày × 2 ngày = 100K > 94K. Chạy 2 ngày là đủ sample!"Quick math, hit sample threshold
B"Sample size ~94K → cần ≥ 2 ngày. NHƯNG phải chạy tối thiểu 7-14 ngày để cover full business cycle (weekday + weekend behavior khác nhau). Recommend 14 ngày, giảm traffic allocation nếu cần."Duration > sample size alone
C"5% MDE quá nhỏ, cần quá nhiều sample. Tăng MDE lên 20% để giảm sample size."Relax requirements
D"50K/ngày quá ít cho A/B test. Cần ít nhất 500K/ngày. Đợi platform grow."More traffic needed
💡 Hint (−2 XP)

Sample size chỉ là 1 condition. A/B test cần cover full business cycle — weekday vs weekend, đầu tháng vs cuối tháng. 2 ngày = chỉ cover 2 ngày trong tuần → biased. Duration ≥ 7 ngày (1 week minimum), ideally 14 ngày.

✅ Đáp án

B — Sample size ~94K đạt được trong 2 ngày, nhưng duration 2 ngày KHÔNG đủ. Lý do:

  1. Day-of-week effect: Shopping behavior thứ 7/CN ≠ thứ 2-6. Test 2 ngày chỉ cover 2 days → biased sample.
  2. Paycheck effect: Đầu tháng spending ≠ cuối tháng.
  3. Novelty effect: Users react differently to NEW design → cần time để normalize.

Correct approach: Run 14 ngày, allocate 50% traffic → 25,000/ngày × 14 = 350K total (far exceeds 94K minimum). Duration matters MORE than hitting sample threshold.

C là SAI vì 5% MDE là business requirement — PM cần detect 5% lift. Tăng MDE = bỏ qua improvement nhỏ nhưng có thể valuable.

Bài học: Sample size calculation tells you MINIMUM sample. Duration tells you MINIMUM time. BOTH must be met. Never run test shorter than 1 full business cycle.


🔵 VÒNG 2: "Kết quả A/B test — nên tin hay không?" (+16 XP)

🏷️ Category: Pitfall Detection — Peeking

Tình huống:

Growth Lead tại QuickChat — messaging app, 200K DAU — chạy A/B test notification frequency (3 notifications/day vs current 5/day). Hypothesis: giảm notification → giảm annoyance → tăng Day 7 retention.

Growth Lead gửi bạn email:

"Good news! Day 7, p-value = 0.04. Treatment (3 notifs) retention 52% vs Control (5 notifs) 49%. Statistically significant! Tôi muốn deploy ngay cuối tuần. Bạn approve?"

Bạn hỏi thêm và phát hiện:

DetailInformation
Planned duration21 ngày
Actual duration so far7 ngày
Planned sample size80,000/group
Current sample28,000/group
Times Growth Lead checked p-valueEvery day since Day 3
Day 3 p-value0.18
Day 5 p-value0.09
Day 7 p-value0.04

4 lựa chọn:

RecommendationLogic
A"p = 0.04 < 0.05, significant! Deploy ngay. Retention là long-term metric, càng deploy sớm càng tốt."Trust the p-value
B"🚨 Peeking alert! Growth Lead check p-value hàng ngày từ Day 3. p fluctuated 0.18 → 0.09 → 0.04. Với 5 peeks, false positive rate thực tế ~20%, không phải 5%. PHẢI chạy tiếp đến Day 21 như planned. Không deploy."Peeking invalidation
C"28K/group < 80K target. Cần thêm sample. Chạy thêm 7 ngày = 14 ngày total."Insufficient sample
D"Retention metric cần ít nhất 30 ngày. 7 ngày retention không reliable."Wrong metric timeframe
💡 Hint (−2 XP)

Growth Lead đã check p-value 5 lần (Day 3, 4, 5, 6, 7). Mỗi lần check = 1 hypothesis test. 5 checks ở α = 0.05 → actual false positive rate:

P(at least 1 false positive)=1(10.05)522.6%

p = 0.04 có thể là false positive. Đây là peeking problem — kẻ thù #1 của A/B testing.

✅ Đáp án

B — Peeking invalidation. Growth Lead peek 5 lần → false positive rate thực tế ~20-25%, không phải 5%. p = 0.04 có thể là noise.

Tại sao B đúng hơn C và D:

  • C (insufficient sample) đúng nhưng chưa identify root cause — vấn đề chính là PEEKING, không chỉ sample size
  • D (retention timeframe) hợp lý nhưng Day 7 retention là standard metric cho messaging apps — không phải vấn đề chính

Action:

  1. KHÔNG deploy
  2. Chạy tiếp đến Day 21 (planned duration)
  3. KHÔNG check p-value cho đến Day 21
  4. Day 21: analyze với full sample → quyết định

Bài học: Peeking = tung đồng xu nhiều lần rồi dừng khi mặt ngửa. Planned duration = commitment. Nếu cần check sớm → dùng Sequential Testing / Group Sequential Design với alpha spending function.


🟡 VÒNG 3: "Statistical significance nhưng nên deploy không?" (+18 XP)

🏷️ Category: Statistical vs Practical Significance

Tình huống:

Product Manager tại BookBuddy — reading app, 500K MAU — A/B test new recommendation algorithm. Test chạy đúng: pre-registered hypothesis, đúng sample size, 21-day duration, no peeking.

Results:

MetricControl (Old Algorithm)Treatment (New Algorithm)Liftp-value
Books Started/User/Month2.342.38+1.7%0.012
Books Finished/User/Month1.121.13+0.9%0.34
Reading Time/Day22.1 min22.3 min+0.9%0.28
App Opens/Day3.13.1+0.0%0.95
Engineering cost to maintain new algo+$8K/month server costs

PM nói: "Books Started significant ở p = 0.012! New algorithm phát hiện đúng sách users muốn đọc. Deploy!"

4 lựa chọn:

RecommendationLogic
A"p = 0.012 cho Books Started — deploy! Data doesn't lie."Trust statistical significance
B"Books Started +1.7% (0.04 books/user/month) nhưng Books Finished, Reading Time, App Opens đều KHÔNG significant. Effect size quá nhỏ (0.04 books ≈ 1 extra book per 25 users). Plus $8K/month extra cost. Practical impact gần bằng 0. KHÔNG deploy."Practical significance check
C"Deploy nhưng monitor 30 ngày. Nếu Books Finished tăng theo → keep."Conditional deploy
D"Sample size có thể chưa đủ cho Books Finished. Chạy tiếp thêm 21 ngày."More data needed
💡 Hint (−2 XP)

Primary metric (Books Started) significant ở p = 0.012 — nhưng effect size = +0.04 books/user/month (từ 2.34 → 2.38). Với 500K MAU = 20,000 extra books started/month. Downstream metrics (Finished, Reading Time, App Opens) đều KHÔNG improved. Plus $8K/month chi phí → ROI âm?

✅ Đáp án

B — Practical significance check. Analysis:

Statistical significance: ✅ p = 0.012 < 0.05. Improvement IS real statistically.

Practical significance: ❌

  • Effect: +0.04 books/user/month = 1 thêm book per 25 users/month → negligible
  • Downstream: Books Finished, Reading Time, App Opens → KHÔNG improve
  • User doesn't finish more books → "Started" tăng nhưng engagement KHÔNG tăng
  • Cost: $8K/month extra → $96K/year
  • Revenue impact: gần bằng 0 (users không read more, không pay more)

ROI = negative. $96K cost cho ~0 revenue uplift.

C (conditional deploy) là risky vì thêm $8K/month chi phí cho unclear benefit. D (more data) không giải quyết vấn đề — even with more data, effect size vẫn negligible.

Bài học: Statistical significance với large sample (500K MAU) có thể detect BẤT KỲ sự khác biệt nhỏ nào. "Significant" ≠ "Important." Luôn hỏi: "Impact = bao nhiêu $$? Bao nhiêu users thực sự affected?"


🟡 VÒNG 4: "Kết quả ngược khi segment" (+18 XP)

🏷️ Category: Simpson's Paradox

Tình huống:

Head of Growth tại FitTrack — fitness app, 300K MAU — A/B test new onboarding flow (video tutorial vs current text-based). Test chạy chuẩn, đủ sample, đủ duration.

Overall results:

MetricControl (Text)Treatment (Video)Liftp-value
Day 7 Retention34.2%36.8%+7.6%0.003
Sample size45,00045,000

Growth Head: "Video onboarding wins! +7.6% retention, p = 0.003. Ship it!"

Bạn segment analysis:

SegmentControl RetentionTreatment Retentionp-valueControl nTreatment n
iOS (60% traffic)38.0%37.5%0.5827,00027,000
Android (40% traffic)28.5%28.0%0.6418,00018,000

Chờ — BOTH segments cho Treatment THUA Control. Nhưng overall Treatment thắng?

4 lựa chọn:

Explanation + ActionLogic
A"Overall result significant — segment fluctuation là noise. Deploy Treatment."Trust overall
B"Simpson's Paradox! Treatment THUA trong cả iOS VÀ Android — nhưng thắng overall. Nguyên nhân: Treatment group nhận nhiều iOS users hơn (iOS retention tự nhiên cao hơn). Traffic split KHÔNG balanced by platform → confounded result. KHÔNG deploy. Investigate randomization."Simpson's Paradox detection
C"iOS và Android có behavior khác nhau. Deploy Treatment cho iOS, giữ Control cho Android."Segment-specific deploy
D"p-value cho segments > 0.05 vì sample nhỏ hơn. Chạy thêm data cho mỗi segment."Underpowered segments
💡 Hint (−2 XP)

Treatment THUA Control trong CẢ HAI segments (iOS: 37.5% < 38.0%, Android: 28.0% < 28.5%) nhưng THẮNG overall (36.8% > 34.2%). Đây là Simpson's Paradox — xảy ra khi confounding variable (platform mix) khác nhau giữa Control và Treatment. Check: Treatment có nhiều iOS users hơn → iOS retention cao hơn → pulls Treatment overall up.

✅ Đáp án

B — Simpson's Paradox. Let's verify bằng toán:

Control group:

  • iOS: 27,000 users × 38.0% = 10,260 retained
  • Android: 18,000 users × 28.5% = 5,130 retained
  • Total: 15,390 / 45,000 = 34.2%

Treatment group — nếu platform mix KHÁC:

  • Giả sử Treatment nhận 32,000 iOS + 13,000 Android (thay vì 27K/18K)
  • iOS: 32,000 × 37.5% = 12,000 retained
  • Android: 13,000 × 28.0% = 3,640 retained
  • Total: 15,640 / 45,000 = 34.8%

Nhưng report nói Treatment = 36.8% → platform mix trong Treatment group phải rất skewed toward iOS.

Root cause: Randomization BUG — Treatment nhận nhiều iOS users hơn. iOS users naturally có retention cao hơn → makes Treatment look better. Nhưng within EACH platform, Treatment actually WORSE.

Action:

  1. ❌ KHÔNG deploy
  2. Investigate randomization mechanism — SRM (Sample Ratio Mismatch) check by platform
  3. Fix randomization → re-run experiment
  4. Stratify by platform khi setup next test

C sai vì Treatment THUA Control trong CẢ HAI segments — không có segment nào Tretment tốt hơn.

Bài học: Luôn chạy segment analysis trước khi deploy. Overall result có thể bị confounded bởi unbalanced splits. Simpson's Paradox = average che giấu sự thật.


🔴 VÒNG 5: "3 variants, 5 metrics — claim 'significant'" (+20 XP)

🏷️ Category: Multiple Testing + Comprehensive Analysis

Tình huống:

Marketing Director tại FreshMeal — meal delivery app — chạy A/B/C test 3 variants email subject line. Test duration 14 ngày, 20K users mỗi variant. Marketing Director gửi bạn report:

"Amazing results! Chúng tôi test 3 subject lines và đo 5 metrics. Dưới đây là kết quả — rất nhiều significant results!"

MetricControl (A)Variant Bp (B vs A)Variant Cp (C vs A)
Open Rate22.0%24.1%0.03123.5%0.082
Click Rate4.2%4.5%0.1804.8%0.040
Purchase Rate1.8%2.0%0.2101.9%0.350
Unsubscribe Rate0.5%0.6%0.2800.4%0.150
Revenue/Email3,600 VND3,800 VND0.3204,100 VND0.048

Marketing Director: "B wins on Open Rate (p=0.031), C wins on Click Rate (p=0.040) AND Revenue/Email (p=0.048). I want to deploy C — 2 significant metrics!"

4 lựa chọn:

RecommendationLogic
A"C có 2 significant results — deploy C."Count significant metrics
B"B wins on Open Rate — deploy B. Open Rate là top-of-funnel, quan trọng nhất."Prioritize top-funnel
C"Multiple testing problem: 3 variants × 5 metrics = 10 comparisons (B vs A: 5, C vs A: 5). Bonferroni α = 0.05/10 = 0.005. KHÔNG CÓ metric nào p < 0.005. All 'significant' results có thể là false positive. Cần: (1) define 1 primary metric, (2) run focused A/B (2 variants, not 3), (3) recalculate sample size."Multiple testing correction
D"Purchase Rate — metric quan trọng nhất — KHÔNG significant cho cả B và C. Experiment fail. Giữ Control."Focus on business metric
💡 Hint (−2 XP)

Tổng số comparisons:

  • B vs A: 5 metrics = 5 tests
  • C vs A: 5 metrics = 5 tests
  • Tổng: 10 independent tests

Probability ít nhất 1 false positive: P=1(10.05)10=40.1%

40% chance ít nhất 1 metric "significant" chỉ vì chance! Bonferroni correction: α = 0.05/10 = 0.005. Metrics với p = 0.031, 0.040, 0.048 → all ABOVE 0.005 → not significant after correction.

✅ Đáp án

C — Multiple testing correction. Detailed analysis:

Problem 1: 10 comparisons without correction

So sánhp-valueα = 0.05α = 0.005 (Bonferroni)
B Open Rate0.031
B Click Rate0.180
B Purchase0.210
B Unsub0.280
B Revenue0.320
C Open Rate0.082
C Click Rate0.040
C Purchase0.350
C Unsub0.150
C Revenue0.048

After Bonferroni: 0 significant results. All 3 "significant" metrics are likely false positives.

Problem 2: No primary metric pre-defined Marketing Director đo 5 metrics và cherry-pick "significant" ones → HARKing/p-hacking behavior.

D cũng có logic (Purchase Rate not significant = experiment fail) nhưng C identify ROOT CAUSE (multiple testing) + đề xuất fix (define primary metric, fewer variants).

Recommended fix:

  1. Define 1 primary metric (Revenue/Email)
  2. Run A/B (2 variants — Control vs best candidate from exploratory)
  3. Calculate sample size cho 1 comparison, 1 metric
  4. Pre-register hypothesis
  5. No peeking, run full duration

Bài học: More variants × more metrics = exponentially more false positives. A/B testing = focused test: 1 change, 1 primary metric, 2 variants. Anything more = phải adjust for multiple testing.


🏁 KẾT QUẢ

Tính tổng XP

Vòng 1 (Sample Size + Duration):    ___/16 XP    (+ bonus hint ___/2 + lý do ___/3)
Vòng 2 (Peeking Detection):         ___/16 XP    (+ bonus hint ___/2 + lý do ___/3)
Vòng 3 (Stat vs Practical Sig):     ___/18 XP    (+ bonus hint ___/2 + lý do ___/3)
Vòng 4 (Simpson's Paradox):         ___/18 XP    (+ bonus hint ___/2 + lý do ___/3)
Vòng 5 (Multiple Testing):          ___/20 XP    (+ bonus hint ___/2 + lý do ___/3)
────────────────────────────────────────
TỔNG:   ___/88 XP    (max 113 XP with all bonuses)

Bảng xếp hạng cuối cùng

HạngXPMô tả
🥇 Gold — Experiment Master≥ 85 XPBạn thiết kế experiment như Netflix, phân tích như Microsoft Bing!
🥈 Silver — Experiment Apprentice≥ 60 XPTốt! Cần luyện thêm pitfalls — đọc lại Phần 4 Buổi 15.
🥉 Bronze — Test Beginner≥ 35 XPHiểu cơ bản nhưng dễ mắc bẫy — ôn lại toàn bộ Buổi 15.
💀 Game Over< 35 XPShip feature lỗi 3 lần — quay lại đọc toàn bộ Buổi 15!

📝 Tổng kết kiến thức

VòngCategoryĐáp ánBài học
1DesignDuration ≥ 1 business cycle, NOT just sample thresholdSample size + Duration BOTH must be met
2PitfallPeeking invalidates p-value → false positive rate 20-25%KHÔNG check p-value trước full duration
3AnalysisStatistical sig (p=0.012) nhưng effect negligible → KHÔNG deployLuôn check practical significance + ROI
4PitfallSimpson's Paradox — overall trend reverses in segmentsSegment analysis TRƯỚC khi deploy
5Pitfall10 comparisons × α=0.05 → 40% chance false positiveMultiple testing → Bonferroni correction

💡 Quy tắc vàng A/B Testing

  1. Design: Tính sample size + plan duration TRƯỚC khi chạy test
  2. Peeking: KHÔNG BAO GIỜ check p-value trước full duration
  3. Significance: Statistical significance ≠ practical significance — hỏi "impact = $$$?"
  4. Segments: Luôn segment analysis — overall average che giấu Simpson's Paradox
  5. Multiple testing: 1 primary metric, 2 variants. Nếu nhiều hơn → Bonferroni correction