CÔNG CỤ
A/B Testing
Dùng khi: hai phương án cãi nhau bằng ý kiến và có đủ traffic để cãi nhau bằng dữ liệu; cần chứng minh nhân quả ("thay đổi X gây ra kết quả Y") thay vì tương quan.
Cốt lõi: chia người dùng ngẫu nhiên thành nhóm A (giữ nguyên) và B (thay đổi), chỉ khác nhau một biến, đo cùng một chỉ số → khác biệt (nếu đủ ý nghĩa thống kê) là do thay đổi gây ra.
6 bước triển khai
- Giả thuyết rõ: "Đổi [X] sẽ tăng [chỉ số] vì [lý do]" — có "vì" mới học được kể cả khi thua.
- Chốt trước: chỉ số chính (một cái thôi), cỡ mẫu tối thiểu, thời gian chạy, ngưỡng kết luận. Chốt trước khi bấm nút.
- Tạo phiên bản + phân bổ ngẫu nhiên (kiểm tra hai nhóm cân nhau về đặc điểm).
- Chạy đủ thời gian định trước — kể cả khi "đã thấy thắng rồi".
- Phân tích: ý nghĩa thống kê + độ lớn tác động (significant nhưng +0.1% có đáng công build?); cắt theo segment xem có nhóm bị âm không.
- Quyết định: ship / bỏ / lặp với biến thể mới. Ghi lại kết quả kể cả khi thất bại — thư viện learnings là tài sản.
Ví dụ (course): ví điện tử test A/B/C/D các mức voucher giữ chân người dùng sắp rời bỏ — so tỷ lệ quay lại và chi phí mỗi người giữ được: bản voucher to nhất thắng về tỷ lệ nhưng thua về hiệu quả chi phí.
Bẫy thường gặp
- Dừng sớm khi thấy thắng — biến động ngẫu nhiên đầu test rất lớn; đó là cách tự lừa phổ biến nhất.
- Test nhiều thay đổi cùng lúc → thắng/thua không biết vì đâu (muốn test đa biến thì dùng multivariate, cần traffic lớn hơn nhiều).
- Traffic quá ít mà vẫn cố A/B → chạy 3 tháng không đủ mẫu; với sản phẩm ít user, dùng phỏng vấn + usability test thay thế.
- Chỉ nhìn chỉ số chính, bỏ qua guardrail metrics (tăng conversion nhưng tăng luôn hủy đơn/khiếu nại).
- Tối ưu cục bộ mãi nút bấm trong khi cả flow sai — A/B giỏi trả lời "cái nào tốt hơn", không trả lời "có nên làm cái này không".
Nguồn: Module 12 (6 bước, sai lầm, case newsletter + ví điện tử), Module 3 (A/B trong validation). Liên quan: Kiểm chứng giả định · Chỉ số tốt · Cohort Analysis · Growth team & thử nghiệm tốc độ cao