DHDataHọc
TheoryLesson 5/86 min read+10 XP

Thiết kế A/B test

Bạn sẽ học được

  • Thiết kế một thử nghiệm A/B từ giả thuyết tới quyết định.
  • Tính cỡ mẫu cần thiết trước khi chạy.
  • Hiểu vì sao dừng sớm làm tăng xác suất sai.
  • Kiểm tra phân bổ mẫu (SRM) trước khi đọc kết quả.
  • Trình bày kết quả thử nghiệm trong phỏng vấn.

Khái niệm cốt lõi

A/B test là cách duy nhất để biết một thay đổi gây ra thay đổi về chỉ số, thay vì chỉ đi kèm. Trong phỏng vấn, câu hỏi thường gặp:

"Bạn muốn đổi màu nút mua hàng. Làm sao biết nó hiệu quả?"

Câu trả lời đầy đủ gồm sáu phần:

  1. Giả thuyết — thay đổi gì, kỳ vọng chỉ số nào tăng, vì sao.
  2. Đơn vị chia — theo người dùng, phiên, hay thiết bị.
  3. Chỉ số — một chỉ số chính, vài chỉ số bảo vệ.
  4. Cỡ mẫu và thời gian — tính trước, không dừng giữa chừng.
  5. Kiểm tra hợp lệ — SRM, tracking, nhiễu.
  6. Quyết định — ngưỡng thành công, hành động nếu thất bại.

Cỡ mẫu

Công thức xấp xỉ cho hai tỷ lệ:

code
n = (z_alpha/2 + z_beta)^2 × [p1(1−p1) + p2(1−p2)] / (p2 − p1)^2

Với mức tin cậy 95% (z = 1,96) và lực lượng 80% (z = 0,84):

  • Tỷ lệ nền 10%.
  • Muốn phát hiện mức tăng tương đối 10%, tức từ 10% lên 11%.
  • Hiệu số tuyệt đối 0,01.
code
n = (1,96 + 0,84)^2 × [0,10×0,90 + 0,11×0,89] / 0,01^2
  = 7,85 × [0,09 + 0,0979] / 0,0001
  = 7,85 × 0,1879 / 0,0001
  ≈ 14.750 người mỗi nhóm

Muốn phát hiện mức tăng chỉ 1% tương đối (10% lên 10,1%), cỡ mẫu tăng khoảng 100 lần — hơn một triệu người mỗi nhóm. Đây là lý do phải chọn mức tăng tối thiểu có ý nghĩa kinh doanh (MDE), không phải mức tăng nhỏ nhất có thể đo.

Trong phỏng vấn, nói được "em cần khoảng 15.000 mỗi nhóm, tức khoảng 2 tuần với lưu lượng hiện tại" tốt hơn nhiều so với "em chạy tới khi có ý nghĩa thống kê".

Vì sao không được dừng sớm

Nếu ngày nào cũng xem p-value và dừng khi p < 0,05, xác suất báo động giả tăng từ 5% lên có thể 20–30%. Mỗi lần "nhìn" là một lần có cơ hội rơi vào vùng ngẫu nhiên.

Dừng sớm không làm bạn biết sớm hơn. Nó làm bạn biết sai sớm hơn.

Cách xử lý đúng: chốt trước thời điểm kết thúc, hoặc dùng phương pháp tuần tự được thiết kế cho việc xem nhiều lần (sequential testing).

Kiểm tra SRM

Trước khi đọc kết quả, kiểm tra tỷ lệ chia có đúng thiết kế không. Giả sử dự kiến chia 50/50, tổng 24.400 người:

code
Kỳ vọng: 12.200 mỗi nhóm
Thực tế: A = 12.600, B = 11.800

Chi-square một bậc tự do:

code
χ² = (12.600 − 12.200)² / 12.200 + (11.800 − 12.200)² / 12.200
   = 160.000/12.200 + 160.000/12.200
   ≈ 26,2

Ngưỡng 3,84 ở mức 0,05. 26,2 lớn hơn rất nhiều, nên phân bổ sai có ý nghĩa. Khi có SRM, kết quả thử nghiệm không đáng tin — phải tìm nguyên nhân (lỗi gán nhóm, tracking mất sự kiện, bot) trước khi kết luận.

code
select
    variant,
    count(*) as n
from experiment_exposure
where experiment_id = 'nut_mua_hang'
group by 1;

Tính SRM bằng SQL đơn giản: so count với kỳ vọng theo tỷ lệ thiết kế.

Chỉ số

