Quay lại Blog
Du lịchỨng dụng thực tếSo sánh

Hoa hồng Klook 3,5 %, nhưng ảnh đã ăn mất một nửa người đọc

Đăng ngày10 min read
Chia sẻ

Ai cũng tính hoa hồng, không ai tính tỷ lệ rời trang

Tôi đọc khá nhiều bài hướng dẫn tiếp thị liên kết du lịch, nội dung trùng nhau nhiều: đăng ký thế nào, hoa hồng bao nhiêu phần trăm, chèn liên kết ở đâu, bao lâu thì đơn được ghi nhận.

Nhìn từ dữ liệu, những thông tin đó không sai. Klook trả khoảng 5 % cho vé phương tiện, 3,5 % cho phần lớn nhóm sản phẩm. Agoda khoảng 4,2 %, khách sạn Booking.com từ 2,8 đến 4,5 %, KKday theo bậc từ 2 đến 5,5 %. Thời gian ghi nhận đơn Klook là 30 ngày, KKday có khi tới 60 ngày.

Nhưng tất cả những bài đó có chung một điểm mù: chúng mặc định người đọc sẽ nhìn thấy liên kết của bạn.

Nói thẳng, giả định này đặc biệt mong manh với nội dung du lịch. Bởi ký sự là loại nội dung có mật độ ảnh cao nhất, mà ảnh lại chính là thủ phạm số một khiến trang tải chậm trên di động.

Doanh thu của một bài viết là phép nhân: lưu lượng × tỷ lệ đọc tới liên kết × tỷ lệ nhấp × tỷ lệ chuyển đổi × tỷ lệ hoa hồng. Phần lớn mọi người dồn chín phần mười công sức vào thừa số cuối — thừa số nhỏ nhất trong cả phép nhân.

Thử tính một bài toán

Trước hết là các số liệu hiệu năng đã công bố, không phải suy luận của tôi.

Core Web Vitals của Google định nghĩa LCP dưới 2,5 giây là tốt. Thực tế: năm 2023 có 74 % website đạt LCP tốt trên máy tính, còn di động chỉ 61,4 %. Thời gian tải trung bình trên di động là 8,6 giây, trên máy tính là 2,5 giây.

Số liệu về rời trang còn trực tiếp hơn. Thời gian tải tăng từ 1 lên 3 giây thì xác suất rời trang tăng 32 %; trang di động quá ba giây thì hơn một nửa khách bỏ đi luôn. Nhiều nghiên cứu đều chỉ về khoảng mỗi giây chậm thêm làm mất 7 % đến 20 % chuyển đổi.

Đặt các con số này vào bối cảnh tiếp thị liên kết, khoảng cách hiện ra rất rõ.

Tình huống LCP trên di động Tỷ lệ tương đối đọc tới liên kết cuối bài Doanh thu hoa hồng (giá trị tương đối)
Ký sự đã tối ưu ảnh dưới 2 giây mốc 100 % 100
Chưa tối ưu, nhiều ảnh 4–5 giây giảm khoảng một nửa 50–60
Trường hợp cực đoan (đưa ảnh gốc lên thẳng) trên 8 giây còn rất ít dưới 20

Các con số trong bảng là giá trị tương đối ước lượng từ những nghiên cứu công khai về rời trang và chuyển đổi, không phải số liệu tuyệt đối tôi tự đo từng trang — nhưng hướng thì không sai. Cùng một bài viết, cùng liên kết Klook, cùng tỷ lệ hoa hồng, chỉ khác cách xử lý ảnh mà doanh thu chênh nhau hơn gấp đôi.

Hơn gấp đôi. Trong khi phần lớn mọi người dành thời gian chọn nền tảng liên kết nhiều hơn hẳn thời gian xử lý ảnh.

Vì sao ký sự du lịch nặng một cách có hệ thống

Đứng từ góc vận hành, đây là vấn đề cấu trúc chứ không phải ai lười.

