Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa tung ra một thử nghiệm A/B trên trang thanh toán của một sàn thương mại điện tử. Sau 3 ngày, biến thể B (nút "Đặt hàng" màu cam thay vì xanh) cho thấy tỷ lệ chuyển đổi cao hơn 8%. Bạn hào hứng báo cáo với sếp, đẩy biến thể B cho 100% người dùng, và... một tuần sau doanh số chẳng nhúc nhích, thậm chí còn giảm. Chuyện gì đã xảy ra?
Câu trả lời nằm ở một con số mà rất nhiều Growth PM bỏ qua: sample size — kích thước mẫu. Bạn đã kết luận quá sớm dựa trên một lượng dữ liệu quá nhỏ. Cái "8% tăng" kia chỉ là nhiễu ngẫu nhiên, giống như bạn tung đồng xu 10 lần ra 7 mặt ngửa rồi vội kết luận đồng xu bị lệch.
Đây là một trong những kỹ năng nền tảng nhất của nghề Growth PM, và tin tốt là: bạn không cần học cao về thống kê để làm đúng. Trong bài này, tôi sẽ dạy bạn cách ước lượng số người cần thiết cho một thử nghiệm — đủ đơn giản để bạn tính được trên giấy hoặc bằng một công cụ online, nhưng đủ chắc để bạn không bao giờ rơi vào cái bẫy "kết luận giả" ở trên nữa.
Lưu ý: Bài này chỉ tập trung vào cách tính sample size trước khi chạy thử nghiệm. Những khái niệm liên quan như p-value, ý nghĩa thống kê, hay lỗi Type I/Type II sẽ được giảng kỹ ở các bài sau. Ở đây, mục tiêu của chúng ta là trả lời đúng một câu hỏi: "Tôi cần bao nhiêu người, và chạy trong bao lâu, thì kết quả mới đáng tin?"
Khái niệm cốt lõi
Vì sao sample quá nhỏ lại nguy hiểm
Mọi dữ liệu đều có nhiễu (noise). Nếu hôm nay bạn đo tỷ lệ chuyển đổi của 50 người và mai đo 50 người khác, hai con số gần như chắc chắn sẽ khác nhau — không phải vì sản phẩm thay đổi, mà vì mỗi nhóm 50 người là một mẫu ngẫu nhiên khác nhau.
Sample size lớn giúp "trung bình hóa" nhiễu đó đi. Càng nhiều người, con số bạn đo càng tiệm cận sự thật. Với sample quá nhỏ, bạn rất dễ thấy một khác biệt "ảo" — một biến thể trông như thắng nhưng thực ra chỉ may mắn.
Nhưng sample quá lớn cũng lãng phí
Ở chiều ngược lại, nếu bạn đợi đến khi gom được nửa triệu người mới dám kết luận, bạn đang lãng phí thời gian và opportunity cost — chi phí cơ hội. Mỗi tuần thử nghiệm chạy thêm là một tuần bạn chưa thể tung tính năng thắng cho toàn bộ người dùng, hoặc chưa thể bắt đầu thử nghiệm tiếp theo. Với team Growth, tốc độ học hỏi (velocity) chính là lợi thế cạnh tranh.
Vậy nên mục tiêu không phải là "càng nhiều càng tốt", mà là vừa đủ — đủ để tin, không thừa để phí.
Bốn biến số quyết định sample size
Để tính sample size, bạn cần xác định bốn thứ. Tôi sẽ giải thích từng cái bằng ngôn ngữ đời thường:
1. Baseline conversion rate (tỷ lệ chuyển đổi hiện tại) Đây là con số bạn đang có. Ví dụ: trang đích hiện tại chuyển đổi 5% khách thành người đăng ký. Bạn lấy con số này từ dữ liệu thực tế trước khi chạy thử nghiệm.
2. Minimum Detectable Effect — MDE (mức cải thiện tối thiểu đáng phát hiện) Đây là biến số quan trọng nhất và hay bị hiểu sai nhất. MDE là câu hỏi: "Mức cải thiện nhỏ nhất mà tôi thực sự quan tâm là bao nhiêu?" Nếu bạn nói "tôi chỉ care nếu biến thể mới giúp tăng từ 5% lên ít nhất 5.5%" thì MDE của bạn là tăng tương đối 10% (từ 5% lên 5.5%).
Nguyên tắc vàng: MDE càng nhỏ, sample cần càng lớn. Phát hiện một thay đổi lớn (như tăng 50%) thì dễ, cần ít người. Phát hiện một thay đổi tí hon (như tăng 1%) thì khó như mò kim đáy bể, cần cực nhiều người.
3. Statistical power (độ mạnh thống kê) Đây là xác suất bạn phát hiện được một khác biệt thật, nếu nó thực sự tồn tại. Chuẩn ngành là 80%. Nghĩa là nếu biến thể mới thật sự tốt hơn, thử nghiệm của bạn có 80% cơ hội bắt được điều đó. Bạn hầu như luôn để mặc định 80% — không cần động đến.
4. Significance level (mức ý nghĩa) Thường ký hiệu là alpha, chuẩn ngành là 5% (hay 0.05). Đây là mức rủi ro bạn chấp nhận cho việc "báo động giả" — kết luận có khác biệt trong khi thực ra không có. Cũng để mặc định, gần như luôn là 5%.
Như vậy, trong bốn biến số, bạn chỉ thực sự phải suy nghĩ về hai cái đầu: tỷ lệ hiện tại (lấy từ dữ liệu) và MDE (do bạn quyết định). Hai cái sau cứ để mặc định 80% và 5%.
Công thức đơn giản để nhớ
Bạn không cần thuộc công thức đầy đủ, nhưng nên nắm một phiên bản rút gọn để có trực giác. Với hai nhóm so sánh, mỗi nhóm cần khoảng:
> n ≈ 16 × p × (1 − p) / (delta)²
Trong đó p là tỷ lệ baseline (dạng thập phân) và delta là mức tăng tuyệt đối bạn muốn phát hiện. Con số 16 là hằng số đã gói sẵn power 80% và significance 5%.
Ví dụ nhanh: baseline p = 0.05 (5%), bạn muốn phát hiện mức tăng tuyệt đối lên 6%, tức delta = 0.01. n ≈ 16 × 0.05 × 0.95 / (0.01)² = 16 × 0.0475 / 0.0001 = 7.600 người mỗi nhóm, tức 15.200 người tổng.
Nhìn vào công thức, bạn thấy ngay: delta nằm ở mẫu số và được bình phương. Nên nếu bạn muốn phát hiện khác biệt nhỏ hơn một nửa, sample không tăng gấp đôi mà tăng gấp bốn. Đây là trực giác quan trọng nhất của cả bài.
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "thắng sớm"
Một team Growth tại một sàn TMĐT lớn ở Việt Nam (tạm gọi theo mô hình Tiki) thử nghiệm thay đổi cách hiển thị nút "Mua ngay" trên trang sản phẩm. Baseline tỷ lệ click-to-cart là 12%. Trang sản phẩm có lưu lượng tốt, khoảng 40.000 lượt xem mỗi ngày, chia đều hai nhánh là 20.000 mỗi nhánh/ngày.
PM muốn phát hiện mức cải thiện tương đối 5%, tức từ 12% lên 12.6%, delta = 0.006. n ≈ 16 × 0.12 × 0.88 / (0.006)² = 16 × 0.1056 / 0.000036 ≈ 46.933 người mỗi nhóm.
Với 20.000 lượt mỗi nhánh/ngày, họ cần khoảng 46.933 / 20.000 ≈ 2.3 ngày chỉ để đủ mẫu. Nhưng vì có hiệu ứng cuối tuần (cuối tuần người mua khác ngày thường), nguyên tắc thực hành là luôn chạy tối thiểu trọn 1–2 tuần dù mẫu đã đủ sớm.
Bài học: Ban đầu PM định dừng sau 3 ngày vì "đã đủ 47k mỗi nhánh rồi". Nhưng nếu dừng vào thứ Tư, dữ liệu chỉ phản ánh hành vi ngày thường. Sample đủ về số lượng không có nghĩa là đủ về tính đại diện. Họ chạy trọn 2 tuần, và biến thể mới hóa ra chỉ tăng 1.2% — không vượt MDE, nên kết luận là "không đáng triển khai". Một quyết định đúng đã được cứu nhờ kiên nhẫn.
Ví dụ 2 — Một startup SaaS nhỏ và bài toán "không đủ traffic"
Một startup SaaS B2B ở TP.HCM có trang đăng ký dùng thử với baseline 3% chuyển đổi, nhưng chỉ có khoảng 500 lượt truy cập trang mỗi ngày (250 mỗi nhánh). Founder muốn thử một tiêu đề mới và kỳ vọng phát hiện mức tăng tương đối 15% (từ 3% lên 3.45%), delta = 0.0045.
n ≈ 16 × 0.03 × 0.97 / (0.0045)² = 16 × 0.0291 / 0.00002025 ≈ 22.992 người mỗi nhóm.
Với 250 lượt/nhánh/ngày, họ cần 22.992 / 250 ≈ 92 ngày, tức gần 3 tháng. Quá lâu để có thể chấp nhận.
Bài học: Đây là tình huống cực kỳ phổ biến với startup nhỏ ở Việt Nam — không đủ traffic để chạy A/B test "chuẩn sách giáo khoa". Có ba lựa chọn thực tế:
- Tăng MDE: Chỉ thử những thay đổi lớn (đại tu cả trang, không phải đổi màu nút), nhắm phát hiện mức tăng 30–50% thay vì 15%. Khi MDE lớn, sample cần nhỏ đi nhiều lần.
- Chọn metric "rộng" hơn: Đo ở phễu trên (như tỷ lệ click vào nút CTA, vốn có baseline cao hơn nhiều) thay vì metric cuối phễu hiếm xảy ra.
- Chấp nhận quyết định định tính: Khi A/B test bất khả thi, dựa vào phỏng vấn người dùng và phán đoán sản phẩm — sẽ học kỹ ở các bài về quasi-experiment sau.
Ví dụ 3 — Booking.com và logic "MDE nhỏ vì quy mô lớn"
Booking.com nổi tiếng chạy hàng nghìn thử nghiệm cùng lúc. Với lượng traffic khổng lồ (hàng triệu lượt/ngày), họ có thể đặt MDE cực nhỏ — phát hiện mức cải thiện chỉ 0.1%. Vì sao họ làm vậy? Vì ở quy mô doanh thu hàng tỷ đô, một cải thiện 0.1% trên tỷ lệ đặt phòng cũng tương đương hàng triệu đô mỗi năm.
Giả sử baseline đặt phòng là 4%, họ muốn phát hiện delta = 0.0004 (tăng tuyệt đối 0.04%): n ≈ 16 × 0.04 × 0.96 / (0.0004)² = 16 × 0.0384 / 0.00000016 ≈ 3.840.000 người mỗi nhóm.
Gần 4 triệu người mỗi nhánh! Con số khổng lồ này hoàn toàn ổn với Booking.com vì họ có traffic, nhưng sẽ là điều bất khả thi với 99% công ty khác.
Bài học: MDE bạn chọn phải khớp với quy mô traffic và giá trị kinh doanh của bạn. Đừng cố bắt chước MDE 0.1% của Booking.com khi bạn chỉ có vài nghìn người dùng — bạn sẽ chạy mãi không bao giờ đủ mẫu. Ngược lại, công ty lớn không nên đặt MDE thô (như 10%) vì họ sẽ bỏ lỡ vô số cải thiện nhỏ nhưng cộng dồn thành giá trị lớn.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn làm trước mỗi thử nghiệm, trước khi bấm nút "chạy":
Bước 1 — Lấy baseline từ dữ liệu thật. Đừng đoán. Mở công cụ analytics (Google Analytics, Mixpanel, Amplitude, hoặc dashboard nội bộ) và lấy tỷ lệ chuyển đổi hiện tại của đúng metric bạn sẽ đo. Lấy trung bình của ít nhất 2–4 tuần gần nhất để tránh nhiễu thời vụ.
Bước 2 — Quyết định MDE dựa trên giá trị kinh doanh. Tự hỏi: "Mức cải thiện nhỏ nhất nào đủ đáng để tôi bỏ công triển khai?" Nếu tăng dưới 5% chẳng đáng để đổi code, thì đặt MDE = 5%. Đừng đặt MDE quá nhỏ chỉ vì tham lam — nó sẽ làm sample phình to.
Bước 3 — Giữ mặc định power 80% và significance 5%. Trừ khi bạn có lý do đặc biệt, đừng động vào hai con số này.
Bước 4 — Dùng công cụ tính, đừng tính tay khi làm thật. Công thức rút gọn ở trên giúp bạn có trực giác, nhưng khi làm thật hãy dùng calculator online miễn phí: Evan Miller's "Sample Size Calculator", Optimizely Sample Size Calculator, hoặc tính năng có sẵn trong nền tảng thử nghiệm của bạn. Nhập 4 biến số, nó trả ra n mỗi nhóm.
Bước 5 — Đổi sample thành thời gian. Lấy n mỗi nhóm × 2 (vì có hai nhánh) chia cho lượng người vào thử nghiệm mỗi ngày → ra số ngày. Đây mới là con số sếp bạn quan tâm: "Test này chạy mất bao lâu?"
Bước 6 — Kiểm tra tính khả thi và làm tròn lên. Nếu ra 92 ngày như startup ở ví dụ 2, dừng lại và xem lại MDE hoặc metric. Nếu ra 2.3 ngày như Tiki, vẫn làm tròn lên tối thiểu 1–2 tuần để bao trọn chu kỳ tuần. Chốt thời gian trước khi chạy và cam kết không dừng giữa chừng.
Lỗi thường gặp & mẹo
Lỗi 1 — Không tính sample size trước khi chạy. Đây là lỗi số một. Nhiều PM cứ bật test lên rồi "nhìn dashboard mỗi sáng" chờ đến khi thấy biến thể nào đó thắng. Cách làm này gần như đảm bảo bạn sẽ kết luận sai. Hãy luôn tính trước và cam kết thời gian dừng.
Lỗi 2 — Nhầm lẫn MDE tương đối và tuyệt đối. "Tăng từ 5% lên 6%" có thể hiểu là tăng tuyệt đối 1 điểm phần trăm (delta = 0.01) hoặc tăng tương đối 20%. Hai cách hiểu cho ra sample rất khác nhau. Khi dùng calculator, đọc kỹ nó hỏi loại nào và nhập đúng.
Lỗi 3 — Đặt MDE quá nhỏ vì "muốn chắc ăn". Càng muốn phát hiện khác biệt nhỏ, sample càng phình to theo cấp số nhân (nhớ: delta bình phương ở mẫu số). Hãy thực dụng: chỉ nhắm tới mức cải thiện thực sự đáng quan tâm.
Lỗi 4 — Quên nhân đôi cho hai nhánh. Calculator thường trả về n mỗi nhóm. Tổng số người cần là gấp đôi. Nếu chia ba nhánh (A/B/C) thì cần gấp ba, và mỗi cặp so sánh vẫn cần đủ mẫu.
Lỗi 5 — Dừng ngay khi đủ mẫu mà bỏ qua chu kỳ tuần. Như ví dụ Tiki, đủ số lượng không bằng đủ tính đại diện. Luôn chạy trọn ít nhất một tuần, lý tưởng là hai, để bao trọn cả ngày thường lẫn cuối tuần.
Mẹo vàng: Khi traffic thấp, đừng cố ép A/B test "chuẩn". Hãy thử những thay đổi lớn để MDE lớn, hoặc đo metric ở phễu trên có baseline cao. Một baseline cao hơn cũng giúp giảm sample đáng kể.
Mẹo nhớ nhanh: Sample size tỉ lệ thuận với độ hiếm của sự kiện, và tỉ lệ nghịch với bình phương của MDE. Sự kiện càng hiếm và bạn càng muốn bắt khác biệt nhỏ — càng cần nhiều người.
Bài tập thực hành
Bài 1 — Tính cơ bản. Trang đăng ký của bạn có baseline 8%. Bạn muốn phát hiện mức tăng tuyệt đối lên 9% (delta = 0.01). Dùng công thức n ≈ 16 × p × (1−p) / delta² để tính sample mỗi nhóm. (Đáp án gợi ý: 16 × 0.08 × 0.92 / 0.0001 ≈ 11.776 người mỗi nhóm.)
Bài 2 — Đổi ra thời gian. Lấy kết quả Bài 1. Trang của bạn có 3.000 lượt mỗi ngày, chia đều hai nhánh. Hỏi: cần chạy bao nhiêu ngày để đủ mẫu? Sau đó làm tròn lên theo nguyên tắc chu kỳ tuần. (Gợi ý: 11.776 / 1.500 ≈ 7.85 ngày → làm tròn lên 14 ngày để trọn 2 tuần.)
Bài 3 — Cảm nhận hiệu ứng MDE. Vẫn baseline 8%, nhưng giờ bạn chỉ muốn phát hiện mức tăng nhỏ hơn một nửa: lên 8.5% (delta = 0.005). Tính lại sample và so sánh với Bài 1. Bạn sẽ thấy nó tăng khoảng bốn lần. Hãy tự rút ra kết luận về mối quan hệ giữa MDE và chi phí thử nghiệm.
Bài 4 — Tình huống thực tế của chính bạn. Lấy một sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày). Ước lượng baseline của một metric, đặt một MDE hợp lý, vào Evan Miller's Sample Size Calculator nhập 4 biến số, rồi đổi ra số ngày dựa trên traffic ước lượng. Viết một câu kết luận: "Test này có khả thi với traffic hiện tại không?"
Tóm tắt
Sample size là tấm vé bảo vệ bạn khỏi hai sai lầm đắt giá: kết luận quá sớm từ dữ liệu nhiễu, hoặc lãng phí thời gian chạy test dài vô ích. Những điều cần khắc cốt ghi tâm:
- Luôn tính sample size trước khi chạy và cam kết thời gian dừng — đừng "nhìn dashboard chờ thắng".
- Bốn biến số: baseline (lấy từ dữ liệu), MDE (bạn quyết định), power 80% và significance 5% (để mặc định). Thực tế bạn chỉ phải nghĩ về hai cái đầu.
- Trực giác cốt lõi: MDE càng nhỏ, sample tăng theo bình phương. Phát hiện khác biệt nhỏ hơn một nửa cần gấp bốn lần người.
- Đổi sample ra thời gian để giao tiếp với team, và luôn chạy trọn ít nhất 1–2 tuần để bao chu kỳ tuần.
- Traffic thấp? Đừng ép A/B test chuẩn — tăng MDE, chọn metric phễu trên, hoặc dùng phương pháp khác.