Tối ưu tỷ lệ chuyển đổi (CRO): Hướng dẫn thực tế

Tối ưu tỷ lệ chuyển đổi (CRO) là thực hành có hệ thống nhằm tăng tỷ lệ khách truy cập thực hiện một hành động có giá trị trên website của bạn, bằng cách tìm ra vì sao họ không làm và khắc phục điều đó. Đó là toàn bộ ý tưởng. Mọi thứ khác trong hướng dẫn này là phương pháp: cách tìm ra lý do thực sự, cách quyết định khắc phục gì trước, cách biết một thay đổi có hiệu quả không, và cách duy trì việc này mà không tự lừa mình.

Đây là hướng dẫn tổng quát. Các nguyên tắc áp dụng cho cả cửa hàng trực tuyến lẫn công ty phần mềm B2B, nhưng chúng tôi dành thêm thời gian cho tình huống mà phần lớn hướng dẫn bỏ qua: website có lưu lượng khiêm tốn, chu kỳ bán hàng dài và các chuyển đổi có giá trị rất chênh lệch. Dù bạn gọi là tối ưu tỷ lệ chuyển đổi hay CRO, đó vẫn là cùng một lĩnh vực.

Tối ưu hóa tỷ lệ chuyển đổi thực sự là gì

Chuyển đổi là bất kỳ hành động nào bạn muốn khách truy cập thực hiện: mua hàng, yêu cầu demo, đăng ký dùng thử, đăng ký bản tin. Tỷ lệ chuyển đổi là tỷ lệ khách truy cập (hoặc phiên) hoàn thành hành động đó:

Tỷ lệ chuyển đổi = số chuyển đổi / số khách truy cập × 100

Ví dụ: một landing page nhận 18.400 phiên trong một tháng và tạo ra 460 lượt đăng ký. 460 / 18.400 = 0,025, vậy tỷ lệ chuyển đổi là 2,5%. Nếu một thay đổi nâng tỷ lệ lên 3,0% trên cùng lưu lượng, bạn có 552 lượt đăng ký: thêm 92 mỗi tháng mà không phải mua thêm lượt nhấp nào. Đó là mức tăng tương đối 20%, hay mức tăng tuyệt đối 0,5 điểm phần trăm. Luôn nói rõ bạn đang nói đến loại nào; nhầm lẫn giữa hai loại là lỗi báo cáo phổ biến nhất trong CRO. Bạn có thể tự tính với công cụ tính tỷ lệ chuyển đổi.

Công thức đó ẩn chứa hai quyết định. Thứ nhất, mẫu số: số phiên làm phình mẫu số với những website có nhiều khách quay lại, còn số người dùng lại làm nó nhỏ đi nếu tracking không loại trùng được giữa các thiết bị. Chọn một và giữ nguyên. Thứ hai, tử số: chuyển đổi nào được tính.

Chuyển đổi vĩ mô và vi mô

• Chuyển đổi vĩ mô là những hành động mà doanh nghiệp tồn tại vì chúng: một đơn hàng, một yêu cầu demo, một gói trả phí.
• Chuyển đổi vi mô là các bước dẫn đến đó: thêm vào giỏ hàng, bắt đầu điền biểu mẫu, xem bảng giá, xem video sản phẩm, nhấp vào CTA.

Chuyển đổi vi mô quan trọng vì hai lý do. Chúng chỉ ra chỗ rò rỉ (khách xem trang bảng giá nhưng không bao giờ bấm “Bắt đầu”), và chúng xảy ra thường xuyên hơn nhiều so với chuyển đổi chính, nên có thể thử nghiệm trên các website mà chuyển đổi chính quá hiếm để đo lường. Xem thêm ở phần dành cho website ít traffic.

CRO không phải là gì

• Đó không phải thử nghiệm màu nút. Thử nghiệm bề ngoài hiếm khi tạo ra thay đổi vì chúng không giải quyết lý do mọi người do dự. CRO tốt thay đổi những gì khách truy cập hiểu, tin hoặc phải làm.
• Không chỉ là A/B testing. Thử nghiệm là bước xác nhận. Phần lớn giá trị đến từ nghiên cứu cho bạn biết nên thay đổi gì. Nhiều cải tiến (biểu mẫu lỗi trên Safari, thiếu thông tin giá) chỉ cần sửa luôn, không cần thử nghiệm.
• Đây không phải một túi các thực hành tốt nhất. “Tạo cảm giác cấp bách” hay “rút gọn form” có thể giúp ích hoặc gây hại tùy đối tượng của bạn. Một thực hành chỉ là giả thuyết cho đến khi dữ liệu của chính bạn ủng hộ nó.
• CRO không phải là thu hút lưu lượng. CRO tác động vào những gì diễn ra sau khi lượt truy cập bắt đầu. Nó giúp mọi kênh thu hút hiệu quả hơn, nhưng không thay thế kênh nào.

Quy trình CRO từng bước

Mọi chương trình CRO đáng tin cậy đều chạy một phiên bản nào đó của cùng một vòng lặp. Tên gọi có thể khác; thứ tự thì không.

