Có nên A/B test? Kiểm tra thực tế lưu lượng

Phần lớn trang web nhỏ không thể A/B test, và chẳng ai nói với họ

Mọi hướng dẫn A/B test đều được viết bởi những công ty có hàng triệu lượt truy cập. Đội thử nghiệm của Microsoft, Google, Booking.com và Airbnb chạy hàng nghìn bài test mỗi năm, và lời khuyên của họ đúng với họ: test mọi thứ, tin vào dữ liệu, triển khai phiên bản thắng. Một startup với 8.000 lượt truy cập mỗi tháng đọc cùng lời khuyên đó, dựng cùng một dashboard, rồi không hiểu vì sao bài test nào cũng kết thúc ở độ tin cậy 87% với mức tăng co lại mỗi tuần. Họ không làm sai. Họ đang làm một việc không hoạt động ở quy mô đó.

Trang này làm phép tính mà các hướng dẫn bỏ qua. Với 8.000 lượt truy cập mỗi tháng và tỷ lệ chuyển đổi 3%, xác nhận mức tăng 10% cần khoảng 106.000 lượt truy cập: mười ba tháng toàn bộ lượt truy cập bạn có, trong khi trang phải giữ nguyên suốt thời gian đó. Trong bốn tuần, mức tăng nhỏ nhất bạn có thể xác nhận là khoảng 40%. Đó không phải là chuyện tinh chỉnh. Ronny Kohavi, người từng phụ trách thử nghiệm tại Microsoft và Airbnb, đặt ngưỡng thực tế để phát hiện mức tăng một chữ số ở vài trăm nghìn người dùng; dưới mức đó, theo ông, A/B test có thể là quá sớm và nghiên cứu người dùng là khoản đầu tư tốt hơn.

Chúng tôi viết điều này từ chính trải nghiệm của mình. Dashboard của Coddy từng chạy khoảng hai mươi thử nghiệm có tên, mười trong số đó là test giá trên từng quốc gia, mỗi bài chỉ trên một phần nhỏ lưu lượng, và báo "Tiếp tục chạy" mỗi khi độ tin cậy còn dưới 95%. Một số bài được đánh dấu thành công và đã triển khai. Nhìn lại bằng công cụ này, vài bài test trong số đó không thể nào phát hiện được mức tăng mà chúng được ghi nhận. Phiên bản trung thực của dashboard đó chính là trang này: lưu lượng này trả lời được câu hỏi gì, mất bao lâu, và phiên bản thắng là báo động giả thường xuyên đến mức nào?

Điều gì quyết định bạn có test được hay không

• Số lượt chuyển đổi mỗi tháng, chứ không phải số lượt truy cập, mới là con số giới hạn bạn. Một trang có 8.000 lượt truy cập ở mức 3% chỉ có 240 lượt chuyển đổi mỗi tháng để chia cho hai nhánh. Z-test cần hàng trăm lượt mỗi nhánh mới nói được điều gì.
• Mức tăng bạn sẽ hành động quyết định chi phí. Hãy thành thật: nếu bạn sẽ triển khai một thay đổi chỉ vì mức tăng 3%, bạn cần một bài test nhìn thấy được 3%, và gần như không trang web nhỏ nào làm được.
• Thời gian là chi phí, không phải lời giải. Một bài test kéo dài một quý sẽ đóng băng trang trong một quý, trải qua nhiều mùa và chiến dịch, và kết thúc trong một bối cảnh kinh doanh khác với lúc bắt đầu.
• Tần suất ý tưởng của bạn hiệu quả thay đổi ý nghĩa của một phiên bản thắng. Nếu cứ mười ý tưởng mới có một thật sự làm thay đổi chỉ số, thì ở độ tin cậy 95% và power 80%, hơn một phần ba số phiên bản thắng "có ý nghĩa thống kê" của bạn là báo động giả. Tỷ lệ cơ sở không phải chi tiết kỹ thuật; nó là phần lớn câu trả lời.
• Dưới ngưỡng đó có những phương pháp tốt hơn. Nói chuyện với năm người dùng, xem bản ghi phiên truy cập, triển khai thay đổi rồi so sánh trước và sau với biên sai số rộng, hoặc test trên một chỉ số nhiều khách chạm tới hơn, như một lượt nhấp thay vì một lượt mua.

