A/B Testing & Experimentation

Feature flag & A/B testing là gì?

Ngày xưa, muốn đưa một tính năng mới ra thị trường thì phải phát hành cả sản phẩm: đã ra là mọi người cùng thấy, và muốn gỡ thì phải phát hành lại lần nữa. Với ứng dụng di động, "lần nữa" đó có thể mất vài ngày chờ cửa hàng ứng dụng duyệt.

Feature flag (còn gọi là feature toggle) là một cái công tắc nằm sẵn trong sản phẩm đã phát hành. Mã của tính năng mới đã có ở đó, nhưng nó chỉ chạy khi công tắc được bật — và bạn bật cho ai là tuỳ bạn: 5% người dùng, riêng thị trường Việt Nam, riêng nhóm nhân viên nội bộ, hay toàn bộ. Tắt thì mất vài giây, không cần phát hành gì cả.

A/B test (experiment) dùng đúng cơ chế chia người dùng đó, nhưng với một ý định khác: giữ hai phiên bản chạy song song trong cùng khoảng thời gian, trên cùng loại người dùng, rồi so sánh chỉ số của hai nhóm để biết phiên bản nào tốt hơn.

Câu để nhớ: flag quyết định ai được thấy; experiment đo khác biệt. Mọi experiment đều chạy trên một flag, nhưng phần lớn flag không phải experiment.

Baseline — bạn hiểu

• Feature flag bật/tắt một tính năng theo thị trường, theo nhóm người dùng hoặc theo phần trăm — mà không cần phát hành bản mới.
• A/B test chạy hai phiên bản song song để so sánh, chứ không phải để "cho ra từ từ".
• Một tính năng đang bật cho 10% người dùng nghĩa là 90% còn lại không thấy nó — nên báo cáo lỗi, ảnh chụp màn hình và số liệu đều phải kèm theo thông tin người đó thuộc nhóm nào.

Working — bạn làm được

• Thiết kế được một kế hoạch mở dần: ai được thấy trước, điều gì cho phép mở rộng sang bậc tiếp theo, và điều gì buộc phải tắt ngay.
• Chọn đúng giữa mở dần và làm experiment thật, dựa trên câu hỏi mình đang cần trả lời.
• Ước lượng được một experiment phải chạy bao lâu mới đọc được kết quả — và dám nói "lưu lượng của mình không đủ để test cái này" khi đúng là như vậy.

Feature flag vs A/B test

Cùng một cơ chế kỹ thuật, hai ý định hoàn toàn khác nhau. Nhầm hai thứ này là nguyên nhân của phần lớn "experiment" không bao giờ kết luận được điều gì.

Dấu hiệu bạn đang nhầm: một "A/B test" mà tỷ lệ nhóm B tăng dần theo ngày thì không so sánh được, vì nhóm B của tuần này gồm cả người mới thêm vào hôm qua. Đó là một rollout đang bị gọi nhầm tên.

Ví dụ theo cấp độ

Cả ba ví dụ dùng chung một sản phẩm giả định: trang thanh toán có 40.000 lượt vào mỗi tháng (khoảng 1.330 lượt/ngày) và tỷ lệ hoàn tất nền là 4% — tức khoảng 1.600 đơn mỗi tháng.

Cơ bản — Bật cho 5% người dùng, có lỗi thì tắt ngay

Tình huống: đội phát triển vừa xong cách hiển thị phí vận chuyển mới. Thay vì bật cho tất cả, họ bật cho 5% người dùng — khoảng 2.000 lượt trong tháng, tức chừng 67 lượt mỗi ngày.

Điều đáng chú ý: sáng hôm sau có 4 ticket báo phí hiện sai với đơn giao liên tỉnh. Người quản lý tính năng tắt công tắc — vài giây, và 5% kia trở lại giao diện cũ ngay lập tức.

So sánh với cách không có công tắc: phải gỡ phần mã đó ra, phát hành lại. Với bản web là khoảng 30 phút chờ dựng và triển khai; với ứng dụng di động là 1–3 ngày chờ cửa hàng ứng dụng duyệt — trong lúc đó lỗi vẫn đang ở trên tay người dùng.