1. Nghiên cứu: tìm ra khách truy cập không chuyển đổi ở đâu và vì sao.
2. Giả thuyết: biến mỗi phát hiện thành một nhận định có thể kiểm thử.
3. Ưu tiên: xếp hạng giả thuyết để lưu lượng và thời gian lập trình khan hiếm được dành cho những phương án tốt nhất.
4. Thử nghiệm: chạy thử nghiệm có kiểm soát (hoặc, khi không thể, phương pháp tốt nhất kế tiếp).
5. Phân tích: đọc kết quả một cách trung thực, bao gồm cả phân khúc và chỉ số bảo vệ.
6. Triển khai và rút kinh nghiệm: đưa phương án thắng vào áp dụng, ghi lại mọi kết quả, đưa bài học trở lại vào nghiên cứu.

1. Nghiên cứu: ở đâu và vì sao

Nghiên cứu có hai nửa. Dữ liệu định lượng cho bạn biết vấn đề nằm ở đâu. Dữ liệu định tính cho bạn biết vì sao. Bạn cần cả hai: báo cáo phễu cho thấy 70% khách truy cập rời trang bảng giá, nhưng không thể cho bạn biết họ rời đi vì gói enterprise chỉ ghi “Liên hệ” mà không có khoảng giá.

Bắt đầu với dữ liệu phân tích để chọn hai hoặc ba trang quan trọng nhất (lưu lượng cao, gần doanh thu, tỷ lệ rời bỏ lớn), rồi chỉ dồn công sức nghiên cứu định tính vào đó. Một đợt nghiên cứu hai đến ba tuần thường cho ra nhiều ý tưởng test hơn số bạn có thể chạy trong sáu tháng.

Trước khi tin vào bất kỳ số liệu nào, hãy kiểm tra hệ thống đo lường. Xác nhận các sự kiện chuyển đổi chỉ kích hoạt một lần cho mỗi chuyển đổi, các bước trong phễu được theo dõi trên mọi thiết bị, và traffic nội bộ đã được lọc. Một tỷ lệ đáng ngạc nhiên các “vấn đề chuyển đổi” hóa ra là vấn đề đo lường.

2. Giả thuyết: làm cho mỗi ý tưởng có thể bị bác bỏ

Giả thuyết liên kết một quan sát với một thay đổi và một kết quả đo lường được. Hãy dùng mẫu sau:

“Vì chúng tôi đã quan sát thấy” điều dữ liệu cho thấy, “chúng tôi tin rằng thay đổi” một yếu tố “cho” một nhóm đối tượng “sẽ dẫn đến” kết quả kỳ vọng, “được đo bằng” một chỉ số chính.

Ví dụ: “Vì chúng tôi quan sát qua bản ghi phiên và khảo sát khi thoát rằng khách truy cập di động trên trang bảng giá không biết gói nào có SSO, chúng tôi tin rằng thêm một nút chuyển đổi so sánh tính năng phía trên các thẻ gói cho khách truy cập di động sẽ giúp có nhiều lượt chọn gói hơn, đo bằng số lượt nhấp vào bất kỳ nút ‘Chọn gói’ nào trên mỗi khách truy cập trang bảng giá.”

Mẫu này làm ba việc. Nó buộc phải có bằng chứng (không có chuyện “vì CEO thích”). Nó nêu rõ đối tượng, để bạn thử nghiệm đúng nơi vấn đề tồn tại. Và nó chốt chỉ số chính trước khi thử nghiệm bắt đầu, tránh việc chọn chỉ số có lợi sau đó. Phiên bản có thể sao chép nằm trong mẫu kế hoạch A/B test của chúng tôi.

3. Ưu tiên: PIE, ICE hay PXL

Bạn sẽ luôn có nhiều ý tưởng hơn năng lực thực hiện. Ba khung chấm điểm phổ biến nhất:

• PIE (Potential, Importance, Ease), được WiderFunnel phổ biến: chấm mỗi yếu tố từ 1-10 rồi lấy trung bình. “Importance” nói về mức giá trị của lưu lượng trên trang.
• ICE (Impact, Confidence, Ease), từ growth marketing: chấm mỗi yếu tố từ 1-10 rồi lấy trung bình. “Confidence” là mức độ mạnh của bằng chứng bạn có.
• PXL, của CXL: một checklist gồm phần lớn là câu hỏi có/không với điểm cố định, chẳng hạn thay đổi có nằm ở màn hình đầu tiên không, có dễ nhận ra trong năm giây không, có thêm hay bớt một thành phần không, có chạy trên trang nhiều traffic không, và có giải quyết vấn đề được phát hiện qua kiểm thử người dùng, phản hồi định tính hay dữ liệu phân tích không. Độ dễ được chấm theo công sức ước tính. CXL thiết kế mô hình này để loại bỏ phần phỏng đoán mà PIE và ICE để lại ở tiêu chí "tác động".

