Đo đơn thật và quy công quảng cáo

Phạm vi tài liệu: dựa trên bản mô phỏng KétSuite Ads. Các số liệu, kết nối, AI và hành động trên nền tảng đều là minh họa; tài liệu không xác nhận tính năng đã phát hành.

Một lượt chuyển đổi chưa chắc là một đơn mua#

Lượt nhấp, gửi form, cuộc gọi và đơn thanh toán là những mốc khác nhau. KétSuite Ads lấy đơn mua đã đối soát làm căn cứ đọc hiệu quả, bổ sung kênh chốt từ Website, KétChat và KétPhone. “Chính xác” ở đây là có thể truy ngược bằng chứng và giải thích chênh lệch; không phải lời hứa nhận diện được mọi khách hoặc mọi lần tiếp xúc.

Trong mock, doanh thu xác thực là doanh thu đơn đã thanh toán, ghép nguồn quảng cáo và trừ hoàn hủy. ROAS xác thực = doanh thu xác thực / chi tiêu quảng cáo. CPA = chi tiêu / số đơn tương ứng. Luôn dùng cùng phạm vi và kỳ; nếu chưa có đơn hoặc chưa đối soát đủ thì chưa có cơ sở kết luận hiệu quả.

Vì sao báo cáo nền tảng và báo cáo đơn khác nhau?#

Một đơn có thể được nhiều nền tảng nhận công; khách chuyển thiết bị hoặc chốt qua điện thoại; đơn hoàn/hủy xuất hiện sau báo cáo; nguồn có thể gửi thiếu hoặc trùng. Sự chênh lệch phải được phân loại. Không được coi toàn bộ doanh thu nền tảng tự báo là doanh thu tăng thêm do Ads tạo ra.

Ảnh mock: danh sách dùng để chọn đơn cần đối soát. Kênh chốt đơn và nguồn quảng cáo cần được đọc cùng nhau; chúng không phải một khái niệm.

Đọc các vùng đánh số trên ảnh:

1. Cần đối soát: chọn nhóm đơn chưa đủ căn cứ thay vì rà toàn bộ danh sách.
2. Kỳ báo cáo và bộ lọc: giữ cùng kỳ, nền tảng và kênh chốt khi so sánh số liệu.
3. Đơn DH-24102: bấm mã đơn để xem hành trình; nguồn đang là gợi ý của AI, cần kiểm bằng chứng trước khi gán.

Lập bảng giải thích chênh lệch thay vì ép hai báo cáo bằng nhau#

Bảng phân rã cần giữ các nguyên nhân không trùng nhau. Đây là cách phân tích đề xuất, chưa phải một báo cáo phân rã tự động trong mock.

flowchart TD
 A["Số nền tảng tự nhận công"] --> B["Cố định tài khoản, kỳ và định nghĩa"]
 B --> C["Đối chiếu từng bản ghi"]
 C --> D["Đủ căn cứ, giá trị đúng"]
 C --> E["Trùng, hoàn/hủy hoặc lệch phạm vi"]
 C --> F["Chưa giải thích được"]
 D --> G["Doanh thu đã đối soát"]
 E --> H["Điều chỉnh đúng nguyên nhân"]
 F --> I["Giữ riêng, giao người rà"]
 H --> G
 I -.->|Khi có thêm bằng chứng| C
 class D,G kv-positive
 class F,I kv-warning
 class E kv-danger

Trước khi so số, cố định tài khoản, kỳ, múi giờ, loại chuyển đổi và cách xử lý hoàn/hủy. Sau đó tách ba lớp: nền tảng nhận công, doanh nghiệp có đơn mua thật, và đơn đã đủ căn cứ ghép nguồn quảng cáo. Một đơn có thể xuất hiện ở hai lớp đầu nhưng chưa ở lớp thứ ba. Số thấp hơn không tự chứng minh hệ thống đo kém; số cao hơn không tự chứng minh kinh doanh tốt.

Ví dụ đối soát giả định: nền tảng báo 500 triệu đồng. Sau khi rà một tập bản ghi, doanh nghiệp xác định 30 triệu nhận công trùng, 20 triệu hoàn/hủy, 15 triệu chênh phạm vi/kỳ và 25 triệu chưa đủ căn cứ nguồn; còn 410 triệu đã đối soát. Phép trừ này chỉ hợp lệ khi mỗi khoản được xếp vào một nguyên nhân duy nhất theo thứ tự đã thống nhất. Nếu đơn hoàn tiền đồng thời bị nhận công trùng, không trừ ở cả hai dòng. Đây là ví dụ giải thích, không phải bảng phân rã 491 triệu trên ảnh và cũng không phải báo cáo tự động đã có trong mock.

Phần “chưa rõ” phải được giữ riêng với người xử lý và mốc rà lại. Không gán nguồn bằng tay chỉ để bảng khớp; việc đó có thể làm ROAS trông đầy đủ hơn nhưng giảm chất lượng tín hiệu cho quyết định sau. Trong Ads, mở từng đơn để xem thanh toán, kênh chốt, nguồn được gợi ý và bằng chứng hành trình; dùng Quy công & đối soát để đối chiếu kết quả theo phạm vi đang xem.

Đừng so một kỳ đã đủ đơn với một kỳ còn đang ghi nhận#

Khách có thể nhấp hôm thứ Hai, gọi thứ Tư rồi thanh toán thứ Sáu. Chi phí đã xuất hiện trước khi đơn đủ điều kiện ghi nhận. Thêm độ trễ đồng bộ và đối soát, ROAS của những ngày gần hiện tại có thể thấp hơn khi nhìn lại sau đó. Google cũng mô tả conversion lag có thể làm CPA tạm cao và ROAS tạm thấp trong báo cáo. Nguồn: Google Ads — conversion lag.