Học được: giá trị lớn nhất của feature flag không phải "cho ra từ từ" mà là rút lui nhanh. Đó là lý do câu hỏi "cái này có nằm sau một công tắc không?" nên có mặt trong mọi buổi rà soát trước phát hành.

Trung bình — Viết kế hoạch mở dần, kèm tiêu chí mở rộng và tiêu chí rút lại

Tình huống: tính năng đã sửa xong lỗi phí vận chuyển và cần mở ra toàn bộ. Ticket của bạn phải viết ra bốn thứ: các bậc, thời gian tối thiểu mỗi bậc, điều kiện để đi tiếp, và điều kiện để quay lại.

Tiêu chí để mở sang bậc tiếp theo (phải đúng cả ba):

• Tỷ lệ lỗi của nhóm đang bật không cao hơn mức nền 0,4%.
• Thời gian phản hồi p95 của trang thanh toán không tăng quá 20% so với trước.
• Không có ticket nào thuộc loại mất tiền hoặc sai số tiền.

Tiêu chí buộc tắt về 0% (chỉ cần một điều xảy ra):

• Tỷ lệ lỗi vượt 1%.
• Từ 3 ticket trở lên cùng một triệu chứng trong 24 giờ.
• Bất kỳ trường hợp nào tính sai số tiền, dù chỉ một đơn.

Điều phải nói thật với chính mình: 133 lượt ở bậc 5% đủ để phát hiện một lỗi lặp lại, nhưng không đủ để nói tỷ lệ hoàn tất tăng hay giảm 1%. Cổng rollout là cổng an toàn, không phải cổng đo hiệu quả. Ai đọc chênh lệch tỷ lệ hoàn tất ở bậc 5% rồi kết luận "tính năng mới tốt hơn" là đang đọc nhiễu.

Học được: một kế hoạch mở dần không có tiêu chí rút lại viết sẵn thì lúc có sự cố sẽ thành một cuộc tranh luận, giữa lúc đang cần hành động.

Nâng cao — Đổi giá: mở dần theo % hay làm một experiment thật?

Tình huống: ban lãnh đạo muốn tăng giá gói cơ bản từ 199.000 đ lên 219.000 đ (khoảng +10%). Câu hỏi được đặt ra là "A/B test đi, xem giá nào tốt hơn". Trước khi gật đầu, hãy tính thử.

Bước 1 — chênh lệch nào mới là chênh lệch đáng quan tâm? Doanh thu trên mỗi lượt vào trang thanh toán hiện tại là 4% × 199.000 = 7.960 đ. Với giá mới, cần tỷ lệ hoàn tất tối thiểu 7.960 ÷ 219.000 = 3,64% thì doanh thu mỗi lượt mới hoà. Nói cách khác, tỷ lệ hoàn tất được phép giảm tương đối khoảng 9% (từ 4% xuống 3,64%); giảm sâu hơn là lỗ.

Bước 2 — đo được chênh lệch đó cần bao nhiêu lưu lượng? Quy tắc ước lượng nhanh cho hai nhóm bằng nhau, với alpha 5% và power 80%: mỗi nhánh cần khoảng 16 × p × (1 − p) ÷ δ² lượt, trong đó p là tỷ lệ nền và δ là chênh lệch tuyệt đối muốn phát hiện.

• p = 0,04 → p × (1 − p) = 0,0384 → tử số 16 × 0,0384 = 0,6144.
• δ = 0,04 − 0,0364 = 0,0036 (0,36 điểm phần trăm).
• Mỗi nhánh cần 0,6144 ÷ 0,0036² ≈ 47.400 lượt → tổng khoảng 94.800 lượt.
• Với 40.000 lượt/tháng, đó là khoảng 2,4 tháng chạy liên tục.

Bước 3 — nếu chỉ có một tháng thì đọc được gì? Một tháng cho 20.000 lượt mỗi nhánh. Đảo ngược công thức: δ = căn bậc hai của (0,6144 ÷ 20.000) ≈ 0,0055 — tức 0,55 điểm phần trăm, tương đương giảm 13,9% tương đối. Nghĩa là sau một tháng bạn chỉ phân biệt được với số 0 khi tỷ lệ rơi xuống dưới 3,45%.

