Bỏ túi mang về: A/B Split test, rẻ, dễ, nhanh và ngắn hạn. Nhưng mấy bạn đã biết 6 sai lầm thường gặp khi set up A/B test này chưa?
Trong số các phương pháp thử nghiệm, chắc chắn mọi người đã từng nghe tới A/B testing. Truyền kỳ liệt truyện kể khi cái chợ toàn cầu Amazon chạy A/B testing để chọn ra phương án tốt hơn, kết quả tìm ra giải nhất chỉ chênh nhau có 1%. Mọi người sẽ nghĩ, 1% thì ăn thua gì, dùng cái nào chả được. Nhưng khi ta có lượng traffic với volumn cực lớn vài tỉ lượt truy cập chẳng hạn, thì 1% của nó đã là mấy chục triệu rồi.
Cùng với A/B testing, một cụm từ nữa mấy bạn hay nghe kèm là ‘conversion rate’, một chỉ tiêu (metric) rất phổ biến trong ecommerce. Conversion rate không phải lúc nào cũng có nghĩa là bán được hàng, là sale. Nó có thể là Trở thành thành viên, Đăng ký nhận thư, Download thông tin sản phẩm… tức là một kết quả, một hành động nào đó.
Do A/B testing được sử dụng rất phổ biến để tìm phương án ngắn hạn mang lại conversion rate cao hơn, A/B test và Conversion rate là cặp bạn thân tay trong tay.
Thông thường, dựa trên data đã thu thập được trước đó, bạn ĐÃ có nghi ngờ rằng, có chi tiết gì đó có thể thay đổi được, nên mới đưa ra (các) phương án thử nghiệm. Nghi ngờ trên đây rất quan trọng bởi nếu không có nghi vấn cụ thể thì chưa chắc A/B test đã là giải pháp. Để thiết lập A/B test, bạn thường đã có cột mốc, ”control group” 1 phiên bản thiết kế hiện đã chạy để có cái so sánh. Sau đó traffic được chia nhánh, một (hoặc một số) nhánh sẽ hiển thị các phương án muốn test.
Ví dụ kinh điển, với cùng một thiết kế giống nhau, phương án A để nút CTA (Call-to-action) ‘Đặt mua” ở bên phải màn hình. Và phương án B, nút này đặt ở dưới. Khi khách truy cập dịch vụ, 50% sẽ thấy phương án A, 50% thấy phương án B. (Bởi vậy nên kêu tên nó là Spit test đó đó) Những phiên bản thiết kế này chạy cùng lúc, sau khi gom đủ lượng dữ liệu (đủ lớn lớn chút) thì bạn sẽ có kết quả vị trí nào hiệu quả hơn.
Ví dụ khác: Nút bấm CTA dùng 2 labels khác nhau – xem cái nào được click nhiều hơn. 2 thông điệp khác nhau cho headline của page. Email marketing gửi đi dùng Emoji vs không dùng Emoji. 2 loại promotion offering khác nhau. Tức là những cái bé bé đó.
Những chi tiết dưới đây là điểm đặc trưng của A/B testing:
Ưu điểm
- Tốn ít công sức: A/B test là một phương pháp thử nghiệm chi phí thấp, không tốn kém mấy, cứ set up cho nó chạy, xong ngồi đợi kết quả mà thôi. (Không như Usability testing phải nào là workshop, strategy sampling, chọn người tham gia, lên plan, làm prototype vv và vv)
Có thể A/B test liên tục, không ngừng
- Kết quả thật, real time, cảm giác nó rất là đã. Chắc đọc tới đây các bạn cũng nhận ra rằng A/B test là thử nghiệm dùng sản phẩm đang hoạt động. Tức là test với người dùng thật, sản phẩm đã được xây dựng (hoặc gần xong), không giống như các phương pháp test với prototype. Nếu các bạn mới chỉ có bản thiết kế, chưa develop sản phẩm thì không thể dùng A/B testing được.
Testing bằng sản phẩm thật, với người dùng thật nó rất kỳ diệu, thuyết phục.
Hạn chế / Điểm cần lưu ý
- A/B split test chỉ nên được dùng với các thử nghiệm có mục đích cụ thể như ví dụ ở trên. Những mục đích này phải dễ dàng đo đếm được (quantitative data). Không dùng A/B test để thử nghiệm xem khách hàng hài lòng hơn, hay ấn tượng hơn với dịch vụ, hay sản phẩm (đây là Qualitative data rồi)
- Thứ hai là A/B test cho biết kết quả, chứ sẽ không cho biết vì sao người dùng chọn A, hay là B. Ai có giải thích kèm theo, thì biết là họ đang troll, hay bốc phét nha 😌
- Cho nên – Điều này là siêu phẩm quan trong nha – kết quả này có thể đúng ở thời điểm đó, chưa chắc đã đúng trong tương lai. Cũng như, kết quả đúng với bối cảnh này, chưa chắc đúng với bối cảnh khác.
- Tóm lại kết quả nó chỉ giới hạn trong bối cảnh của nghiên cứu đó mà thôi
- Vì chúng ta không biết nguồn cơn vì sao user thích B hơn là A, nên có khi chúng ta cũng không biết rằng, có phiên bản C lại còn hiệu quả hơn gấo mấy lần nữa.
6 sai lầm thường gặp với A/B testing
- A/B quá ngắn, quá ít. Ví dụ test sản phẩm có khách hàng chính là dân chuyên đi du lịch hè, nhưng lại chỉ chạy có 1 tuần, thì lượng dữ liệu thu thập được chưa đủ để đại diện. Lưu ý nhất là với những sản phẩm có tính ‘theo mùa’, theo thời điểm, thì thời gian test và thời lượng test nó phải đủ để bao trọn phần nào vòng phát triển sản phẩm.
- So sánh cam với táo. Hai giải pháp khác nhau hoàn toàn mà đem ra A/B testing thì khó có thể nói vì sao cái này tốt hơn cái kia được. Bạn chỉ có thể so sánh táo xanh với táo đỏ chẳng hạn. Hoặc táo có cuống, với không có cuống, kiểu kiểu vậy.
- Xác định mục tiêu cho thử nghiệm sai – Ví dụ như đi tìm câu trả lời cho các câu hỏi ‘Tại sao”. Trên đã nói rồi, A/B split test không thể đưa ra giải thích trăng sao gì được hết. Về chỗ.
- Dùng A/B test để đánh giá concept. Từ điểm số 3 ở trên. Khẳng định lại lần nữa không thể dùng A/B test để phán rằng concept này tốt hơn concept kia được. Concept là thứ rất high level. A/B chỉ test được 1 yếu tố trên thiết kế mô phỏng concept đó mà thôi.
- Dùng kết quả A/B test của thiết kế cũ, áp đặt lên thiết kế mới. Nếu bên team Author/Producer (xây dựng, bảo trì web/app trên CMS) có phán là Navigation bar phải đặt ở bên phải, chúng tôi đã test rồi. Trong khi bạn đang thiết kế LẠI cái trang đó, thì bạn cứ dũng cảm cãi lại nhé. Cái đó gọi là biết 1 mà không biết 2. Kết quả xưa đúng với thiết kế cũ, nhưng bạn đang đưa ra một thiết kế mới cơ mà. Tất nhiên sửa gáy nhau cũng nhẹ nhàng duyên dáng thôi mới được việc 😉
- Chỉ chạy A/B test mà không kết hợp với các phương pháp khác. A/B test phù hợp với các mục tiêu cụ thể, ngắn hạn. Để có hiệu quả lớn và lâu dài, không được quên các loại UX test khác nha các bạn ơi.