Cách kiểm tra thực tế

1. 1

   Nhập số lượt truy cập mỗi tháng sẽ thấy bài test

   Không phải toàn bộ trang web. Nếu bài test nằm trên trang bảng giá, đó là lượt truy cập của trang bảng giá. Nếu đó là một bước thanh toán, đó là những người đi tới bước đó.

2. 2

   Nhập tỷ lệ chuyển đổi hiện tại của bước đó

   Công cụ hiển thị số lượt chuyển đổi mỗi tháng tương ứng, đó mới là ràng buộc thật sự.

3. 3

   Nêu mức tăng mà bạn sẽ hành động

   Mức tăng tương đối khiến bạn triển khai thay đổi. Hầu hết mọi người nói 10% và nghĩ đúng như vậy; hãy thành thật nếu con số của bạn nhỏ hơn.

4. 4

   Đọc kết luận và bậc thang

   Chạy nghĩa là dưới một tháng. Kéo dài nghĩa là dưới một quý, với trang bị giữ nguyên suốt thời gian đó. Dừng nghĩa là với lưu lượng của bạn, bài test không trả lời được câu hỏi. Bậc thang cho thấy các mức tăng lớn hơn sẽ tốn bao nhiêu.

5. 5

   Chọn tỷ lệ cơ sở và đọc rủi ro dương tính giả

   Chọn tần suất ý tưởng của bạn thật sự hiệu quả. Ô kết quả cho biết bao nhiêu phần kết quả có ý nghĩa thống kê sẽ là báo động giả ở tỷ lệ đó, con số cần nhớ vào lần tới một bài test chuyển xanh.

Số tháng để xác nhận mức tăng 10% ở độ tin cậy 95%, power 80%

Hai nhánh, mọi lượt truy cập đều vào bài test. Tìm hàng và cột của bạn.

Ba trang web, ba kết luận

Lỗi thường gặp khi test với ít lưu lượng

• Vẫn chạy test và đọc kết quả ở mức 85%. Độ tin cậy bạn đặt ra là lời hứa về tần suất bạn chấp nhận bị đánh lừa. Đọc dưới mức đó sau khi đã có kết quả cũng giống như chưa từng đặt ra nó.
• Test những thay đổi nhỏ xíu. Màu nút hay đổi vài chữ cùng lắm chỉ tạo ra mức tăng vài phần trăm, mà trang web nhỏ không thể phát hiện. Nếu nhất định phải test, hãy test thứ có khả năng làm con số thay đổi một phần ba.
• Test ở đáy phễu. Lượt mua thì hiếm; lượt nhấp thì nhiều. Một bài test trên lượt nhấp dẫn tới lượt mua có số sự kiện gấp mười lần và có thể kết thúc được.
• Để bài test chạy sáu tháng. Mùa vụ, chiến dịch và thay đổi sản phẩm đều len vào, và hai nhánh rốt cuộc đo hai thời kỳ khác nhau.
• Tin vào phiên bản thắng chỉ vì nó có ý nghĩa thống kê. Khi ý tưởng của bạn ít khi thật sự thắng, một kết quả có ý nghĩa thống kê thường là báo động giả nhiều hơn mức p-value gợi ý. Ô rủi ro dương tính giả cho bạn con số cụ thể.
• Coi "không có ý nghĩa thống kê" là "ý tưởng thất bại". Với lưu lượng thấp, gần như chẳng có gì có ý nghĩa thống kê. Ý tưởng có thể vẫn tốt; chỉ là bài test không nhìn thấy được.

Câu hỏi thường gặp về kiểm tra thực tế