Kết luận rút ra từ chính ba con số trên: vùng cần quyết định (giảm 9%) nằm bên trong vùng mà một tháng không đọc được (13,9%). Chạy experiment một tháng gần như chắc chắn cho kết quả "không kết luận được" — đúng ở khoảng giá trị quan trọng nhất. Muốn có câu trả lời thì phải chấp nhận 2,4 tháng hiển thị hai mức giá khác nhau cho hai nhóm khách cùng lúc.

Vậy nên làm gì:

• Mở dần theo nhóm, không phải experiment: áp giá mới cho khách hàng mới trước, giữ giá cũ cho khách hiện hữu trong một thời gian đã công bố. Theo dõi doanh thu trên mỗi lượt, tỷ lệ huỷ và số ticket phàn nàn theo tuần. Đây là mở dần có kiểm soát, và nó tránh được chuyện hai người cạnh nhau thấy hai giá khác nhau ở cùng một thời điểm — một rủi ro về niềm tin và truyền thông mà con số thống kê không phản ánh.
• Đo bằng chỉ số đúng: câu hỏi về giá là câu hỏi về doanh thu trên mỗi lượt, không phải tỷ lệ hoàn tất. Lấy tỷ lệ hoàn tất làm chỉ số chính cho một thay đổi giá là chọn sai chỉ số ngay từ đầu — giá cao hơn thì tỷ lệ giảm là chuyện đương nhiên.
• Dùng experiment cho việc nó làm tốt: giữ A/B test cho những thay đổi mà bạn kỳ vọng tác động lớn hơn ngưỡng đọc được, và không mang theo vấn đề công bằng — cách trình bày phí, thứ tự các bước, câu chữ của nút bấm.

Học được: "A/B test đi" không phải lúc nào cũng là câu trả lời. Phép tính ba bước ở trên mất mười lăm phút và cho bạn quyền nói "với lưu lượng hiện tại, cách này không trả lời được câu hỏi đó" — kèm con số để chứng minh.

Áp dụng khi viết spec

Với mỗi tính năng đi sau một công tắc, ticket nên trả lời được:

1. Ai được thấy ở từng bậc? Theo phần trăm, theo thị trường, theo nhóm người dùng, hay theo tài khoản cụ thể?
2. Điều gì cho phép mở rộng? Ngưỡng cụ thể, không phải "thấy ổn thì mở".
3. Điều gì buộc rút lại, và ai được quyền bấm tắt? Cả ngoài giờ hành chính.
4. Người ở nhóm cũ và nhóm mới có gặp nhau không? Nếu hai người cùng nhìn một đơn hàng mà thấy hai giao diện khác nhau, hãy viết rõ điều đó có chấp nhận được không.
5. Bao giờ gỡ công tắc đi? Công tắc quên gỡ sẽ tích lại thành đường rẽ trong mã nguồn mà không ai còn nhớ tại sao có.
6. Nếu là experiment: chỉ số chính là gì, cần bao nhiêu lưu lượng, chạy tối thiểu bao lâu, và ai đọc kết quả?

Câu hỏi nên hỏi dev

• "Cái này có nằm sau một công tắc không, hay bật ra là toàn bộ người dùng thấy?"
• "Tắt công tắc thì bao lâu người dùng trở lại giao diện cũ — ngay lập tức hay phải chờ phiên đăng nhập mới?"
• "Việc chia nhóm dựa trên gì — tài khoản, thiết bị, hay phiên truy cập? Một người dùng có bị nhảy qua lại giữa hai phiên bản không?"
• "Số liệu của mình có tách được theo nhóm không? Nếu không thì chạy xong cũng không so sánh được."
• "Ai bấm tắt được, và ngoài giờ làm việc thì ai?"
• "Công tắc này khi nào gỡ đi?"

Sai lầm thường gặp

