Bối cảnh
Bài này ghép toàn bộ 7 bài trước vào một tình huống end-to-end như bạn gặp ở công ty. Mục tiêu: bạn thấy cả quy trình chảy mượt, biết dùng AI ở đúng điểm, và biết khi nào tin, khi nào nghi. Đây cũng là kịch bản bạn có thể mang thẳng vào chu kỳ thử nghiệm tiếp theo.
Tình huống: App giao đồ ăn
Bạn là PM của app giao đồ ăn. Team hỗ trợ báo nhiều khách bỏ giỏ hàng ở bước chọn phương thức thanh toán. Ý tưởng: thêm nút "Thanh toán 1 chạm" bằng ví điện tử đã lưu. Baseline: tỷ lệ hoàn tất đơn từ giỏ hàng là 60%. Traffic 5.000 đơn/ngày.
Bước 1 — Thiết kế (dùng logic bài 2-3)
Bạn là Trợ lý A/B Test. Thiết kế test từ thông tin sau, hỏi lại nếu thiếu:
- Sản phẩm: app giao đồ ăn, mục tiêu tăng đơn hoàn tất
- Vấn đề: rớt ở bước chọn thanh toán
- Ý tưởng: nút "Thanh toán 1 chạm" bằng ví đã lưu
- Baseline hoàn tất: 60%, traffic 5000 đơn/ngày
- MDE mong muốn: cải thiện tương đối 5% (60% -> 63%)
Xuất: giả thuyết, primary + guardrail, cỡ mẫu/nhánh (kèm công thức), thời lượng tròn tuần, test brief.
AI trả về: giả thuyết "Nếu thêm thanh toán 1 chạm, tỷ lệ hoàn tất tăng từ 60% lên 63% vì giảm ma sát bước cuối"; primary = tỷ lệ hoàn tất; guardrail = tỷ lệ khiếu nại thanh toán sai, tỷ lệ hoàn tiền; cỡ mẫu ~4.200/nhánh; thời lượng ~2 tuần.
Bước 2 — Chạy sạch (bài 4)
Bạn randomize theo user ID, chạy SRM check ngày 2 (tỷ lệ 50.2/49.8 — ổn), loại đơn test nội bộ. Không đọc kết quả trước ngày đã hẹn.
Bước 3 — Đọc & soi bẫy (bài 5-6)
Sau 2 tuần: Control 60.0%, Variant 63.8%, p=0.008, CI [+1.5%, +6.1%]. Guardrail khiếu nại: 1.2% → 1.3% (ổn). Bạn phân khúc theo hệ điều hành.
Soi kết quả này cho quyết định launch:
- Primary hoàn tất: Control 60.0% vs Variant 63.8%, p=0.008, CI [+1.5%, +6.1%]
- Guardrail khiếu nại thanh toán: 1.2% -> 1.3%
- Phân khúc: iOS +5%, Android chỉ +0.5%
- Đủ cỡ mẫu, chạy đủ 2 tuần, SRM ổn
Chỉ ra: primary có vững không? Có dấu hiệu Simpson hay hiệu ứng lệch phân khúc? Guardrail ổn chứ? Khuyến nghị launch/không/điều tra + 1 câu cho sếp.
AI chỉ ra: primary vững (CI không chứa 0, guardrail ổn), NHƯNG hiệu ứng gần như chỉ đến từ iOS; Android hầu như không cải thiện — có thể do ví điện tử phổ biến hơn trên iOS, hoặc lỗi UX trên Android. Khuyến nghị: launch cho iOS, điều tra Android trước khi mở rộng.
Các bước vận hành chuẩn
- Nhận vấn đề từ dữ liệu/hỗ trợ, không từ cảm tính.
- Dùng agent dựng giả thuyết + cỡ mẫu.
- Chốt test brief, cam kết ngày đọc kết quả.
- Chạy sạch: randomize đúng, SRM check, loại nhiễu.
- Đọc kết quả đúng hẹn, phân tích primary + guardrail + phân khúc.
- Soi bẫy peeking/multiple/Simpson bằng AI.
- Ra quyết định có điều kiện (ví dụ launch một phân khúc).
- Lưu lại kết quả và bài học vào kho tri thức thử nghiệm.
Template: Bản tóm tắt quyết định 1 trang
TEST: ______ NGÀY: ______ PM: ______
Giả thuyết:
Kết quả primary (+CI): | Guardrail:
Phát hiện theo phân khúc:
Bẫy đã kiểm tra: peeking / multiple / Simpson / SRM
QUYẾT ĐỊNH: launch toàn bộ / launch một phần / không / điều tra
LÝ DO (1-2 câu):
BÀI HỌC & bước tiếp theo:
Sai lầm thường gặp
- Launch toàn bộ khi hiệu quả chỉ ở 1 phân khúc: dễ gây hại cho nhóm không hưởng lợi. Quyết định có điều kiện.
- Bỏ qua điều tra khi phân khúc bất thường: chênh lệch iOS/Android là tín hiệu, không phải nhiễu bỏ qua được.
- AI tự tin thái quá (ảo giác + phụ thuộc): khi tình huống phức tạp, AI có thể đưa khuyến nghị dứt khoát nhưng thiếu căn cứ. Luôn hỏi "lý do KHÔNG nên launch là gì".
- Rò rỉ dữ liệu vận hành: đơn hàng thật chứa địa chỉ, SĐT khách. Chỉ đưa số liệu tổng hợp vào AI.
- Không lưu bài học: mỗi test là tài sản. Không ghi lại thì lần sau lặp lại sai lầm cũ.
- Coi kết quả 1 test là chân lý vĩnh viễn: hành vi người dùng đổi theo mùa/thị trường. Test lại định kỳ với quyết định quan trọng.