Mở đầu — vì sao bài này quan trọng
Trong các bài trước, chúng ta đã coi A/B testing như "tiêu chuẩn vàng" để đo lường tác động của một thay đổi. Lý do A/B mạnh đến vậy nằm ở hai chữ: random assignment (phân bổ ngẫu nhiên). Khi bạn tung đồng xu để quyết định ai vào nhóm A, ai vào nhóm B, hai nhóm về mặt thống kê là "giống hệt nhau" ở mọi đặc điểm — kể cả những đặc điểm bạn không đo được. Bất kỳ chênh lệch nào ở kết quả cuối cùng đều có thể quy cho thay đổi mà bạn áp dụng. Đó là sức mạnh nhân quả (causal) của A/B.
Nhưng đây là sự thật mà nhiều Growth PM mới vào nghề không lường trước: trong rất nhiều tình huống thực tế, bạn KHÔNG thể chạy A/B test. Có thể vì lượng người dùng quá ít để đạt sample size. Có thể vì bạn không được phép random — ví dụ thay đổi giá theo luật phải áp dụng cho tất cả khách hàng cùng lúc. Có thể vì feature đã ship rồi cho 100% người dùng, giờ mới có ai đó hỏi "feature đó có thực sự tạo tác động không?". Có thể vì sự kiện cần đo là một thứ ngoài tầm kiểm soát của bạn — một đợt thay đổi thuật toán của Facebook, một quy định mới, một đối thủ rút khỏi thị trường.
Trong tất cả những tình huống đó, bạn không bó tay. Bạn dùng quasi-experiment (thử nghiệm bán thực nghiệm) — một bộ phương pháp cho phép bạn ước lượng tác động nhân quả mà KHÔNG cần random assignment. Một Growth PM giỏi không chỉ biết chạy A/B; họ biết khi nào A/B bất khả thi và biết "đồ nghề thay thế" nào để vẫn đưa ra quyết định dựa trên dữ liệu thay vì cảm tính. Bài này chính là về bộ đồ nghề đó.
Khái niệm cốt lõi
Quasi-experiment là gì?
Quasi-experiment là các phương pháp ước lượng tác động của một "can thiệp" (treatment) khi việc phân bổ ai nhận can thiệp không ngẫu nhiên. Vì không random, bạn phải dùng các kỹ thuật thống kê và thiết kế thông minh để "mô phỏng" nhóm đối chứng (control) mà lẽ ra A/B sẽ tạo ra cho bạn một cách tự nhiên.
Điểm mấu chốt cần hiểu: vấn đề lớn nhất khi không random là confounding (yếu tố gây nhiễu). Giả sử bạn thấy người dùng app của bạn ở Hà Nội mua hàng nhiều hơn người dùng ở Cần Thơ sau khi bạn ra mắt một tính năng. Có phải tính năng đó hiệu quả hơn ở Hà Nội? Hay đơn giản là người Hà Nội vốn có thu nhập trung bình cao hơn, hành vi mua sắm khác đi? Bạn không biết — vì hai nhóm vốn đã khác nhau từ đầu. Mọi kỹ thuật quasi-experiment đều sinh ra để giải quyết đúng vấn đề confounding này.
Khi nào dùng quasi-experiment?
Có ba nhóm tình huống điển hình:
1. Population không đủ lớn cho A/B. Nếu bạn là một startup B2B chỉ có 400 khách hàng doanh nghiệp, chia đôi ra mỗi nhóm 200 thì gần như không bao giờ đạt được statistical significance cho một thay đổi có effect size vừa phải. A/B đòi hỏi sample size, mà sample size bạn không có.
2. Treatment không thể random assign. Một số lý do phổ biến:
- Pháp lý: thay đổi điều khoản dịch vụ, thay đổi giá niêm yết thường phải áp dụng đồng loạt.
- Đạo đức: bạn không thể cố tình cho một nửa người dùng một trải nghiệm tệ hơn nếu nó gây hại thật.
- Kỹ thuật: một số thay đổi ở tầng hạ tầng (ví dụ chuyển CDN, đổi nhà cung cấp thanh toán) không thể bật cho 50% traffic.
- Network effects: nếu treatment lan từ người này sang người kia (mạng xã hội, marketplace), việc random ở cấp cá nhân làm "rò rỉ" tác động giữa hai nhóm — chủ đề này sẽ được đào sâu ở Bài 16.
Các phương pháp quasi-experiment chính
Bạn không cần là nhà thống kê để dùng được. Hãy nắm 4 công cụ phổ biến nhất, theo thứ tự dễ áp dụng:
a) Pre/Post (Before/After) — đo trước và sau. Đơn giản nhất: so sánh chỉ số trước khi ship và sau khi ship. Cảnh báo: đây là phương pháp yếu nhất vì không loại trừ được xu hướng tự nhiên (seasonality, tăng trưởng nền). Đừng bao giờ dùng pre/post một mình để kết luận nhân quả mạnh.
b) Difference-in-Differences (DiD) — khác biệt của khác biệt. Đây là "con ngựa thồ" của quasi-experiment. Bạn có một nhóm nhận treatment và một nhóm không nhận (dù không random). Bạn đo thay đổi của cả hai nhóm theo thời gian, rồi lấy "thay đổi của nhóm treatment" trừ "thay đổi của nhóm control". Phần chênh lệch còn lại chính là ước lượng tác động. Ý tưởng cốt lõi: dùng nhóm control để "trừ đi" xu hướng chung mà cả hai cùng chịu (như mùa vụ). Điều kiện then chốt: parallel trends — trước khi có treatment, hai nhóm phải biến động song song với nhau.
c) Regression Discontinuity (RDD) — gián đoạn hồi quy. Dùng khi có một "ngưỡng" quyết định ai nhận treatment. Ví dụ: khách hàng chi tiêu trên 5 triệu/tháng được vào hạng VIP với nhiều ưu đãi. So sánh khách hàng ngay-trên-ngưỡng (5,01 triệu) với khách hàng ngay-dưới-ngưỡng (4,99 triệu) — họ gần như giống hệt nhau, chỉ khác ở việc một bên được treatment. Chênh lệch kết quả tại ngưỡng chính là tác động.
d) Synthetic Control — nhóm đối chứng tổng hợp. Khi bạn chỉ có một đơn vị nhận treatment (ví dụ một thành phố, một thị trường), bạn "lắp ghép" nhiều đơn vị control thành một "bản sao tổng hợp" mô phỏng đơn vị treatment trước khi có can thiệp, rồi so sánh. Đây là kỹ thuật mạnh khi bạn làm geo-experiment ở quy mô thị trường.
Đánh đổi cần hiểu rõ
Quasi-experiment không miễn phí. Bạn đánh đổi độ chắc chắn nhân quả để lấy khả năng đo được khi A/B không thể. Kết quả quasi luôn kèm nhiều giả định (assumptions) hơn — và nếu giả định sai, kết luận sai. Vì vậy nguyên tắc của một Growth PM trưởng thành là: ưu tiên A/B khi có thể; chỉ rút quasi-experiment ra khi A/B thực sự bất khả thi; và luôn nói rõ giả định của mình khi trình bày.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán "feature đã ship" (DiD)
Giả định một bối cảnh sát thực tế: team Growth tại một sàn TMĐT lớn ở Việt Nam (tạm gọi là sàn S) đã ra mắt tính năng "giao nhanh 2 giờ" cho toàn bộ người dùng ở khu vực nội thành TP.HCM cách đây 2 tháng. Không ai set up A/B. Giờ ban lãnh đạo muốn biết: tính năng này có thực sự làm tăng tần suất đặt hàng không, hay chỉ là chi phí logistics đốt tiền?
PM không thể chạy A/B vì tính năng đã bật 100% ở TP.HCM. Cô dùng Difference-in-Differences:
- Nhóm treatment: người dùng nội thành TP.HCM (được giao nhanh 2 giờ).
- Nhóm control: người dùng nội thành Hà Nội (chưa được bật tính năng, hành vi mua sắm tương đồng).
- TP.HCM: tăng từ 2,4 lên 3,1 đơn/người/tháng (tăng 0,7).
- Hà Nội: tăng từ 2,3 lên 2,5 đơn/người/tháng (tăng 0,2 — đây là tăng trưởng nền do mùa vụ).
- DiD = 0,7 − 0,2 = 0,5 đơn/người/tháng quy cho tính năng giao nhanh.
Bài học rút ра: Khi feature đã ship, đừng so sánh "trước với sau" một cách ngây thơ. Luôn tìm một nhóm control "tự nhiên" để trừ đi xu hướng nền. DiD biến một tình huống tưởng như vô vọng thành một ước lượng nhân quả hợp lý.
Ví dụ 2 — Startup B2B SaaS với 350 khách hàng (RDD)
Một startup SaaS Đông Nam Á cung cấp phần mềm quản lý kho cho doanh nghiệp vừa và nhỏ. Họ chỉ có 350 khách hàng trả phí — quá ít cho A/B test có ý nghĩa. Họ muốn biết: gói "onboarding 1-1 có chuyên viên hỗ trợ" có làm tăng retention không?
Vấn đề: chính sách hiện tại là khách hàng ký hợp đồng từ 50 triệu/năm trở lên thì được onboarding 1-1 miễn phí; dưới ngưỡng thì tự onboard. Đây là một ngưỡng hoàn hảo cho Regression Discontinuity.
PM so sánh nhóm khách hàng có giá trị hợp đồng quanh ngưỡng 50 triệu (ví dụ 45–55 triệu). Những khách hàng ở 48 triệu và 52 triệu về bản chất rất giống nhau về quy mô và nhu cầu, chỉ khác ở chỗ một bên nhận onboarding 1-1, một bên không. Kết quả: retention 12 tháng của nhóm ngay trên ngưỡng là 78%, nhóm ngay dưới ngưỡng là 64% — chênh lệch 14 điểm phần trăm tại ngưỡng.
PM cẩn thận kiểm tra một rủi ro của RDD: liệu khách hàng có "cố tình" nâng hợp đồng lên đúng 50 triệu để được hỗ trợ không (gọi là manipulation quanh ngưỡng)? Cô vẽ phân bố giá trị hợp đồng, thấy không có "cục u" dồn ngay tại 50 triệu → ngưỡng không bị thao túng → RDD đáng tin.
Bài học rút ra: Khi sample quá nhỏ cho A/B nhưng tồn tại một quy tắc-ngưỡng trong cách bạn phân phối treatment, RDD cho bạn một cửa sổ nhân quả ngay tại ngưỡng đó. Đổi lại, kết luận chỉ áp dụng cho nhóm "quanh ngưỡng", không nhất thiết đúng cho khách hàng 200 triệu.
Ví dụ 3 — Ra mắt thị trường mới (Synthetic Control)
Một ứng dụng gọi xe khu vực Đông Nam Á tung một chiến dịch marketing lớn chỉ tại Đà Nẵng để test hiệu quả trước khi nhân rộng. Họ không thể A/B vì chiến dịch là billboard, radio, KOL địa phương — áp lên cả thành phố, không thể random từng người. Họ cũng chỉ có một đơn vị treatment: Đà Nẵng.
Team dùng Synthetic Control: lấy dữ liệu số chuyến xe/ngày của nhiều thành phố không chịu chiến dịch (Huế, Nha Trang, Vinh, Quy Nhơn...), rồi tìm tổ hợp trọng số sao cho "Đà Nẵng tổng hợp" khớp với Đà Nẵng thật trong 6 tháng trước chiến dịch. Ví dụ máy tính ra: Đà Nẵng tổng hợp = 40% Nha Trang + 35% Huế + 25% Quy Nhơn.
Sau chiến dịch, Đà Nẵng thật đạt 18.000 chuyến/ngày, trong khi "Đà Nẵng tổng hợp" (mô phỏng kịch bản không có chiến dịch) chỉ ở mức 15.500. Chênh lệch ~2.500 chuyến/ngày là tác động ước lượng của chiến dịch. Khi đặt cạnh chi phí chiến dịch, team tính được hiệu quả trên mỗi đồng chi tiêu và quyết định có nên nhân rộng sang Cần Thơ hay không.
Bài học rút ra: Với geo-experiment ở cấp thị trường và chỉ một đơn vị treatment, synthetic control cho bạn một "phản thực tế" (counterfactual) định lượng — câu trả lời cho "nếu không làm chiến dịch thì điều gì đã xảy ra?". Đây là điều mà pre/post đơn thuần không bao giờ trả lời được.
Hướng dẫn từng bước
Khi gặp một bài toán mà A/B không khả thi, hãy đi theo quy trình sau:
- Xác nhận A/B thực sự bất khả thi. Hỏi thẳng: lý do là sample size, ràng buộc random, hay feature đã ship? Đừng vội bỏ A/B — đôi khi bạn vẫn có thể random theo cụm (cluster), theo vùng địa lý, hoặc rollout dần (gradual rollout). Quasi chỉ là phương án khi đã loại trừ các khả năng này.
- Định nghĩa rõ treatment và thời điểm bắt đầu. Ai nhận can thiệp? Áp dụng từ ngày nào? Mốc thời gian rõ ràng là điều kiện bắt buộc cho hầu hết mọi phương pháp.
- Chọn phương pháp phù hợp với cấu trúc dữ liệu:
- Kiểm tra giả định cốt lõi của phương pháp đó. Với DiD là parallel trends; với RDD là không có thao túng quanh ngưỡng; với synthetic control là độ khớp tốt ở giai đoạn trước treatment. Đây là bước hay bị bỏ qua nhất và cũng nguy hiểm nhất.
- Ước lượng tác động và khoảng tin cậy. Đừng chỉ đưa một con số điểm; luôn kèm khoảng tin cậy hoặc ít nhất một đánh giá về độ chắc chắn.
- Chạy kiểm tra độ vững (robustness check). Thử đổi nhóm control khác xem kết quả có ổn định không. Thử "placebo test": giả vờ treatment xảy ra ở một thời điểm không có gì — nếu vẫn ra tác động "ảo", phương pháp của bạn đang có vấn đề.
- Trình bày kèm giả định. Khi báo cáo, nói rõ: "Đây là ước lượng quasi-experimental, dựa trên giả định X. Nếu giả định đúng, tác động là Y." Sự trung thực này giúp lãnh đạo cân nhắc đúng mức độ tin cậy.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng pre/post và gọi đó là nhân quả. Đây là lỗi phổ biến nhất. Bạn ship tính năng, doanh thu tăng 10%, bạn tuyên bố tính năng tạo ra 10%. Nhưng có thể đó là mùa cao điểm (Tết, sale 11.11), hoặc một chiến dịch marketing chạy song song. Luôn tìm cách trừ đi xu hướng nền bằng một nhóm control.
Lỗi 2 — Bỏ qua kiểm tra parallel trends trong DiD. DiD chỉ đúng nếu trước treatment hai nhóm đi song song. Nếu nhóm treatment vốn đã tăng nhanh hơn từ trước, DiD sẽ quy nhầm xu hướng sẵn có thành tác động. Luôn vẽ đồ thị giai đoạn pre-treatment trước khi tin con số.
Lỗi 3 — Chọn nhóm control quá khác biệt. So sánh người dùng TP.HCM với người dùng vùng nông thôn có hành vi rất khác là tự rước confounding. Chọn control càng giống treatment càng tốt về mọi mặt ngoài chính treatment.
Lỗi 4 — Quên hiệu ứng lan tỏa (spillover). Nếu nhóm treatment và control "nói chuyện" được với nhau (cùng một mạng xã hội, cùng một marketplace), treatment có thể rò rỉ sang control, làm loãng chênh lệch. Cân nhắc tách nhóm ở cấp cao hơn (theo thành phố, theo cụm).
Lỗi 5 — Trình bày quasi-result như thể nó chắc chắn bằng A/B. Không trung thực về độ tin cậy là cách nhanh nhất đánh mất uy tín khi kết quả sau này không lặp lại.
Mẹo:
- Khi có thể, hãy chạy A/A test giả lập trên dữ liệu lịch sử (placebo) để kiểm tra phương pháp trước.
- Kết hợp nhiều phương pháp: nếu DiD và synthetic control cùng cho hướng kết quả giống nhau, độ tin cậy tăng đáng kể.
- Lưu lại quy ước và giả định vào experiment archive (Bài 49) để team sau tham khảo.
- Nếu sắp ship một feature mà biết trước không thể A/B, hãy chuẩn bị nhóm control TRƯỚC khi ship — ví dụ giữ một vùng địa lý làm holdout. Đo lường tốt nhất luôn được thiết kế từ đầu, không phải chữa cháy về sau.
Bài tập thực hành
Bài 1 — Nhận diện phương pháp. Với mỗi tình huống dưới đây, chọn phương pháp quasi-experiment phù hợp và giải thích trong 2–3 câu vì sao A/B không khả thi:
- (a) Bạn tăng phí dịch vụ cho tất cả khách hàng từ 1/1, không thể random.
- (b) Khách hàng tích đủ 1.000 điểm thì được nâng hạng thành viên có nhiều ưu đãi.
- (c) Bạn chạy một chiến dịch OOH (quảng cáo ngoài trời) chỉ ở Hải Phòng.
- iOS: trước 1,2 triệu → sau 1,8 triệu.
- Android: trước 1,1 triệu → sau 1,3 triệu.
Bài 3 — Thiết kế chủ động. Team bạn sắp ship một chương trình loyalty mới cho toàn bộ người dùng và đã quyết KHÔNG chạy A/B vì lý do vận hành. Hãy đề xuất một thiết kế quasi-experiment để vẫn đo được tác động, nêu rõ: nhóm control bạn chọn, phương pháp, và một robustness check bạn sẽ làm.
Hãy viết câu trả lời ra giấy hoặc tài liệu trước khi đối chiếu với phần lý thuyết. Việc tự diễn đạt giả định bằng lời của mình là cách tốt nhất để nội hóa kiến thức này.
Tóm tắt
- A/B test là tiêu chuẩn vàng nhờ random assignment, nhưng có nhiều tình huống thực tế không thể chạy A/B: sample quá nhỏ, không được random (pháp lý/đạo đức/kỹ thuật/network effects), hoặc feature đã ship cho 100% người dùng.
- Quasi-experiment là bộ phương pháp ước lượng tác động nhân quả khi không có random assignment. Vấn đề trung tâm cần xử lý luôn là confounding.
- Bốn công cụ chính: Pre/Post (yếu nhất, đừng dùng một mình), Difference-in-Differences (con ngựa thồ — cần parallel trends), Regression Discontinuity (khi có ngưỡng quyết định treatment), và Synthetic Control (khi chỉ có một đơn vị treatment cấp thị trường).
- Mọi phương pháp quasi đều đánh đổi độ chắc chắn nhân quả lấy khả năng đo được. Vì vậy luôn: ưu tiên A/B khi có thể, kiểm tra kỹ giả định cốt lõi, chạy robustness/placebo check, và trình bày trung thực về độ tin cậy.
- Mẹo quan trọng nhất của một Growth PM trưởng thành: nếu biết trước không thể A/B, hãy thiết kế nhóm control từ trước khi ship thay vì chữa cháy bằng pre/post sau này.