Ví dụ (điểm minh họa cho một backlog, PXL được rút gọn còn bảy câu hỏi):

Cả ba khung đánh giá đều đồng ý A đi đầu và D xếp cuối. Chúng bất đồng về C: PIE xếp C gần ngang B vì tiêu chí “tiềm năng” khá rộng rãi, trong khi ICE và PXL trừ điểm vì thiếu bằng chứng. Chính sự bất đồng đó là lý do cần chọn khung đánh giá một cách có chủ đích.

Quan điểm của chúng tôi: dùng ICE cho một đội nhỏ cần xếp hạng 20 ý tưởng trong một buổi chiều. Chuyển sang PXL khi có nhiều hơn một người chấm điểm, vì câu hỏi có/không cho điểm số nhất quán giữa các người chấm và ngăn tiếng nói lớn nhất thổi phồng "tác động". PIE hữu ích khi bạn đang quyết định nên làm trang nào, ít hữu ích hơn với từng ý tưởng riêng lẻ. Dù chọn mô hình nào, hãy đặt trọng số cao cho bằng chứng: yếu tố dự báo chính của một thử nghiệm thắng là giả thuyết dựa trên nghiên cứu.

4. Thử nghiệm

Xây biến thể, kiểm tra chất lượng trên mọi trình duyệt và thiết bị chính, và chạy thử nghiệm có kiểm soát khi traffic cho phép (xem phần thống kê bên dưới). Trước khi triển khai, hãy ghi lại: chỉ số chính, chỉ số bảo vệ, cỡ mẫu, thời lượng dự kiến và quy tắc dừng. Nếu không điền được năm mục này, bạn chưa sẵn sàng triển khai.

5. Phân tích

Khi đạt cỡ mẫu dự kiến, hãy kiểm tra chất lượng dữ liệu trước (tỷ lệ mẫu, theo dõi), sau đó đến chỉ số chính, rồi các chỉ số bảo vệ, rồi các phân khúc đã đăng ký trước như thiết bị hoặc khách mới so với khách quay lại. Hãy xem các phát hiện ở phân khúc bạn không lên kế hoạch là giả thuyết mới, không phải kết luận: chia một bài thử nghiệm đủ nhiều cách thì sẽ có thứ trông có vẻ có ý nghĩa một cách ngẫu nhiên.

6. Triển khai rộng và rút kinh nghiệm

Triển khai phiên bản thắng một cách bài bản (vào mã nguồn, chứ không để chạy 100% trong công cụ thử nghiệm hàng tháng trời). Ghi mọi thử nghiệm vào nhật ký: giả thuyết, ảnh chụp màn hình, số liệu, quyết định và bài học về khách truy cập. Một thử nghiệm thua nhưng bác bỏ được một niềm tin phổ biến thường có giá trị hơn một chiến thắng nhỏ, nhưng chỉ khi có người ghi chép lại.

Thống kê thử nghiệm, làm cho đúng

Bạn không cần là nhà thống kê để chạy test hợp lệ, nhưng bạn cần tôn trọng năm nguyên tắc. Tài liệu tham khảo tốt nhất là Kohavi, Tang và Xu, Trustworthy Online Controlled Experiments (2020).

Cỡ mẫu: quyết định trước khi bắt đầu

Số khách truy cập bạn cần phụ thuộc vào tỷ lệ chuyển đổi cơ sở, hiệu ứng nhỏ nhất bạn muốn phát hiện (hiệu ứng tối thiểu phát hiện được, MDE), mức ý nghĩa (alpha) và lực thống kê. Với kiểm định hai phía so sánh hai tỷ lệ:

n mỗi biến thể = [ z_1-α/2 × √(2 p̄(1-p̄)) + z_1-β × √(p₁(1-p₁) + p₂(1-p₂)) ]² / (p₂ - p₁)²

Ví dụ tính toán: mức cơ sở p₁ = 3%, MDE = 20% tương đối, nên p₂ = 3,6%. Alpha = 0,05 (hai phía), nên z = 1,96. Độ mạnh = 0,8, nên z ≈ 0,8416. Tỷ lệ gộp p̄ = 3,3%.

1. Số hạng thứ nhất: 1,96 × √(2 × 0,033 × 0,967) = 1,96 × √0,06382 = 1,96 × 0,2526 = 0,4951
2. Số hạng thứ hai: 0,8416 × √(0,03 × 0,97 + 0,036 × 0,964) = 0,8416 × √(0,02910 + 0,03470) = 0,8416 × 0,2526 = 0,2126
3. Tử số: (0,4951 + 0,2126)² = 0,7077² = 0,5009
4. Mẫu số: (0,036 - 0,03)² = 0,006² = 0,000036
5. n = 0,5009 / 0,000036 ≈ 13.900 khách truy cập mỗi biến thể, tổng cộng khoảng 27.800.