• Gọi một rollout là "A/B test" rồi cố đọc chênh lệch chỉ số từ hai nhóm có kích thước thay đổi mỗi ngày.
• Đọc kết quả ở bậc 5% và kết luận về hiệu quả, trong khi lượng dữ liệu ở đó chỉ đủ để phát hiện lỗi.
• Không viết tiêu chí rút lại, nên lúc có sự cố thì mất nửa tiếng tranh luận trước khi có người dám tắt.
• Số liệu không tách được theo nhóm — chạy xong không so sánh được gì, coi như mất luôn khoảng thời gian đó.
• Để công tắc nằm lại vĩnh viễn sau khi đã mở 100%, biến mã nguồn thành mê cung điều kiện.
• Quên rằng người dùng nói chuyện với nhau: nhóm được bật đăng ảnh chụp màn hình lên mạng xã hội, nhóm chưa được bật hỏi vì sao mình không có.
• Bắt đầu một experiment mà chưa ai tính xem cần bao nhiêu lưu lượng và bao nhiêu ngày.

Definition of done — dấu hiệu bạn đã đạt

• Bạn nói được tính năng nào trong khu vực của mình đang nằm sau công tắc và đang bật cho ai.
• Mọi tính năng có rủi ro do bạn spec đều có kế hoạch mở dần với tiêu chí mở rộng và tiêu chí rút lại viết sẵn.
• Bạn phân biệt được lúc nào cần một rollout, lúc nào cần một experiment, và nói được vì sao.
• Trước khi khởi động một experiment, bạn đã có con số ước lượng số ngày cần chạy — và sẵn sàng nói "không đủ lưu lượng" khi đúng như vậy.

Đi sâu hơn

• Event tracking — không có sự kiện tách được theo nhóm thì không có experiment nào đọc được.
• Product analytics — nơi bạn thật sự nhìn thấy kết quả của hai nhóm.
• Funnel & cohort analysis — đọc chênh lệch giữa hai nhóm mà không tự lừa mình.

Phần dưới đây là nội dung chuyên sâu của trang: nền tảng thống kê để đọc được kết quả experiment, mẫu kế hoạch experiment, và các tình huống thực tế.

Pillars của A/B test

1. Hypothesis — "Nếu X, thì metric Y sẽ thay đổi Z, vì lý do W."
2. Metrics — primary (decision), guardrail (don't break), secondary (insight).
3. Sample size + MDE — tính power, alpha, MDE trước khi launch.
4. Randomization unit — user, session, account.
5. Analysis — segment, novelty effect, interaction.

Statistical concepts

• Type I (false positive) — alpha thường set 5%.
• Type II (false negative) — beta 20%, power = 1-beta = 80%.
• MDE — minimum detectable effect bạn quan tâm.
• Sample size formula: phụ thuộc baseline conversion, MDE, alpha, power.
• Peeking — check kết quả nhiều lần inflate Type I → fix bằng sequential test hoặc đợi đủ sample.

Common pitfalls

• Test 1 tuần thấy "win" → ship → revert sau 1 tháng (novelty effect).
• SRM (Sample Ratio Mismatch) — 50/50 split thực ra là 53/47 → randomization broken.
• Multiple comparison — test 20 metric, 1 cái "significant" by chance.
• Test trên user mới mà extrapolate sang user cũ.

Khi nào KHÔNG nên A/B test

• Sample size không đủ (<1000 conversions/variant) — qual research tốt hơn.
• Quyết định strategic (vd: chuyển business model) — không thể test.
• Bug fix obvious — chỉ test nếu có risk break metric.

Vietnam context

MoMo, Shopee, Tiki đều có internal experimentation platform. PM cần: viết hypothesis tốt, đề xuất MDE thực tế (3–5% cho mature product, 10%+ cho early), interpret p-value với segment.

Experiment plan template

Case study: pricing page CTA

Team tests “Start free trial” vs “Book demo”. Primary metric: qualified signup. Guardrail: sales-qualified lead quality. Result: free trial increases signup but lowers SQL quality for enterprise traffic. Decision: segment CTA by company size instead of global winner.

No-nos

• Peeking daily and stopping when result looks good.
• Testing tiny copy changes without enough traffic.
• Ignoring novelty effects and seasonality.
• Using conversion lift while support cost or churn gets worse.
• Calling inconclusive test a failure; it can still teach.