Khi có chênh lệch giữa hệ thống, kiểm ngày đang được dùng là ngày tương tác hay ngày mua. Với chuyển đổi nhập từ Analytics, Google nêu cách ghi nhận theo ngày tương tác trong Google Ads khác với ngày xảy ra sự kiện trong Analytics. Không nên lấy hai cột khác cơ sở ngày để kết luận thiếu đơn. Nguồn: Google Ads — dữ liệu chuyển đổi từ Analytics.

Quy trình đề xuất là lưu mốc đọc số, rồi đọc lại cùng phạm vi sau khoảng thời gian phù hợp với chu kỳ chốt thực tế. Tách thay đổi do đơn về muộn khỏi thay đổi do hoạt động quảng cáo mới. Không có một số ngày chờ chuẩn cho mọi doanh nghiệp; mock chưa tự tính độ chín của từng nhóm dữ liệu hay dự báo chuyển đổi đến muộn.

Xử lý một đơn chưa rõ nguồn#

Luồng đối soát giữ riêng sự thật rằng có đơn mua và kết luận rằng quảng cáo nào được ghi nhận. Không đủ căn cứ thì giữ chưa rõ nguồn.

flowchart TD
 A["Mở đơn và hành trình mua"] --> B("Thanh toán và giá trị đã đúng?"):::kv-decision
 B -->|Chưa| C["Đối chiếu đơn, hoàn/hủy trước"]
 B -->|Đúng| D["Đọc tín hiệu Website, KétChat, KétPhone"]
 D --> E("Đủ căn cứ nguồn quảng cáo?"):::kv-decision
 E -->|Chưa| F["Giữ chưa rõ nguồn; bổ sung bằng chứng"]
 E -->|Đủ| G["Xác nhận nguồn trong phạm vi đối soát"]
 G --> H["Kiểm doanh thu ghi nhận và nhật ký"]
 H --> I("Phát hiện gán sai?"):::kv-decision
 I -->|Có| J["Hoàn tác nếu còn khả dụng, đối soát lại"]
 I -->|Không| K["Dùng số đã đối soát cho quyết định"]
 class C,F,J kv-warning
 class K kv-positive

1. Mở Đơn hàng & chuyển đổi, chọn đơn còn thiếu căn cứ quy công.
2. Xem hành trình đơn: tín hiệu quảng cáo, Website, hội thoại hoặc cuộc gọi, thanh toán và phần hoàn/hủy nếu có.
3. Đối chiếu nguồn thực tế. Mock có tình huống đơn chốt qua KétPhone thiếu mã lượt nhấp và cho gán chiến dịch sau khi xem bằng chứng.
4. Kiểm lại kết quả trong Quy công & đối soát và nhật ký. Nếu gán sai, dùng hoàn tác còn khả dụng.

Gán nguồn thủ công là một quyết định đối soát, không biến suy đoán thành bằng chứng về tác động nhân quả. Khi không đủ thông tin, giữ trạng thái chưa rõ nguồn để đội ngũ xử lý tiếp.

Làm sạch tín hiệu trước khi gửi ngược#

Nguồn tín hiệu cho biết luồng Website, KétChat, KétPhone có hoạt động đúng kỳ vọng hay không. Chất lượng chuyển đổi tách tín hiệu nghi vấn để kiểm tra, giữ bằng chứng gốc và bảo vệ đơn đã thanh toán. Thiếu đồng ý thì không gửi; cùng nền tảng và khóa đơn chỉ gửi một lần trong mô hình mock. Một sự kiện đã gửi không thể được xem là tự động thu hồi chỉ vì đổi kết luận nội bộ.

Đơn hoàn/hủy sau khi đã gửi chuyển đổi#

Khi đơn đã gửi về nền tảng rồi mới hoàn tiền, khả năng sửa lại khác nhau theo nền tảng. Bảng Sự kiện gửi đi trong hành trình đơn ghi rõ kết quả cho từng đích:

Vì vậy, khi số nền tảng tự báo cao hơn doanh thu xác thực, phần chênh có thể gồm cả các đơn đã hoàn mà nền tảng không cho rút lại. Quyết định ngân sách nên dựa trên số đã đối soát trong Két. Google mô tả hai cách điều chỉnh là rút lại (retraction) và sửa giá trị (restatement). Nguồn: Google Ads — About conversion adjustments.

Xếp ưu tiên dữ liệu theo quyết định đang bị ảnh hưởng#

Tỷ lệ khớp cao chỉ mô tả khả năng ghép theo cách đo hiện tại. Nó không chứng minh quảng cáo gây ra đơn mua, không chứng minh đồng ý hợp lệ và không thay thế kiểm toán chất lượng. Đó là lý do thử nghiệm đối chứng vẫn cần thiết ngay cả khi báo cáo quy công đã rất đầy đủ.

Dùng số liệu để quyết định#

Nếu một kênh đem lại nhiều cuộc trò chuyện nhưng ít đơn thanh toán, kiểm chất lượng lead và quy trình chốt. Nếu đơn tốt nhưng thiếu ghép nguồn, ưu tiên sửa kết nối đo lường; cắt ngân sách ngay có thể làm mất một nguồn bán hàng hiệu quả. Khi muốn biết phần tăng trưởng nào thật sự do tối ưu tạo ra, chuyển sang thử nghiệm đối chứng.