Con số này khớp với kết quả của máy tính cỡ mẫu của Evan Miller cho cùng đầu vào, và bạn có thể kiểm tra kịch bản của mình trong máy tính A/B test của chúng tôi. Hãy để ý phép toán khắc nghiệt thế nào: giảm MDE xuống một nửa còn 10% và bạn cần lưu lượng gấp khoảng bốn lần. Bài viết về cỡ mẫu A/B test có bảng tra cho các tỷ lệ cơ sở phổ biến.

Thời gian: cỡ mẫu chia cho lưu lượng, tính theo tuần trọn vẹn

Thời gian thử nghiệm = tổng cỡ mẫu cần thiết / số khách truy cập đủ điều kiện mỗi tuần, làm tròn lên thành số tuần nguyên.

Ví dụ: trang ở trên có 7.000 khách truy cập đủ điều kiện mỗi tuần. 27.800 / 7.000 = 3,97, nên hãy chạy 4 tuần trọn vẹn. Tuần trọn vẹn quan trọng vì khách truy cập ngày thường và cuối tuần hành xử khác nhau; dừng vào thứ Tư sẽ làm một phần của tuần bị đại diện quá mức. Theo kinh nghiệm, hãy chạy ít nhất một chu kỳ kinh doanh đầy đủ và tránh thử nghiệm dài hơn sáu đến tám tuần, vì sau đó việc xóa cookie và thay đổi theo mùa bắt đầu làm nhiễu mẫu.

Đừng xem trộm kết quả (hoặc dùng phương pháp được thiết kế cho việc đó)

Kiểm tra một bài kiểm thử tiêu chuẩn có thời hạn cố định hằng ngày và dừng ngay khi đạt p < 0,05 làm tăng mạnh kết quả dương tính giả, như Evan Miller chỉ ra trong How Not To Run an A/B Test. Hoặc cam kết với cỡ mẫu đã lên kế hoạch và chỉ đọc kết quả ở cuối, hoặc dùng công cụ có phương pháp thống kê được xây dựng cho giám sát liên tục (sequential testing). Xem dashboard thì không sao; hành động sớm dựa vào nó mới là vấn đề.

Kiểm tra sai lệch tỷ lệ mẫu

Nếu bạn chia lưu lượng 50/50 mà nhận 10.000 khách ở nhóm đối chứng và 9.400 ở biến thể, có gì đó đang hỏng: một lệnh chuyển hướng làm mất người dùng, bộ lọc bot chỉ tác động lên một nhánh, một biến thể bị lỗi trên một số trình duyệt. Kiểm định chi bình phương trên số lượng khách truy cập sẽ phát hiện điều này. Kohavi và cộng sự coi sai lệch tỷ lệ mẫu (SRM) là một trong những phép kiểm tra độ tin cậy quan trọng nhất; khi nó không đạt, đừng diễn giải kết quả, hãy tìm lỗi.

Hiệu ứng mới lạ, một chỉ số chính và chỉ số bảo vệ

• Hiệu ứng mới lạ và hiệu ứng thói quen: khách quay lại có thể nhấp vào thành phần mới vì nó mới, hoặc bỏ qua vì đã quen bố cục cũ. Hãy so sánh tuần đầu với các tuần sau; nếu tác động mờ dần, hãy hoài nghi.
• Một chỉ số chính: công bố từ trước, lý tưởng nhất là chỉ số gần doanh thu nhất mà bạn đo được với đủ lượng dữ liệu. Mười chỉ số “chính” chắc chắn sẽ cho ra một người thắng giả ở đâu đó.
• Chỉ số bảo vệ: những thứ không được tệ đi, như doanh thu trên mỗi khách truy cập, chất lượng lead, tỷ lệ hoàn tiền, thời gian tải trang. Một biến thể tăng lượt đăng ký 10% nhưng giảm giá trị đơn hàng trung bình 15% không phải là biến thể thắng.

Và hãy kiểm thử một thay đổi nhất quán cho mỗi biến thể, trừ khi bạn có rất nhiều lưu lượng. Bài so sánh A/B testing và multivariate testing của chúng tôi giải thích khi nào hướng multivariate đáng với chi phí lưu lượng (hiếm khi, nếu website có dưới 100.000 lượt truy cập mỗi tháng).

CRO cho website ít traffic và website B2B

Phần lớn lời khuyên về CRO được viết bởi những người tối ưu website tiêu dùng có lưu lượng lớn. Website B2B, và cả website tiêu dùng nhỏ, đối mặt với ba vấn đề mang tính cấu trúc:

1. Traffic thấp. Ví dụ minh họa ở trên cần khoảng 27.800 khách truy cập cho một bài thử nghiệm. Một trang có 5.000 lượt truy cập mỗi tháng sẽ mất năm đến sáu tháng, đến lúc đó thị trường, quảng cáo và chính trang đó đã thay đổi.
2. Chu kỳ bán hàng dài. Một bài test có thể đếm lượt điền form trong vài tuần, nhưng việc những lead đó có thành pipeline hay không cần nhiều tháng. Biến thể thắng về số yêu cầu demo vào tháng 2 có thể thua về doanh thu vào tháng 6 nếu nó thu hút những công ty kém phù hợp.
3. Giá trị chuyển đổi không đồng đều. Một yêu cầu demo có thể đến từ một công ty có thể trở thành khách hàng lớn nhất của bạn; yêu cầu khác lại đến từ một sinh viên. Tỷ lệ chuyển đổi xem chúng ngang nhau, còn các chỉ số tính theo doanh thu thì nhiễu hơn nhiều, nên chúng cần còn nhiều dữ liệu hơn nữa.

