Mở đầu — vì sao bài này quan trọng
Có một sự thật khó chịu mà mọi PM đều phải đối mặt: phần lớn ý tưởng "chắc chắn sẽ tốt" của chúng ta khi đưa lên thực tế lại không nhúc nhích kim đồng hồ, thậm chí làm metric tệ đi. Các đội sản phẩm trưởng thành như Booking.com, Microsoft hay Grab công khai rằng chỉ khoảng 1/3 thí nghiệm cho kết quả dương, 1/3 không có ý nghĩa, và 1/3 thực sự gây hại. Nếu bạn không đo, bạn sẽ ship cả nhóm thứ ba mà không hề hay biết — và đổ lỗi cho "thị trường" hay "mùa thấp điểm".
Đó là lý do Experiment Spec ra đời. Nó là tài liệu biến một câu nói cảm tính ("tôi nghĩ nút này nên to hơn") thành một phép thử có kỷ luật, có thể chứng minh đúng hoặc sai bằng số liệu. Trong khóa học này, bạn đã học cách viết Acceptance Criteria (Bài 21), Analytics Event Spec (Bài 36) để gắn sự kiện theo dõi, và sắp tới là Rollout Strategy (Bài 38). Experiment Spec nằm chính giữa: nó dùng các event bạn đã định nghĩa làm nguyên liệu đo, và quyết định liệu một thay đổi có xứng đáng được rollout hay không.
Bài này tập trung hẹp và sâu vào một việc: viết ra một spec để chạy A/B test cho đúng — từ giả thuyết, các biến thể, cách lấy mẫu, đến tiêu chí dừng. Tôi sẽ không bàn về counter-metrics tổng quát (Bài 15) hay rollout (Bài 38) ngoài phần giao thoa tối thiểu. Mục tiêu: sau bài này bạn cầm một feature bất kỳ là có thể viết được một Experiment Spec mà data scientist gật đầu, engineer hiểu phải gắn flag thế nào, và sếp tin được con số kết luận.
Khái niệm cốt lõi
A/B test (còn gọi là controlled experiment hoặc split test) là việc chia ngẫu nhiên người dùng thành hai (hoặc nhiều) nhóm, mỗi nhóm thấy một phiên bản khác nhau, rồi so sánh chỉ số giữa các nhóm. Vì việc chia là ngẫu nhiên, mọi khác biệt còn lại — tuổi, hành vi, thiết bị — được phân bố đều, nên chênh lệch metric cuối cùng có thể quy về đúng phần thay đổi bạn đưa vào. Đây là điểm khác biệt căn bản so với so sánh "trước và sau khi ship": so sánh trước-sau lẫn lộn rất nhiều yếu tố (mùa vụ, chiến dịch marketing, thay đổi đối thủ).
Một Experiment Spec tốt cần trả lời rành mạch các phần sau.
1. Hypothesis (Giả thuyết)
Giả thuyết là trái tim của spec. Công thức kinh điển:
> "Chúng tôi tin rằng [thay đổi X] sẽ làm [chỉ số Y] thay đổi [mức Z%], bởi vì [lý do/insight]."
Ví dụ: "Chúng tôi tin rằng hiển thị giá trước thuế ngay trên trang danh sách sẽ làm tỷ lệ thêm vào giỏ tăng 8%, vì khảo sát cho thấy 40% người dùng bỏ giỏ do bất ngờ với giá ở bước thanh toán."
Một giả thuyết tốt phải: (a) nêu rõ thay đổi cụ thể, (b) chỉ đúng một metric chính (primary metric), (c) có con số kỳ vọng để sau này biết test có đủ "power" hay không, và (d) có lý do dựa trên dữ liệu/insight chứ không phải linh cảm. Nếu bạn không viết được phần "bởi vì", rất có thể bạn đang đoán mò.
2. Variants (Các biến thể)
Mỗi thí nghiệm có một control (nhóm đối chứng — giữ nguyên trải nghiệm hiện tại) và một đến ba treatment (nhóm thử nghiệm — thấy thay đổi). Quy tắc vàng: mỗi biến thể chỉ khác control ở đúng một thứ bạn muốn đo. Nếu treatment vừa đổi màu nút vừa đổi text vừa đổi vị trí, mà metric tăng, bạn không biết cái nào tạo ra hiệu ứng.
Spec cần mô tả từng variant đủ rõ để engineer biết phải build gì sau feature flag: control là gì, treatment 1/2/3 khác nhau ra sao, và tỷ lệ phân bổ traffic (thường 50/50 cho 2 nhánh, hoặc 25/25/25/25 cho 4 nhánh). Đính kèm mock hoặc link Figma cho mỗi variant.
3. Sample (Mẫu)
Phần này gồm ba câu hỏi:
- Segment (đối tượng): Ai được vào thí nghiệm? Toàn bộ user, hay chỉ user mới, hay chỉ thị trường Việt Nam, hay chỉ người dùng iOS? Định nghĩa rõ targeting và exclusion (loại trừ ai — ví dụ loại nhân viên nội bộ, loại tài khoản test).
- Sample size & power: Cần bao nhiêu user mỗi nhánh để phát hiện được mức thay đổi Z% mà bạn kỳ vọng? Đây là phép tính dựa trên baseline hiện tại, Minimum Detectable Effect (MDE — hiệu ứng nhỏ nhất đáng phát hiện), mức tin cậy (thường 95%) và power (thường 80%). Metric càng "ồn", baseline càng nhỏ, MDE càng nhỏ thì cần càng nhiều mẫu.
- Duration (thời lượng): Suy ra từ sample size chia cho lưu lượng mỗi ngày. Nguyên tắc tối thiểu: chạy ít nhất 1–2 tuần đầy đủ để bao trọn chu kỳ tuần (hành vi cuối tuần khác ngày thường), tránh kết luận sớm vào thứ Ba khi thấy số đẹp.
4. Metrics: primary, secondary, guardrail
- Primary metric: đúng một chỉ số quyết định thắng/thua. Đây là chỉ số trong giả thuyết.
- Secondary metrics: các chỉ số phụ giúp giải thích "vì sao".
- Guardrail metrics: các chỉ số không được phép tệ đi dù primary có tăng (ví dụ: tốc độ tải trang, tỷ lệ lỗi, doanh thu tổng, tỷ lệ huỷ). Đây là điểm giao với Bài 15 — ở đây ta chỉ liệt kê chúng như một phần của spec thí nghiệm.
5. Decision rule (Quy tắc ra quyết định)
Viết TRƯỚC khi chạy: "Nếu primary tăng ≥ X% với p < 0.05 và không guardrail nào tệ đi quá Y%, ta rollout. Nếu kết quả không có ý nghĩa thống kê (flat), ta giữ control. Nếu guardrail vi phạm, dừng ngay." Viết quy tắc trước giúp tránh thiên kiến "tìm lý do để ship cái mình thích" sau khi nhìn số.
Tình huống thực tế
Ví dụ 1 — Tiki và nút "Mua ngay" trên trang sản phẩm
Bối cảnh: Một sàn TMĐT giả định mô phỏng Tiki muốn tăng tỷ lệ chuyển đổi từ trang sản phẩm. PM đề xuất thêm nút "Mua ngay" (mua thẳng, bỏ qua giỏ hàng) bên cạnh nút "Thêm vào giỏ".
Experiment Spec của họ viết:
- Hypothesis: Thêm nút "Mua ngay" sẽ làm tỷ lệ đặt hàng thành công từ trang sản phẩm tăng 5%, vì dữ liệu phễu cho thấy 22% user rời đi ở bước giỏ hàng.
- Variants: Control = chỉ nút "Thêm vào giỏ". Treatment = hai nút song song. Phân bổ 50/50.
- Sample: Toàn bộ user trên app Android & iOS tại Việt Nam, loại trừ seller và tài khoản nội bộ. Baseline conversion 3.2%, MDE 5% tương đối → tính ra cần ~180.000 user/nhánh → với 60.000 phiên xem sản phẩm/ngày, chạy 12 ngày (làm tròn 2 tuần).
- Primary: tỷ lệ đặt hàng thành công/phiên. Guardrail: giá trị đơn trung bình (AOV) không giảm quá 3%, tỷ lệ huỷ đơn không tăng.
Ví dụ 2 — Một fintech mô phỏng MoMo và onboarding KYC
Bối cảnh: Đội growth của một ví điện tử muốn rút ngắn luồng xác minh danh tính (KYC) từ 5 bước xuống 3 bước để tăng tỷ lệ hoàn tất.
Sai lầm ban đầu: PM định chạy test 3 ngày vì "traffic của tụi mình lớn lắm, đủ mẫu rồi". Data scientist phản đối, và spec được viết lại nghiêm túc:
- Hypothesis: Rút KYC còn 3 bước làm tỷ lệ hoàn tất KYC tăng 10%, vì 35% người bỏ ngang ở bước chụp 2 mặt giấy tờ.
- Sample & duration: Dù traffic lớn, hành vi KYC khác hẳn giữa ngày thường và cuối tuần (cuối tuần nhiều người rảnh hoàn tất hơn). Vì vậy bắt buộc chạy trọn 2 tuần để tránh "novelty effect" và lệch chu kỳ tuần.
- Guardrail: tỷ lệ hồ sơ KYC bị reject bởi đội compliance không được tăng — vì rút bước có thể làm chất lượng ảnh giảm, gây rủi ro pháp lý.
Ví dụ 3 — Grab và thử nghiệm thông báo đẩy giờ cao điểm
Bối cảnh: Một nền tảng gọi xe muốn tăng số chuyến đặt vào giờ cao điểm bằng cách gửi push notification gợi ý đặt sớm.
- Hypothesis: Push "Đặt trước, tránh tăng giá" làm số chuyến giờ cao điểm tăng 7%.
- Variants: 3 nhánh — Control (không push), Treatment A (push với nội dung lý tính về giá), Treatment B (push với nội dung khẩn cấp "Sắp hết tài xế gần bạn"). Phân bổ 34/33/33.
- Sample: chỉ user đã bật cho phép thông báo, tại TP.HCM và Hà Nội. Đây là một đối tượng đã được lọc — và spec ghi rõ kết luận chỉ áp dụng cho nhóm đã opt-in push, không suy rộng ra toàn bộ user.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn theo khi viết một Experiment Spec từ đầu.
- Bắt đầu từ một insight, không phải từ giải pháp. Trước khi viết "test nút màu cam", hãy hỏi: dữ liệu nào khiến tôi tin điều này đáng? Mở phễu (funnel) ra, tìm bước rò rỉ lớn nhất. Insight là phần "bởi vì" trong giả thuyết.
- Viết hypothesis theo công thức X–Y–Z. Một thay đổi, một primary metric, một con số kỳ vọng, một lý do. Nếu bạn muốn đo nhiều metric, hãy phân vai rõ: cái nào primary, cái nào secondary, cái nào guardrail.
- Thiết kế variants tối giản. Mỗi treatment khác control đúng một biến. Đính link mock cho từng nhánh. Quyết định số nhánh: càng nhiều nhánh càng cần nhiều mẫu (chia traffic nhỏ ra), nên đừng tham 5 nhánh nếu traffic mỏng.
- Định nghĩa segment và exclusion. Ai vào, ai ra. Luôn loại trừ tài khoản nội bộ, bot, tài khoản test. Ghi rõ targeting (thị trường, nền tảng, loại user).
- Tính sample size và suy ra duration. Dùng calculator (Evan Miller, Optimizely, hoặc tích hợp sẵn trong công cụ như GrowthBook, Statsig). Cần: baseline của primary, MDE, confidence 95%, power 80%. Lấy sample size chia traffic/ngày ra số ngày, rồi làm tròn lên bội số của 7 ngày và tối thiểu 1–2 tuần.
- Khai báo metric và cách đo. Primary, secondary, guardrail. Quan trọng: liên kết với các analytics event đã định nghĩa ở Bài 36 — nêu đúng tên event và thuộc tính dùng để tính mỗi metric. Nếu event chưa tồn tại, phải gắn trước khi chạy.
- Viết decision rule TRƯỚC khi chạy. Ngưỡng ý nghĩa, ngưỡng guardrail, và ba kịch bản: win → rollout, flat → giữ control, guardrail vi phạm → dừng. Cam kết không "peek-and-stop" (nhìn lén số rồi dừng sớm khi thấy đẹp), vì điều đó thổi phồng tỷ lệ dương giả.
- Ghi rủi ro và kế hoạch dừng khẩn cấp. Nếu guardrail (lỗi, crash, doanh thu) sụp, ai có quyền tắt flag, tắt trong bao lâu. Đây là cầu nối sang Bài 38 Rollout và Bài 39 Feature Flag.
- Cho review trước khi chạy. Ít nhất data scientist (xác nhận phép tính power) và engineer (xác nhận flag, event gắn đúng). Một spec chưa được review thường có lỗi ở sample size hoặc metric definition.
Lỗi thường gặp & mẹo
Peeking — nhìn lén và dừng sớm. Đây là lỗi phổ biến nhất. Bạn chạy test, ngày thứ 3 thấy treatment thắng p = 0.04, vội tuyên bố chiến thắng. Vấn đề: với phép kiểm định cổ điển, nếu bạn nhìn liên tục và dừng ngay khi thấy "có ý nghĩa", tỷ lệ dương giả có thể vọt từ 5% lên 20–30%. Mẹo: cố định duration trước, chỉ kết luận ở cuối; hoặc dùng phương pháp sequential testing/Bayesian nếu công cụ hỗ trợ.
Quên tính power, chạy underpowered test. Test thiếu mẫu cho ra kết quả "không ý nghĩa" và bạn kết luận sai rằng "tính năng vô dụng", trong khi thực ra nó có tác dụng nhưng test quá nhỏ để thấy. Luôn tính sample size trước; nếu không đủ traffic để đạt MDE hợp lý, hãy nâng MDE hoặc gộp test, đừng chạy bừa.
Đa metric không hiệu chỉnh. Nếu bạn nhìn 20 metric, theo xác suất sẽ có ~1 cái "có ý nghĩa" hoàn toàn do may rủi. Mẹo: cam kết một primary metric duy nhất trước khi chạy; các metric còn lại chỉ để tham khảo/giải thích, không dùng để tuyên bố thắng.
Bỏ qua novelty effect và chu kỳ tuần. Người dùng phản ứng với cái mới (bấm vì tò mò) rồi nguội dần. Test 3 ngày dễ bắt trúng đỉnh tò mò. Mẹo: tối thiểu một tuần đầy đủ, lý tưởng hai tuần, và xem xu hướng theo ngày chứ không chỉ con số tổng.
Sample Ratio Mismatch (SRM). Bạn định chia 50/50 nhưng thực tế lại 53/47. Đây là dấu hiệu hệ thống phân nhánh hoặc logging bị lỗi, và mọi kết luận đều không đáng tin. Mẹo: luôn kiểm tra tỷ lệ phân bổ thực tế ngay sau 1 ngày chạy.
Không loại trừ nội bộ/bot. Nhân viên test tính năng của chính mình sẽ làm nhiễu số liệu. Luôn có exclusion list.
Mẹo tổng quát: dùng một template Experiment Spec cố định cho cả đội (hypothesis → variants → sample → metrics → decision rule → risks). Khi mọi thí nghiệm cùng một khuôn, việc review nhanh hơn và các đội học được từ kho thí nghiệm cũ — kể cả những test thất bại, vốn là kiến thức quý giá nhất.
Bài tập thực hành
Chọn một tính năng nhỏ trong sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày) và viết một Experiment Spec hoàn chỉnh dài khoảng một trang, gồm đủ các phần sau:
- Hypothesis theo đúng công thức "Chúng tôi tin rằng [X] sẽ làm [Y] thay đổi [Z%], bởi vì [insight]". Phần "bởi vì" phải dựa trên một dữ liệu/quan sát cụ thể, không được là cảm tính.
- Variants: mô tả control và 1–2 treatment, mỗi cái khác control đúng một biến. Ghi tỷ lệ phân bổ traffic.
- Sample: segment + exclusion, ước lượng baseline của primary metric, chọn một MDE hợp lý, và nêu (ước chừng) sample size cùng duration. Bạn có thể dùng calculator của Evan Miller online để tính.
- Metrics: một primary, hai secondary, và ít nhất hai guardrail. Với mỗi metric, ghi sẽ đo bằng analytics event nào.
- Decision rule: ba kịch bản win / flat / guardrail-vi-phạm, kèm ngưỡng cụ thể.
Tóm tắt
Experiment Spec biến một ý tưởng cảm tính thành một phép thử có kỷ luật. Năm trụ cột cần nhớ: (1) Hypothesis theo công thức X–Y–Z có kèm lý do từ dữ liệu; (2) Variants với một control và 1–3 treatment, mỗi cái khác nhau đúng một biến; (3) Sample gồm segment, exclusion, sample size tính từ power, và duration tối thiểu 1–2 tuần bao trọn chu kỳ; (4) Metrics với một primary duy nhất, các secondary giải thích, và guardrail bảo vệ; (5) Decision rule viết trước khi chạy để chống thiên kiến.
Ba bài học từ thực tế: guardrail có thể chặn một primary "thắng" khỏi gây hại (Tiki/AOV, MoMo/compliance); đừng cắt duration vì "traffic lớn"; và khi có nhiều treatment, hãy đọc cả tác động dài hạn chứ không chỉ con số cao nhất (Grab/push). Tránh các bẫy kinh điển: peeking, underpowered test, đa metric không hiệu chỉnh, novelty effect và SRM. Một spec tốt là spec mà data scientist tin phép tính, engineer biết gắn gì, và bạn cam kết trước kết quả sẽ dẫn tới quyết định nào. Khi đã có kết quả đáng tin, bạn sẵn sàng bước sang Rollout Strategy — chủ đề của bài kế tiếp.