LoạiVí dụVai trò
ChínhTỷ lệ mua hàngQuyết định thành công
Bảo vệThời gian tải, tỷ lệ hoàn hàngKhông được xấu đi
PhụSố sản phẩm xem mỗi phiênGiải thích cơ chế

Chỉ số chính phải được chốt trước khi chạy. Chọn sau khi thấy dữ liệu là p-hacking.

Nếu thử nghiệm nhiều chỉ số, dùng hiệu chỉnh Bonferroni hoặc chấp nhận rằng một vài chỉ số sẽ "có ý nghĩa" do ngẫu nhiên. Với 20 chỉ số ở mức 0,05, kỳ vọng có 1 chỉ số dương tính giả.

Bẫy thường gặp

Hiệu ứng mới lạ. Người dùng thấy giao diện mới nên bấm nhiều hơn trong tuần đầu, sau đó quay lại bình thường. Chạy đủ ít nhất một chu kỳ sử dụng, thường 2–4 tuần.

Nhiễu giữa hai nhóm. Nếu hai nhóm chia sẻ cùng một tài khoản, cùng thiết bị, hoặc cùng mạng xã hội, kết quả bị pha. Chọn đơn vị chia phù hợp: người dùng cho sản phẩm tiêu dùng, cửa hàng cho thử nghiệm vận hành.

Không xét mùa vụ. Chạy thử nghiệm trong tuần khuyến mãi lớn rồi áp dụng quanh năm là sai.

Chọn chỉ số sau khi xem kết quả. Đây là dạng p-hacking phổ biến nhất. Chốt trước, ghi vào tài liệu thiết kế.

Kết luận từ p-value mà bỏ qua độ lớn. Chênh lệch 0,1% có ý nghĩa thống kê với mẫu 10 triệu người nhưng không đáng triển khai. Luôn báo cáo cả độ lớn và khoảng tin cậy.

Trình bày trong phỏng vấn

Một câu trả lời tốt trong 5 phút:

  1. "Giả thuyết: đổi nút sang màu cam làm tăng tỷ lệ mua từ 10% lên ít nhất 11%."
  2. "Chia ngẫu nhiên theo người dùng, 50/50, chạy 14 ngày."
  3. "Cần khoảng 15.000 người mỗi nhóm. Với 1.000 người mua mỗi ngày, chạy 30 ngày." — nói rõ lưu lượng thực tế quyết định thời gian.
  4. "Chỉ số chính là tỷ lệ mua; chỉ số bảo vệ là thời gian tải và tỷ lệ hoàn hàng."
  5. "Trước khi đọc kết quả, em kiểm tra SRM. Nếu phân bổ lệch, em dừng và điều tra."
  6. "Nếu tăng ít nhất 1 điểm phần trăm và chỉ số bảo vệ không xấu, em triển khai; nếu không, em phân tích theo phân khúc trước khi kết luận."

Nói được cả bước "nếu thất bại thì làm gì" thể hiện bạn nghĩ tới chi phí và học hỏi, không chỉ thắng thua.

Thực hành

  1. Tính cỡ mẫu cho tỷ lệ nền 5%, MDE +0,5 điểm phần trăm.
  2. Thiết kế thử nghiệm cho nút "thêm vào giỏ" từ giả thuyết tới quyết định.
  3. Cho số liệu 12.600 và 11.800, tính chi-square và kết luận.
  4. Giải thích trong 2 phút vì sao không nên xem p-value mỗi ngày.
  5. Nêu ba chỉ số bảo vệ cho tính năng gợi ý sản phẩm.

Lỗi thường gặp

Triệu chứngNguyên nhânCách sửa
Kết quả đẹp rồi biến mấtHiệu ứng mới lạChạy đủ chu kỳ, xem tuần 2–4
Hai nhóm lệch tỷ lệLỗi gán nhómKiểm tra SRM trước khi đọc
Nhiều chỉ số "có ý nghĩa"So sánh nhiều lầnChốt một chỉ số chính
Không lặp lại đượcChọn chỉ số sau khi xemGhi thiết kế trước khi chạy
Triển khai rồi doanh thu giảmBỏ qua chỉ số bảo vệĐặt ngưỡng cho chỉ số bảo vệ

Tóm tắt

  • Chốt giả thuyết, chỉ số, cỡ mẫu và thời gian trước khi chạy.
  • Cỡ mẫu tăng theo bình phương nghịch của MDE.
  • Không dừng sớm dựa trên p-value.
  • Kiểm tra SRM trước khi đọc kết quả.
  • Báo cáo cả độ lớn, khoảng tin cậy và hành động nếu thất bại.

Use ← → to move between lessons