Số lượng ảnh vốn đã lớn. Trang sản phẩm thương mại điện tử năm tám tấm là đủ, còn bài ký sự bảy ngày bắt đầu từ ba mươi tấm. Đây là phần không cắt được — thứ người đọc cần chính là hình ảnh, cắt ảnh là cắt giá trị cốt lõi của bài.

Tìm kiếm du lịch nghiêng hẳn về di động. Người ta tra «lịch trình Kyoto 3 ngày» lúc đi làm, giờ nghỉ trưa, trước khi ngủ. Mà di động lại đúng là môi trường hiệu năng kém nhất: trung bình 8,6 giây, mạng chậm hơn, khả năng giải mã yếu hơn.

Ảnh gốc từ máy ảnh ngày càng nặng. Điện thoại bây giờ chụp vô tư đã 4–5 MB, nhiều người đưa thẳng ảnh gốc vào hệ quản trị nội dung rồi phó mặc cho tiện ích nén. Chất lượng nén của các tiện ích rất chênh lệch, mà phần lớn chỉ đổi kích thước chứ không đổi định dạng.

Trước đây tôi tưởng đó là vấn đề máy chủ, đổi máy chủ rồi mới thấy chẳng cải thiện bao nhiêu — nút thắt chưa bao giờ nằm ở thời gian phản hồi của máy chủ, mà ở ba mươi tấm ảnh đang truyền xuống. Trả xong học phí đó tôi mới bắt đầu nghiêm túc nhìn vào số byte thực của từng tấm ảnh.

Ba điều chỉnh làm được ngay

Không cần viết lại website. Ba việc này có tỷ suất hiệu quả cao nhất.

Một, hạ cạnh dài xuống 1600 pixel và chuyển sang WebP. Ảnh ký sự không cần rộng 4000 pixel, khung hiển thị trên điện thoại của người đọc thường chưa tới 500 pixel. WebP ở cùng chất lượng nhẹ hơn JPEG 25–50 %, riêng việc này thường cắt được hơn nửa dung lượng trang.

Hai, cho tất cả ảnh ngoài màn hình đầu tải trễ. Trình duyệt hiện nay hỗ trợ sẵn, chỉ thêm một thuộc tính. LCP đo thời gian vẽ phần tử nội dung lớn nhất, nên chặn hai mươi chín tấm phía dưới tranh băng thông với ảnh đầu sẽ cải thiện con số này rõ rệt.

Ba, dời vị trí liên kết liên kết lên sớm hơn một đoạn. Đây là điều phản trực giác nhất nhưng hiệu quả tức thì. Nhiều người quen đặt liên kết Klook hay Traveloka ở phần tổng kết cuối bài — đúng chỗ ít người kéo tới nhất. Đặt một lần ở một phần ba đầu bài (chẳng hạn khi kể «tour này mình đặt ở đâu») sẽ hứng được nhóm độc giả không đủ kiên nhẫn kéo xuống đáy.

Nhân tiện, điều thứ ba không liên quan đến hiệu năng, nhưng nó là nửa còn lại của cùng một vấn đề: sự chú ý của người đọc cũng là tài nguyên hữu hạn, y như băng thông.

Ảnh nên đặt ở đâu

Đây là câu hỏi thực tế hay gặp nhất, và quan điểm của tôi là — trước hết phải tách hai nhu cầu.

Tài sản nội dung dài hạn (ảnh minh họa cho các bài chủ lực) nên đặt ở nơi bạn kiểm soát được, kèm CDN. Những ảnh này phải sống trên năm năm, không thể phụ thuộc vào việc chính sách của một dịch vụ miễn phí không đổi.

Cộng tác ngắn hạn và bản nháp (ảnh chụp trao đổi với biên tập, tư liệu gửi đối tác xem, ảnh tạm cho mạng xã hội) thì dùng dịch vụ lưu trữ ảnh tiện hơn, vì bỏ được khâu tải lên hệ quản trị rồi lại xóa.

