Trước khi chạy A/B test, tính một con số — với phần lớn website Việt Nam nó lớn hơn lưu lượng cả năm

Một tình huống quen thuộc: đội marketing đề xuất thử nghiệm hai phiên bản trang đích — đổi màu nút, sửa lại dòng tiêu đề — rồi chạy song song vài tuần xem bên nào chuyển đổi tốt hơn. Cách làm nghe rất hợp lý: thay vì cãi nhau, cứ để số liệu quyết định.

Trước khi dựng thử nghiệm, có một phép tính nên làm, mất khoảng một phút. Với phần lớn website doanh nghiệp Việt Nam, kết quả của phép tính đó là dừng lại.

Phép tính: cần bao nhiêu lượt truy cập

Thử nghiệm A/B là chia người truy cập thành hai nhóm, cho mỗi nhóm xem một phiên bản, rồi so tỷ lệ chuyển đổi. Vấn đề là tỷ lệ chuyển đổi luôn dao động ngẫu nhiên — hai phiên bản giống hệt nhau vẫn cho hai con số khác nhau. Để nói được rằng khác biệt quan sát được là thật chứ không phải may rủi, cần đủ số lượt.

Số lượt cần cho mỗi nhánh tính được bằng một công thức gọn:

• n ≈ 16 × p × (1 − p) / d², trong đó p là tỷ lệ chuyển đổi hiện tại và d là mức chênh tuyệt đối bạn muốn phát hiện.

Hằng số 16 đến từ hai lựa chọn tiêu chuẩn: chấp nhận 5% khả năng báo thắng nhầm, và muốn có 80% cơ hội phát hiện được khác biệt nếu nó thật sự tồn tại.

Lấy một website bán hàng với tỷ lệ chuyển đổi 2% — mức khá điển hình — và 500 khách mỗi ngày:

• Muốn phát hiện cải thiện 5% tương đối (2% lên 2,1%): cần khoảng 630.000 lượt, tức 1.259 ngày.
• Cải thiện 10% (2% lên 2,2%): khoảng 161.000 lượt, tức 322 ngày.
• Cải thiện 20% (2% lên 2,4%): khoảng 42.000 lượt, tức 84 ngày.
• Cải thiện 50% (2% lên 3%): khoảng 7.600 lượt, tức 15 ngày.

Điểm quan trọng nhất nằm ở hình dạng của dãy số này, không phải ở từng con số. Cỡ mẫu tỉ lệ nghịch với bình phương mức chênh: muốn phát hiện cải thiện nhỏ bằng một nửa thì cần lưu lượng gấp bốn. Đó là lý do khoảng cách giữa dòng đầu và dòng cuối là hơn tám mươi lần.

Hệ quả thực tế: thay đổi nhỏ không đo được ở quy mô nhỏ

Đổi màu một nút, sửa một dòng tiêu đề, dịch chuyển một ô nhập liệu — những thay đổi này, khi có tác dụng, thường nằm trong khoảng vài phần trăm. Bảng trên nói rằng ở mức 500 khách mỗi ngày, một thử nghiệm như vậy cần từ một tới ba năm mới kết luận được.

Điều này không có nghĩa những thay đổi ấy vô ích. Nó có nghĩa A/B test không phải công cụ để quyết định chúng. Chạy một thử nghiệm ba tuần rồi tuyên bố phiên bản B thắng là đang đọc nhiễu chứ không đọc tín hiệu — và tệ hơn, là đang tin vào kết quả đó.

Ở đây có một điểm thường bị bỏ qua: thử nghiệm thiếu cỡ mẫu không cho kết quả "chưa rõ", nó cho kết quả sai lệch theo một hướng có hệ thống. Khi lưu lượng quá nhỏ, những khác biệt duy nhất đủ lớn để vượt ngưỡng ý nghĩa thống kê là những dao động ngẫu nhiên lớn. Nên nếu bạn chỉ công bố những thử nghiệm "có kết quả", tập kết quả bạn thu được gần như toàn bộ là nhiễu được chọn lọc.

Cái bẫy thứ hai: ngó kết quả mỗi ngày

Phép tính trên còn giả định một điều mà gần như không ai làm đúng: chỉ đọc kết quả một lần, vào cuối.

Trên thực tế người ta mở bảng theo dõi mỗi sáng. Và khi thấy phiên bản B đang dẫn với mức chênh đạt ngưỡng, phản xạ tự nhiên là dừng lại, tuyên bố thắng, triển khai. Nghe hợp lý — sao phải chờ thêm khi đã có kết quả?

Vì mỗi lần nhìn là một lần cho phép ngẫu nhiên có cơ hội đánh lừa bạn. Ngưỡng 5% chỉ đúng cho một phép kiểm định. Nhìn hai mươi lần thì xác suất ít nhất một lần chạm ngưỡng do may rủi cao hơn nhiều.

Để có con số cụ thể thay vì nói chung chung, chúng tôi chạy một mô phỏng. Cách làm để bạn tự kiểm lại được: dựng hai nhánh giống hệt nhau, cùng tỷ lệ chuyển đổi thật là 2%, mỗi nhánh 250 lượt mỗi ngày trong 28 ngày, lặp lại 4.000 lần. Vì hai nhánh giống hệt nhau nên mọi kết luận "có khác biệt" đều là báo nhầm.