Điều này không có nghĩa là “đừng làm CRO”. Nó có nghĩa là thay đổi phương pháp.

Nên thử nghiệm gì trước

Khi bạn chỉ chạy được vài thử nghiệm mỗi năm, hãy chạy những thử nghiệm có hiệu ứng kỳ vọng lớn trên các trang gần doanh thu. Một thứ tự hợp lý:

1. Tiêu đề và tuyên bố giá trị trên các trang thương mại có traffic cao nhất: tập trung vào kết quả hay vào tính năng, dành riêng cho đối tượng hay chung chung, bắt đầu từ vấn đề hay từ giải pháp.
2. Ưu đãi và CTA: không chỉ chữ trên nút, mà là thứ bạn đưa ra (demo, product tour, đánh giá, cuộc gọi báo giá) và vị trí nó xuất hiện.
3. Form: trường thông tin, câu hỏi sàng lọc, một bước hay nhiều bước. Đo chất lượng lead, không chỉ tỷ lệ hoàn thành.
4. Bố cục và cấu trúc trang để sau cùng: tốn kém nhất để xây, trung bình cho mức tác động nhỏ nhất và đo lường chậm nhất.

Thay đổi táo bạo hơn

Cỡ mẫu cần thiết tỷ lệ nghịch với bình phương hiệu ứng. Phát hiện mức tăng 40% cần khoảng một phần tư lưu lượng so với mức tăng 20%. Những chỉnh sửa nhỏ không thể thử nghiệm với lưu lượng thấp; những thay đổi táo bạo dựa trên nghiên cứu (một lập luận tiêu đề hoàn toàn khác, một ưu đãi khác) thì được. Chúng cũng dạy bạn nhiều hơn về người mua, trong khi chỉnh sửa nhỏ chỉ dạy bạn về trang.

Test các chuyển đổi vi mô ở phía trên phễu

Nếu yêu cầu demo quá hiếm, hãy chọn một chỉ số chính ở vị trí cao hơn trong phễu và có mối liên hệ hợp lý với nó: lượt nhấp đến trang demo, số lần bắt đầu điền biểu mẫu, lượt truy cập trang bảng giá từ trang chủ. Một chỉ số xảy ra thường xuyên gấp mười lần sẽ giúp test đạt đủ độ mạnh nhanh hơn khoảng mười lần. Đổi lại, bạn vẫn phải theo dõi chuyển đổi chính như một chỉ số bảo vệ, vì chuyển đổi vi mô có thể tăng trong khi chuyển đổi thực sự vẫn đi ngang.

Chấp nhận mức độ tin cậy phù hợp với quyết định

Không phải quyết định nào cũng cần độ tin cậy 95%. Với các thay đổi nội dung dễ hoàn tác, ngưỡng thấp hơn (hoặc đọc theo “xác suất là phương án tốt nhất” của phương pháp Bayes) là sự đánh đổi hợp lý giữa tốc độ và độ chắc chắn. Với các thay đổi cấu trúc tốn kém để hoàn tác, như thiết kế lại trang bảng giá, hãy chờ bằng chứng mạnh. Quyết định ngưỡng trước khi thử nghiệm, không phải sau khi đã thấy con số.

Thử nghiệm tuần tự và trước/sau, kèm lưu ý

Khi không thể chia nhóm kiểm thử (trải nghiệm cho tài khoản mục tiêu chỉ có vài chục lượt truy cập, thay đổi điều hướng toàn website), so sánh trước/sau vẫn tốt hơn không có gì, nhưng hãy thẳng thắn về điểm yếu của nó: yếu tố mùa vụ, chiến dịch, hoạt động sales và tin tức thị trường đều thay đổi cùng lúc với trang của bạn. Giảm rủi ro bằng cách so sánh các khoảng thời gian bằng nhau, kiểm tra một chỉ số đối chứng mà thay đổi của bạn không nên ảnh hưởng (nếu nó cũng thay đổi, sự dịch chuyển có lẽ đến từ bên ngoài), và lặp lại việc bật/tắt (bật, tắt, bật) khi có thể.

Dựa vào nghiên cứu định tính

Với lưu lượng thấp, năm cuộc phỏng vấn khách hàng và hai mươi bản ghi cuộc gọi bán hàng có giá trị hơn một thử nghiệm thiếu lực thống kê. Hãy dùng nghiên cứu định tính để thực hiện những thay đổi bạn khá chắc chắn, và dành thử nghiệm cho những quyết định thực sự chưa chắc chắn và có rủi ro cao.

Đo pipeline, không đo lượt điền form