Với lpic.cc, tải lên xong có ngay liên kết rút gọn để dán, không cần đăng ký, cần thì thêm mật khẩu xem — khá hợp với tư liệu hợp tác chưa công bố. Nhưng giới hạn phải nói rõ: ảnh tối đa 8 MB, tệp giữ 30 ngày kể từ lần xem cuối, và tệp tải lên được nén tối ưu tự động nên bản gốc không được giữ lại.

Vậy nên nó hợp làm trạm trung chuyển, không hợp làm nguồn ảnh chính thức. Người đọc thật ra không quan tâm ảnh của bạn nằm ở đâu, nhưng doanh thu của bạn thì quan tâm ba năm nữa ảnh còn hiện hay không. Hai việc này phải tách ra xử lý.

Muốn xem ảnh hưởng thực tế của cách lưu trữ tới tốc độ tải, trên trang có hai bài: đo tốc độ các dịch vụ lưu trữ ảnh đo chênh lệch độ trễ giữa các nhà cung cấp, và đo LCP toàn trình khi tải hàng loạt ảnh sản phẩm áp dụng cùng phương pháp cho thương mại điện tử, có thể chuyển thẳng sang ký sự du lịch.

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

Q1: Lưu lượng của tôi còn ít, tối ưu ảnh có đáng không?

Đáng, nhưng phải đúng thứ tự. Khi chưa đạt quy mô nhất định, chất lượng nội dung và chọn chủ đề có đòn bẩy lớn hơn nhiều so với hiệu năng. Tuy vậy tối ưu ảnh là loại đầu tư một lần rồi hưởng lâu dài — dựng xong quy trình thì mọi bài sau tự động hưởng lợi, khác hẳn chi phí kéo khách phải bỏ ra liên tục.

Q2: Nén mạnh quá người đọc có thấy ảnh xấu đi không?

Hạ chất lượng JPEG xuống 80–85 hoặc chuyển sang WebP thì trên màn hình điện thoại gần như không phân biệt được. Thứ thật sự bị phàn nàn là nén xuống dưới 60 làm xuất hiện dải màu. Có một cách dung hòa: ảnh trong bài dùng bản nén, đồng thời đặt thêm liên kết «xem ảnh gốc» cho số ít người đọc muốn phóng to.

Q3: Thời gian ghi nhận đơn 30–60 ngày ảnh hưởng dòng tiền nhiều không?

Nếu bạn mới bắt đầu thì ảnh hưởng rất lớn. Klook ghi nhận đơn sau 30 ngày, KKday tới 60 ngày, nghĩa là nội dung sản xuất tháng này có thể hai tháng sau mới về tiền, mà khách hủy chuyến thì hoa hồng cũng mất luôn. Đây là khác biệt về bản chất giữa liên kết du lịch và liên kết thương mại điện tử thông thường, phải tính vào kế hoạch dòng tiền.

Q4: Một bài ký sự nên để bao nhiêu ảnh?

Xét theo tỷ lệ đọc hết bài, 25–35 tấm là khoảng thực dụng. Vượt con số đó, mức mỏi mắt khi kéo trang trên di động tăng rõ rệt. Thà chọn 30 tấm và bảo đảm tấm nào cũng tải nhanh, còn hơn dán 60 tấm.

Q5: Có nên đăng ký cả Klook lẫn Traveloka không?

Chi phí đăng ký cả hai gần như bằng không, và mức trùng lặp sản phẩm không cao như tưởng tượng — cùng một điểm tham quan nhưng gói dịch vụ, giá và tình trạng chỗ ở hai bên thường khác nhau. Điều cốt lõi không phải chọn bên nào, mà là nội dung của bạn có người đọc hay không. Thất bại phổ biến nhất trong mảng này không phải chọn sai nền tảng, mà là chưa có người đọc đã lo tính hoa hồng.

Nguồn tham khảo

#tiếp thị liên kết#blog du lịch#Klook#Traveloka#Core Web Vitals#LCP#tối ưu ảnh
A

Tác giả

Andy Chen

Đồng sáng lập & CEO

Chuyên gia phân tích dữ liệu và tiếp thị quảng cáo kỹ thuật số