Sai lệch trong thí nghiệm thực tế
Bạn sẽ học được
- SRM là gì và cách phát hiện bằng số liệu.
- Hiệu ứng mới lạ và hiệu ứng thứ tự.
- Nhiễm bẩn giữa hai nhóm và lỗi đo lường.
- Ảnh hưởng của yếu tố mùa vụ và sự cố.
- Quy trình kiểm tra trước khi tin kết quả.
Khái niệm cốt lõi
Một thí nghiệm có thể đúng về công thức thống kê nhưng sai về dữ liệu. Bốn nhóm lỗi thực tế thường gặp:
| Nhóm | Dấu hiệu | Hậu quả |
|---|---|---|
| SRM (lệch phân bổ) | Hai nhóm không đúng tỷ lệ | Kết quả không đại diện |
| Mới lạ / thứ tự | Hiệu ứng giảm dần theo ngày | Kết luận quá lạc quan |
| Nhiễm bẩn | Nhóm này ảnh hưởng nhóm kia | Ước lượng bị kéo về 0 |
| Đo lường | Khác biệt do tracking, không do sản phẩm | Kết luận sai hoàn toàn |
Kiểm tra các dấu hiệu này trước khi đọc p-value.
SRM — sample ratio mismatch
Nếu thiết kế chia 50/50, mỗi nhóm phải nhận khoảng một nửa lưu lượng. Lệch đáng kể là dấu hiệu lỗi chia nhóm, lỗi ghi log, hoặc lọc dữ liệu không đối xứng.
Kiểm tra bằng chi-square một bậc tự do:
χ² = Σ (quan sát − kỳ vọng)² / kỳ vọngVới 10.000 người chia đôi, kỳ vọng 5.000 mỗi nhóm:
| Quan sát A / B | χ² | p | Đánh giá |
|---|---|---|---|
| 5.050 / 4.950 | 1,0 | 0,317 | Bình thường |
| 5.100 / 4.900 | 4,0 | 0,046 | Cần xem lại |
| 5.200 / 4.800 | 16,0 | < 0,001 | Lỗi nghiêm trọng |
Ngưỡng cảnh báo thường dùng p < 0,001 cho SRM vì kiểm tra này chạy nhiều lần. Khi SRM xảy ra, nguyên nhân phổ biến:
- Phân bổ dựa trên hash nhưng một nhóm bị lỗi hiển thị.
- Chỉ một phần người dùng được log (chặn quảng cáo, lỗi client).
- Lọc dữ liệu loại bỏ người dùng của một nhóm nhiều hơn.
- Bot hoặc tài khoản nội bộ lọt vào một nhóm.
Kiểm tra SRM theo từng ngày bằng SQL:
SELECT
date_trunc('day', exposed_at) AS ngay,
variant,
COUNT(DISTINCT user_id) AS n
FROM experiment_exposure
WHERE experiment = 'checkout-button'
GROUP BY 1, 2
ORDER BY 1, 2;Nhìn bảng: nếu tỷ lệ lệch từ một ngày cụ thể, nguyên nhân thường là thay đổi triển khai ngày đó, không phải ngẫu nhiên.
Hiệu ứng mới lạ và thứ tự
Người dùng thử tính năng mới vì nó mới. Hiệu ứng có thể dương trong tuần đầu rồi biến mất, hoặc âm lúc đầu do người dùng chưa quen rồi hồi phục.
Cách phát hiện: chia kết quả theo ngày hoặc tuần và xem xu hướng.
SELECT
date_trunc('week', exposed_at) AS tuan,
variant,
ROUND(100.0 * COUNT(DISTINCT converted_user) / COUNT(DISTINCT user_id), 2) AS pct
FROM experiment_exposure
GROUP BY 1, 2
ORDER BY 1, 2;Nếu chênh lệch lớn ở tuần 1 và thu hẹp về 0 ở tuần 3, kết quả trung bình cả kỳ không đại diện cho trạng thái ổn định. Kết luận nên dựa trên giai đoạn ổn định, hoặc báo cáo riêng từng tuần.
Nhiễm bẩn giữa hai nhóm
Hai nhóm không độc lập khi:
- Người dùng thấy cả hai phiên bản (chia theo phiên nhưng đo theo người).
- Một người trong nhóm B nói với người nhóm A (hiệu ứng mạng).
- Can thiệp thay đổi nguồn cung dùng chung (tồn kho, tài xế, bác sĩ).
- Thay đổi giá làm người mua chuyển giữa hai nhóm.
Hậu quả thường là hiệu ứng bị kéo về 0, khiến thí nghiệm "không thấy gì" dù thay đổi có tác dụng thật. Cách xử lý: chia theo cụm (thành phố, cửa hàng) hoặc dùng thiết kế switchback theo thời gian.
Lỗi đo lường
Khác biệt có thể đến từ cách đo, không từ sản phẩm:
- Sự kiện chuyển đổi được ghi ở hai thời điểm khác nhau cho hai nhóm.
- Bản B tải chậm nên một phần người dùng rời trước khi sự kiện được ghi.
- Chỉ số tính trên cửa sổ thời gian khác nhau.
- Bản B có thêm nút ghi nhận sự kiện không có ở bản A.
Cách kiểm tra: so sánh số sự kiện mỗi người dùng giữa hai nhóm. Nếu tỷ lệ sự kiện/người khác nhau bất thường ngay cả ở bước không liên quan đến thay đổi, nghi ngờ lỗi đo lường trước khi nghi ngờ hiệu ứng.
Mùa vụ và sự cố
- Mùa vụ: chạy trong dịp lễ, khuyến mãi lớn làm hành vi khác thường. Kết quả không đại diện cho ngày thường.
- Sự cố: lỗi hệ thống giữa kỳ tác động không đều hai nhóm. Phải ghi lại thời điểm và xem xét loại giai đoạn đó.
- Chiến dịch song song: email marketing, thông báo đẩy đến một nhóm người dùng nhiều hơn.
Luôn ghi lại sự kiện ngoài lề trong nhật ký thí nghiệm. Khi đọc kết quả, xem nhật ký trước khi kết luận.
Quy trình kiểm tra trước khi đọc kết quả
1. Tỷ lệ chia nhóm có đúng thiết kế không? (SRM)
2. Số người dùng mỗi nhóm có tăng đều không?
3. Chỉ số bảo vệ có vượt ngưỡng không?
4. Có sự kiện ngoài lề nào trong kỳ không?
5. Xu hướng theo tuần có ổn định không?
6. Sự kiện đo lường có nhất quán giữa hai nhóm không?Chỉ khi tất cả đều ổn mới đọc p-value và khoảng tin cậy. Nếu một mục lỗi, kết quả nên được đánh dấu "không dùng để quyết định".
Thực hành
- Tính χ² cho 5.080/4.920 trên tổng 10.000 và đánh giá.
- Viết truy vấn kiểm tra SRM theo ngày.
- Nêu ba cách can thiệp có thể gây nhiễm bẩn.
- Đề xuất cách phát hiện hiệu ứng mới lạ từ dữ liệu.
- Lập nhật ký thí nghiệm mẫu với một sự cố giả định.
Lỗi thường gặp
| Triệu chứng | Nguyên nhân | Cách sửa |
|---|---|---|
| Hai nhóm lệch 52/48 | SRM | Kiểm tra log chia nhóm và lọc dữ liệu |
| Hiệu ứng giảm dần | Hiệu ứng mới lạ | Đọc giai đoạn ổn định, báo cáo riêng |
| Kết quả gần 0 bất thường | Nhiễm bẩn | Chia theo cụm hoặc switchback |
| Số sự kiện/người khác nhau | Lỗi đo lường | Kiểm tra tracking trước khi kết luận |
| Kết quả đẹp trong tuần lễ | Mùa vụ | Chạy lại ở giai đoạn thường |
| Không biết vì sao dừng kỳ | Thiếu nhật ký | Ghi sự kiện ngoài lề ngay khi xảy ra |
Tóm tắt
- SRM là dấu hiệu sớm nhất của lỗi; kiểm tra trước mọi kết luận.
- Hiệu ứng mới lạ làm kết quả trung bình lạc quan.
- Nhiễm bẩn kéo hiệu ứng về 0; cần chia theo cụm.
- Lỗi đo lường tạo khác biệt giả; so sánh sự kiện/người.
- Ghi nhật ký sự cố và mùa vụ ngay trong lúc chạy.
Use ← → to move between lessons