Ở bài 1, Nhà Gọn học cách đo kênh không trả tiền. Bài này chuyển sang kênh trả tiền, và đây là nơi sai lầm tốn kém nhất, vì analytics ở đây không chỉ để biết, mà để đút thẳng vào cỗ máy tiêu tiền.
Cơ chế đáng sợ nằm ở chỗ: bạn gửi conversion về Google và Meta, và thuật toán đấu thầu của họ học từ những conversion đó để quyết định hiển thị quảng cáo cho ai với giá nào. Nếu conversion bạn gửi bị sai, thiếu, hoặc đếm trùng, thuật toán học sai và tiêu tiền vào sai người. Đo đúng ở đây không phải chuyện báo cáo, mà là chuyện lời lỗ.
Vì sao chỉ chạy Pixel là không đủ
Cách cũ để đo quảng cáo là đặt một đoạn mã (Pixel với Meta, thẻ chuyển đổi với Google) trên trình duyệt của khách. Khi khách mua, đoạn mã đó gửi tín hiệu về nền tảng quảng cáo.
Vấn đề: đoạn mã chạy trên trình duyệt, mà trình duyệt ngày càng chặn. Trình chặn quảng cáo, giới hạn cookie của trình duyệt, cài đặt riêng tư của khách, tất cả đều cắt bớt tín hiệu. Thực tế mất khoảng 20 tới 40 phần trăm conversion so với số thật. Nhà Gọn thấy Meta báo 60 đơn từ quảng cáo trong tháng, nhưng đối chiếu với hệ thống bán hàng thì có 90 đơn đến từ khách bấm quảng cáo Facebook. Ba mươi đơn biến mất khỏi tầm nhìn của Meta, nên thuật toán của Meta đang tối ưu với thông tin thiếu một phần ba.
Chuẩn hiện nay: hai đường song song, khử trùng lặp
Cách chữa là gửi conversion theo hai đường cùng lúc:
- Đường trình duyệt (Pixel): như cũ, gửi từ trình duyệt khách. Nhanh, có thêm thông tin ngữ cảnh, nhưng bị chặn một phần.
- Đường máy chủ (Conversions API): máy chủ của bạn gửi thẳng conversion tới Meta, không qua trình duyệt. Không bị chặn quảng cáo, bền hơn nhiều.
Chạy cả hai thì bù cho nhau: đường máy chủ vớt lại phần đường trình duyệt bị chặn. Nhưng nảy ra vấn đề mới: khi một khách mua, cả hai đường cùng gửi một conversion, và Meta có thể đếm thành hai.
Khử trùng lặp bằng event_id, bắt buộc
Khi cả Pixel và Conversions API gửi cùng một conversion, bạn phải để Meta hiểu đó là một sự kiện duy nhất. Cơ chế: gửi cùng một tên sự kiện và cùng một mã sự kiện (event_id) ở cả hai đường. Meta thấy hai tín hiệu cùng event_id thì gộp làm một.
Thiếu khử trùng lặp, conversion phồng gấp đôi. Nhà Gọn từng gặp: bật Conversions API mà quên event_id, thế là Meta báo ROAS tăng vọt trong một tuần, ai cũng mừng, rồi phát hiện mỗi đơn bị đếm hai lần. ROAS ảo dẫn tới quyết định tăng ngân sách sai. Luôn kiểm tra trong Meta Events Manager rằng các sự kiện hiện trạng thái đã khử trùng lặp trước khi tin vào số.
Về mặt định nghĩa conversion, nguyên tắc là một nguồn sự thật: định nghĩa sự kiện quan trọng một lần trong GA4 (như đã làm ở series trước), rồi import sang Google Ads, thay vì tạo thẻ chuyển đổi riêng. Nếu mỗi nền tảng có định nghĩa "đơn hàng" riêng, số sẽ loạn.
Quy công: mỗi nền tảng nói tiếng riêng
Quy công là việc gán "công" của một đơn hàng cho các điểm chạm marketing đã dẫn tới nó. Có nhiều mô hình:
| Mô hình | Cách chia công | Điểm mạnh, điểm yếu |
|---|---|---|
| Chạm cuối | 100% cho điểm chạm cuối trước khi mua | Đơn giản, nhưng bỏ qua kênh khám phá |
| Chạm đầu | 100% cho điểm chạm đầu tiên | Thấy kênh mở đầu, bỏ qua kênh chốt |
| Chia đều | Chia đều cho mọi điểm chạm | Công bằng, thiếu trọng số |
| Theo vị trí | 40% đầu, 20% giữa, 40% cuối | Cân cả mở đầu lẫn chốt |
| Theo dữ liệu | Máy học chia theo đóng góp thật | Chính xác hơn, nhưng là hộp đen |
GA4 mặc định dùng mô hình theo dữ liệu. Điểm quan trọng cần chấp nhận: số của GA4, Google Ads và Meta sẽ không bao giờ khớp nhau. Lý do là mỗi nền tảng chỉ thấy phần điểm chạm của mình (Meta không biết khách cũng thấy quảng cáo Google), và mỗi bên dùng cửa sổ quy công khác nhau (khoảng thời gian sau tương tác còn được tính công, ví dụ bấm trong 30 ngày, xem trong 1 ngày).
Đừng ép khớp, hãy chọn một nguồn cho quyết định tổng
Rất nhiều đội tốn hàng giờ cố làm cho số Meta khớp số GA4 khớp số Google Ads. Vô ích, vì chúng đo những thứ khác nhau theo cách khác nhau.
Cách làm đúng: chọn một nguồn để ra quyết định phân bổ ngân sách tổng (thường là GA4 hoặc kho dữ liệu, vì chúng nhìn được cả các kênh), và dùng số của từng nền tảng để tối ưu bên trong nền tảng đó. Khi báo cáo, luôn ghi rõ đang dùng mô hình quy công nào và cửa sổ bao lâu, để cả đội đừng cãi nhau vì số lệch.
ROAS, chi phí giành khách, và thời gian hoàn vốn
Có conversion tin cậy rồi, bạn tính được ba con số ra quyết định ngân sách:
- ROAS: doanh thu chia chi phí quảng cáo. Cho biết một đồng quảng cáo ra mấy đồng doanh thu.
- Chi phí giành một khách (CAC): tốn bao nhiêu để có một khách trả tiền.
- Thời gian hoàn vốn: bao lâu doanh thu từ khách bù lại chi phí giành họ.
Với mô hình bán một lần, ROAS tức thời gần đủ. Nhưng với mô hình mua lặp lại như Nhà Gọn (North Star là khách mua lại), một khách giành được hôm nay còn mua tiếp nhiều tháng sau. Nếu chỉ nhìn ROAS của đơn đầu, Nhà Gọn có thể cắt nhầm một kênh tưởng là lỗ nhưng thực ra lời khi tính cả các đơn mua lại. Luôn tính tới giá trị vòng đời và thời gian hoàn vốn cho mô hình có khách quay lại, đừng chỉ nhìn đơn đầu.
Ba lỗi thường gặp với quảng cáo trả tiền
| Lỗi | Vì sao hại | Cách sửa |
|---|---|---|
| Pixel không kèm Conversions API | Mất 20 tới 40% tín hiệu, thuật toán tối ưu thiếu | Thêm đường máy chủ song song |
| Hai đường không khử trùng lặp | Conversion gấp đôi, ROAS ảo, tăng ngân sách sai | Cùng event_id ở cả hai đường |
| Chỉ nhìn ROAS đơn đầu với mô hình mua lặp | Cắt nhầm kênh tốt | Tính giá trị vòng đời và thời gian hoàn vốn |
Một lưu ý quan trọng về quyền riêng tư: mọi thẻ marketing phải được gác cổng theo consent, và không được gửi thông tin cá nhân thô (email, số điện thoại) mà phải mã hóa theo chuẩn. Đó chính là chủ đề bài 3.
Trước khi sang bài 3
- Trong GA4, đảm bảo các sự kiện quan trọng đã kiểm tra kỹ, rồi import sang Google Ads thay vì tạo thẻ riêng.
- Cài đường máy chủ (Conversions API) song song với Pixel, gửi cùng event_id, và kiểm tra trạng thái đã khử trùng lặp trong Meta.
- So sánh ba mô hình quy công trong GA4 cho đơn hàng chính, ghi lại chúng khác nhau ra sao.
- Lập bảng ROAS, chi phí giành khách và thời gian hoàn vốn theo kênh, ra hai quyết định ngân sách.
Ở bài này ta liên tục nhắc tới consent và không gửi dữ liệu cá nhân thô. Bài 3 đi sâu vào đó: cách xử lý consent cho đúng luật với Consent Mode phiên bản 2, cách nối dữ liệu web với CRM và email một cách hợp pháp, và vì sao làm consent đúng còn giúp giữ được nhiều tín hiệu hơn chứ không chỉ để tuân thủ.
Đọc tiếp
Bài 8, Thử nghiệm và quy công: đo tác động thật của thay đổi
Đây là đỉnh của việc ra quyết định bằng dữ liệu: thay vì tương quan, bạn có nhân quả. Bài cuối series giải thích cách thiết kế thử nghiệm A/B đúng thống kê, các bẫy như nhìn lén kết quả và dừng sớm, và quy công nâng cao gồm tính gia tăng, cách duy nhất đo được quảng cáo có thật sự thêm khách hay không.
Đọc bàiBài 1, Content và SEO analytics: đo nội dung nào thật sự ra khách
Phần lớn doanh nghiệp đo nội dung bằng lượt xem, nên không biết bài nào ra khách. Bài này ghép nửa trước click (Search Console) với nửa sau click (GA4) thành một phễu SEO đầy đủ, giới thiệu ma trận nội dung để quyết định mở rộng hay bỏ, và cách đo tới tận chuyển đổi thay vì dừng ở view.
Đọc bàiBài 3, CRM, email và consent: quyền riêng tư và Consent Mode v2
Dữ liệu bên thứ nhất có consent là tài sản trong thế giới hết cookie bên thứ ba. Bài này giải thích cách nối web với CRM và email qua mã người dùng thay vì email thô, triển khai Consent Mode phiên bản 2 với bốn tín hiệu, phân biệt chế độ cơ bản với nâng cao, và vì sao làm consent đúng còn giúp giữ tín hiệu chứ không chỉ để tuân thủ.
Đọc bài