• Đọc kết quả một lần vào cuối: báo nhầm 4,2%.
• Đọc mỗi ngày từ ngày thứ bảy, dừng ngay khi chạm ngưỡng: báo nhầm 20,1%.

Con số 4,2% là dấu hiệu cho thấy mô phỏng chạy đúng — nó phải xấp xỉ mức danh nghĩa 5% đã chọn. Còn 20,1% nghĩa là một trong năm "chiến thắng" thu được theo cách này là ảo hoàn toàn, trên dữ liệu mà bản thân nó không chứa khác biệt nào.

Đáng chú ý là cả hai dòng dùng cùng một lượng dữ liệu và cùng 28 ngày. Khác biệt duy nhất là thói quen nhìn. Không cần thêm lưu lượng, không cần công cụ tốt hơn — chỉ cần không nhìn.

Vậy làm gì khi không đủ lưu lượng

Bốn hướng, xếp theo mức độ dễ làm.

Một: thử những thay đổi lớn hơn. Bảng ở trên cho thấy một cải thiện 50% đo được trong mười lăm ngày ở cùng mức lưu lượng. Thay vì đổi màu nút, hãy thử viết lại toàn bộ trang đích, đổi cách định giá, bỏ hẳn một bước trong luồng. Những thay đổi lớn vừa có cơ hội tạo khác biệt đủ lớn để đo được, vừa đáng để bỏ công hơn.

Hai: chuyển phép đo lên thượng nguồn. Nếu đơn hàng hoàn tất quá hiếm, hãy đo bước gần hơn với thay đổi vừa làm: lượt bấm nút, lượt mở trang chi tiết, lượt thêm vào giỏ. Những bước này thường có lưu lượng lớn hơn hàng chục lần nên đạt cỡ mẫu nhanh hơn nhiều. Cái giá phải trả là một giả định: cải thiện ở bước đó sẽ chảy xuống doanh thu. Giả định ấy không phải lúc nào cũng đúng — nên hãy viết nó ra thay vì lờ đi.

Ba: chốt ngày dừng trước, rồi không nhìn nữa. Đây là thứ rẻ nhất trong cả bốn: nó không tốn gì ngoài kỷ luật. Tính số lượt cần, quy ra ngày, ghi ngày đó vào lịch, và chỉ mở kết quả đúng hôm ấy. Nếu buộc phải theo dõi giữa chừng vì lý do vận hành, hãy chỉ nhìn số lượt đã thu được chứ đừng nhìn bên nào đang dẫn.

Bốn: với thay đổi nhỏ, quyết định bằng lập luận và gọi đúng tên. Chọn dựa trên lý do thiết kế, tính nhất quán với phần còn lại của sản phẩm, và phản hồi trực tiếp của người dùng. Rồi ghi lại rằng đây là một quyết định, không phải một kết quả đo. Nhầm hai thứ này chính là nguồn gốc của những bản báo cáo kết luận chắc nịch trên nền số liệu không chịu nổi một phép kiểm tra.

Khi nào A/B test thật sự đáng chạy

Nói cho công bằng, A/B test là công cụ tốt khi điều kiện cho phép. Ba dấu hiệu cho thấy bạn đang ở trong điều kiện đó:

• Lưu lượng đủ để phép tính ra một khoảng thời gian chấp nhận được — thường là vài nghìn lượt chuyển đổi mỗi tháng chứ không phải vài nghìn lượt truy cập.
• Thay đổi đủ lớn để kỳ vọng khác biệt hai chữ số phần trăm, hoặc bạn chấp nhận đo ở bước thượng nguồn.
• Có người chịu trách nhiệm giữ kỷ luật đọc kết quả, vì như mô phỏng ở trên cho thấy, đây mới là chỗ phần lớn thử nghiệm hỏng chứ không phải ở công cụ.

Nếu cả ba đều đúng thì chạy. Nếu không, những cách ở mục trước cho thông tin thật hơn — và rẻ hơn nhiều so với ba tuần chạy một thử nghiệm mà kết quả không nói lên điều gì.

Đây cũng là lý do chúng tôi viết riêng về việc một màn hình báo cáo chỉ sống khi có một quyết định đang chờ nó: cả hai trường hợp đều là cùng một sai lầm — dựng công cụ đo trước khi biết nó phục vụ quyết định nào.

Kết luận

Phép tính ở đầu bài mất một phút và nó trả lời được câu hỏi quan trọng nhất trước khi tiêu bất kỳ nguồn lực nào: thử nghiệm này có khả năng kết luận được gì không.

Với phần lớn website doanh nghiệp Việt Nam, câu trả lời cho những thay đổi nhỏ là không, và đó là số học chứ không phải ý kiến. Biết điều đó trước khi bắt đầu không phải là bi quan — nó giải phóng ba tuần để làm một thay đổi đủ lớn để đáng đo, hoặc để quyết định nhanh bằng lập luận rồi đi tiếp.

Cái bẫy thứ hai thì rẻ hơn nữa để tránh: chốt ngày dừng trước khi bắt đầu, rồi không nhìn. Chỉ riêng việc đó đưa tỷ lệ báo nhầm từ một phần năm về đúng mức bạn đã chọn, mà không cần thêm một lượt truy cập nào.

Nếu bạn muốn có người tính giúp cỡ mẫu cho một thử nghiệm cụ thể, hoặc dựng phần đo lường trước khi cần đến nó, liên hệ với chúng tôi hoặc xem năng lực Optimization Loop và Data Analytics của KonexForge.