Ví dụ: biến thể A tạo ra 20 lead, trong đó 25% trở thành cơ hội (5 cơ hội). Biến thể B tạo ra 30 lead, trong đó 10% trở thành cơ hội (3). B “thắng” về tỷ lệ chuyển đổi nhưng thua ở chỉ số thực sự quan trọng. Hãy kết nối công cụ testing hoặc phân tích với CRM để mỗi lead mang theo biến thể của nó, và xem lại kết quả khi dữ liệu cơ hội đã đủ chín. Cũng kiểm tra kết quả theo phân khúc: một kết quả tổng đi ngang có thể che giấu một biến thể thắng với khách từ doanh nghiệp lớn và thua với công ty nhỏ, triệt tiêu lẫn nhau. Về các chiến thuật CRO riêng cho B2B như biểu mẫu sàng lọc, bằng chứng xã hội cho doanh nghiệp lớn và nội dung cho hội đồng mua hàng, xem hướng dẫn chuyên sâu về tối ưu tỷ lệ chuyển đổi B2B của chúng tôi.

Thực hiện audit CRO

Kiểm định CRO là bước nghiên cứu được rút gọn thành một đợt đánh giá một lần, hữu ích khi bạn tiếp quản một website hoặc cần nhanh chóng có kế hoạch ưu tiên. Phiên bản ngắn gọn:

1. Kiểm tra đo lường: sự kiện chuyển đổi, các bước phễu, theo dõi xuyên tên miền, lọc lưu lượng nội bộ.
2. Vẽ bản đồ phễu theo thiết bị và kênh, và tìm hai bước có mức thất thoát tuyệt đối lớn nhất.
3. Đánh giá các trang đó theo kinh nghiệm: mức độ rõ ràng của ưu đãi trong năm giây, mức độ liên quan với nguồn traffic, ma sát (số trường, số bước, thời gian tải), lo ngại (độ tin cậy, giá, quyền riêng tư) và yếu tố gây xao nhãng.
4. Thu thập bằng chứng định tính trên cùng các trang: bản ghi phiên, một khảo sát ngắn, vài buổi kiểm thử người dùng.
5. Ghi lại phát hiện dưới dạng “sửa ngay” (lỗi, luồng hỏng), “điều tra” hoặc “thử nghiệm”, mỗi mục có một giả thuyết và điểm ưu tiên.

Checklist audit CRO của chúng tôi liệt kê mọi hạng mục kiểm tra, và hướng dẫn audit CRO chỉ cách biến các phát hiện thành lộ trình.

Nên tập trung vào đâu, theo loại trang

Có hai chuẩn tham chiếu bên ngoài đáng biết. Baymard Institute, tổng hợp 50 nghiên cứu, cho thấy tỷ lệ bỏ giỏ hàng trực tuyến được ghi nhận vào khoảng 70%; trong số những người mua bỏ giỏ vì lý do khác ngoài "chỉ xem thử", chi phí phát sinh (40%) và bắt buộc tạo tài khoản (18%) xếp hạng cao, và Baymard ước tính một quy trình thanh toán lý tưởng chỉ cần 7-8 trường biểu mẫu so với mức trung bình khoảng 15 ở Mỹ. Với biểu mẫu nói chung, khuyến nghị về khả năng sử dụng biểu mẫu của Nielsen Norman Group (giữ biểu mẫu ngắn, một cột, giải thích yêu cầu từ đầu, thông báo lỗi cụ thể) là một checklist vững chắc. Biểu mẫu B2B là ngoại lệ một phần của nguyên tắc "càng ngắn càng tốt", vì các trường đánh giá chất lượng bảo vệ thời gian của sales; hướng dẫn thiết kế biểu mẫu thu thập lead của chúng tôi trình bày cách khớp độ dài biểu mẫu với ý định, và tối ưu landing page B2B đi sâu hơn vào các trang chiến dịch.

Cá nhân hóa như một đòn bẩy CRO

A/B test truyền thống hỏi “phiên bản nào tốt nhất cho tất cả mọi người?” Đôi khi câu trả lời trung thực là “không phiên bản nào”: người mua doanh nghiệp lớn và một startup năm người cần bằng chứng khác nhau, ngôn ngữ khác nhau và bước tiếp theo khác nhau, và kết quả trung bình che giấu điều đó. Cá nhân hóa nghĩa là phục vụ trải nghiệm khác nhau cho các phân khúc xác định, rồi đo từng phân khúc so với nhóm đối chứng của chính phân khúc đó.

Cá nhân hóa vượt trội hơn kiểm thử một-cho-tất-cả khi đáp ứng ba điều kiện: đối tượng của bạn chia thành các phân khúc có nhu cầu thực sự khác nhau (theo ngành, quy mô công ty, giai đoạn phễu hoặc nguồn lưu lượng), bạn nhận ra các phân khúc đó một cách đáng tin cậy ngay khi họ đến, và bạn có nội dung thực sự khác biệt cho từng phân khúc. Nếu thiếu bất kỳ điều kiện nào, cá nhân hóa chỉ thêm phức tạp mà không tăng kết quả. Nó cũng chia nhỏ lưu lượng, nên không phải lối tắt để né phép tính cỡ mẫu; hãy bắt đầu với một hoặc hai phân khúc lớn và một trang. Nếu muốn xây dựng cấu trúc phân khúc trước, hướng dẫn chiến lược phân khúc sẽ hướng dẫn bạn từng bước, và tính năng phân khúc của chúng tôi cho thấy Markettailor phục vụ biến thể riêng cho từng phân khúc kèm nhóm đối chứng holdout như thế nào.

Các lỗi CRO thường gặp (và cách khắc phục)

1. Kiểm thử mà không nghiên cứu. Ý tưởng từ brainstorm ít khi thắng hơn ý tưởng từ bằng chứng. Cách khắc phục: mọi bài kiểm thử đều dẫn ra quan sát làm cơ sở.
2. Dừng thử nghiệm sớm. Lợi thế ban đầu phần lớn là nhiễu và việc xem trộm kết quả làm tăng dương tính giả. Cách khắc phục: cố định cỡ mẫu và thời gian từ trước.
3. Bài test thiếu cỡ mẫu. Một bài test chỉ phát hiện được mức tăng 50% sẽ kết luận hầu hết cải thiện thực tế là “không khác biệt”. Cách sửa: tính MDE bạn có thể phát hiện trước khi triển khai và chỉ chạy những bài test có khả năng đạt được mức đó.
4. Tối ưu sai chỉ số. Nhiều lead hơn, pipeline tệ hơn. Cách khắc phục: chỉ số chính càng gần doanh thu càng tốt trong phạm vi khối lượng cho phép, cộng với các rào chắn về chất lượng.
5. Gọi thử nghiệm thua là thất bại. Các đội lặng lẽ bỏ qua các thử nghiệm thua và đánh mất bài học. Cách khắc phục: ghi lại mọi kết quả và điều nó đã bác bỏ.
6. Bỏ qua phân khúc, hoặc diễn giải quá mức. Cả hai đều xảy ra. Cách khắc phục: đăng ký trước hai hoặc ba phân khúc (thiết bị, khách mới so với khách quay lại, quy mô công ty) và coi phần còn lại là giả thuyết.
7. Sao chép đối thủ hoặc danh sách “best practice”. Bạn thấy trang của họ, không thấy kết quả của họ. Cách sửa: dùng chúng làm nguồn giả thuyết, không bao giờ là đáp án.
8. Bỏ qua QA. Một biến thể bị lỗi trên một trình duyệt tạo ra phiên bản thua giả và sai lệch tỷ lệ mẫu. Cách sửa: kiểm tra mọi biến thể trên các trình duyệt và thiết bị chính trước khi triển khai.
9. Coi CRO như một dự án. Một lần kiểm tra, năm chỗ sửa, xong. Cách khắc phục: một nhịp làm việc cố định có người phụ trách, danh sách việc tồn đọng và nhật ký.
10. Không sửa lỗi hiển nhiên vì “chúng ta nên thử nghiệm đã”. Cách khắc phục: thứ bị hỏng thì sửa; thứ chưa chắc chắn thì thử nghiệm.

Công cụ CRO theo từng việc

Chọn công cụ theo nhiệm vụ của nó, và mua công cụ thử nghiệm sau cùng: hầu hết các đội cần nghiên cứu tốt hơn trước khi cần thêm năng lực thử nghiệm.

• Phân tích: phễu, phân khúc và sự kiện. Google Analytics 4, Adobe Analytics, hoặc công cụ phân tích sản phẩm như Mixpanel và Amplitude.
• Phân tích hành vi: bản đồ nhiệt và bản ghi phiên. Microsoft Clarity, Hotjar, Contentsquare.
• Testing và cá nhân hóa: thử nghiệm phía trình duyệt hoặc phía máy chủ. Optimizely, VWO, AB Tasty, hoặc các nền tảng feature flag cho test phía máy chủ.
• Khảo sát và nghiên cứu người dùng: khảo sát nhanh trên trang và kiểm thử người dùng có hoặc không có người điều phối. Hotjar surveys, Typeform, UserTesting, Maze.

Để có bảng so sánh đầy đủ hơn theo mức lưu lượng và ngân sách, xem tổng hợp công cụ tối ưu tỷ lệ chuyển đổi của chúng tôi.

Xây dựng chương trình CRO

CRO chỉ tạo hiệu quả cộng dồn khi được vận hành như một chương trình thay vì một loạt bản sửa rời rạc. Cấu trúc tối thiểu:

• Một người phụ trách có thời gian dành riêng cho việc này, cùng quyền tiếp cận năng lực thiết kế và phát triển. Không có thời gian của lập trình viên, backlog sẽ trở thành danh sách mong ước.
• Nhịp làm việc: một sprint nghiên cứu mỗi quý, buổi rà soát ưu tiên hai tuần một lần, và báo cáo kết quả hằng tháng cho các bên liên quan.
• Nhật ký thử nghiệm mà ai cũng tìm kiếm được: giả thuyết, đối tượng, ảnh chụp màn hình, mẫu, kết quả, quyết định, bài học. Sau một năm, đây là tài sản CRO giá trị nhất bạn có.
• Mục tiêu năng suất thực tế. Một website tiêu dùng nhiều lưu lượng có thể chạy song song vài thử nghiệm mỗi tháng trên các trang khác nhau. Một website B2B có 10.000 khách truy cập mỗi tháng có thể chỉ chạy được một hoặc hai thử nghiệm mỗi tháng, kết hợp với các bản sửa dựa trên nghiên cứu.

Hãy đặt kỳ vọng về tỷ lệ thắng ngay từ đầu. Trong Online Experimentation at Microsoft (Kohavi et al., 2009), các tác giả cho biết chỉ khoảng một phần ba ý tưởng cải thiện được chỉ số mà chúng được thiết kế để cải thiện, khoảng một phần ba không đổi và một phần ba tiêu cực. Ý tưởng của Microsoft không tệ; chỉ là ý tưởng tốt rất khó dự đoán. Nếu chương trình của bạn “thắng” 80% số thử nghiệm, lời giải thích hợp lý hơn là thống kê lỏng lẻo, không phải ý tưởng xuất sắc. Hãy đánh giá chương trình CRO dựa trên tác động tích lũy đã được xác thực và chất lượng những gì nó học được, không phải tỷ lệ thắng.

Câu hỏi thường gặp

Tỷ lệ chuyển đổi tốt là bao nhiêu?

Không có con số tốt chung cho mọi trường hợp, vì tỷ lệ chuyển đổi phụ thuộc vào thứ bạn đếm, cơ cấu lưu lượng, mức giá và chu kỳ mua. Một lượt đăng ký newsletter miễn phí và một yêu cầu demo enterprise trị giá hàng trăm nghìn không thể dùng chung một benchmark. Phép so sánh hữu ích là so với mức cơ sở của chính bạn cho cùng trang, cùng nguồn lưu lượng và cùng thiết bị. Hãy cải thiện nó đều đặn, và đánh giá thành công bằng doanh thu hoặc pipeline trên mỗi khách truy cập thay vì chỉ nhìn vào tỷ lệ.

Một bài A/B test nên chạy trong bao lâu?

Chạy cho đến khi đạt cỡ mẫu bạn đã tính trước khi triển khai, làm tròn lên thành tuần trọn vẹn để mọi ngày trong tuần đều được đại diện như nhau. Chia tổng số khách truy cập cần thiết cho lưu lượng đủ điều kiện hằng tuần. Với hầu hết website, con số đó là hai đến sáu tuần. Nếu phép tính ra vài tháng, hãy test một thay đổi lớn hơn hoặc một chỉ số có số lượng lớn hơn thay vì chạy một test không hồi kết.

CRO và SEO khác nhau thế nào?

SEO tăng số khách truy cập đủ điều kiện đến website từ tìm kiếm tự nhiên. CRO tăng tỷ lệ những khách truy cập đó, từ bất kỳ kênh nào, thực hiện một hành động có giá trị. Hai việc hỗ trợ lẫn nhau: những trang trả lời rõ ý định của người tìm kiếm thường vừa xếp hạng tốt vừa chuyển đổi tốt hơn. Xung đột hiếm khi xảy ra, nhưng hãy tránh các thay đổi CRO ẩn hoặc loại bỏ nội dung mà công cụ tìm kiếm và khách truy cập cần.

CRO có đáng làm với website ít lưu lượng truy cập không?

Có, nhưng phương pháp sẽ khác. Khi lưu lượng hạn chế, hãy dựa vào nghiên cứu định tính như phỏng vấn khách hàng, bản ghi phiên truy cập và kiểm thử người dùng, sửa ngay các vấn đề hiển nhiên, và dành A/B test cho những thay đổi táo bạo, quan trọng, đo bằng các chỉ số đầu phễu xảy ra thường xuyên. Ngay cả khi không kiểm thử gì, một đợt audit dựa trên nghiên cứu cho hai hoặc ba trang quan trọng nhất thường vẫn tìm ra những điểm ma sát đáng sửa.

Chuyên viên CRO làm gì?

Chuyên viên CRO vận hành vòng lặp tối ưu hóa: phân tích phễu, nghiên cứu người dùng, viết giả thuyết, ưu tiên và thiết kế thử nghiệm, kiểm tra giá trị thống kê và biến kết quả thành khuyến nghị. Vai trò này kết hợp phân tích dữ liệu, nghiên cứu UX, khả năng đánh giá nội dung và đủ kiến thức thống kê để tránh những phiên bản thắng giả. Nếu bạn đang cân nhắc theo nghề này, bài tổng quan về việc làm tối ưu hóa tỷ lệ chuyển đổi của chúng tôi trình bày các vị trí, kỹ năng và cách bắt đầu.