Chống gian lận quảng cáo

Đây là một hướng dẫn theo kịch bản. Phần tích hợp cốt lõi không thay đổi — bạn tải Web SDK, đọc một phán quyết, và kéo dữ liệu từ Data API đúng như được mô tả trong những trang đó. Trang này bổ sung vài chi tiết mà chỉ kịch bản chống gian lận quảng cáo cần.

Bảo vệ chống gian lận quảng cáo lọc bot và lưu lượng không hợp lệ ra khỏi các chiến dịch trả phí, để nhà quảng cáo và nền tảng quảng cáo trả tiền cho những lượt nhấp và hiển thị thật — chứ không phải lượng giả. Điều khiến nó khác với các trường hợp sử dụng khác là một bên thứ ba gửi khách truy cập đến, và cả hai bên cần thống nhất trên một kết luận người thật / bot độc lập, theo từng lượt nhấp.

Chặn theo thời gian thực ngay tại nguồn

Fraud Prevention chạy inline tại điểm vào và trả về phán quyết theo thời gian thực — nó không phải là báo cáo hậu kỳ. Ai sở hữu trang mà khách truy cập đáp xuống đều có thể hành động theo phán quyết đó ngay lập tức:

• Nhà quảng cáo chạy SDK trên trang đích: lưu lượng không hợp lệ bị phát hiện — và tùy chọn được đưa ra challenge — ngay khi nó đến, trước khi nó vào phễu hay làm sai lệch báo cáo.
• Nền tảng lưu lượng chạy SDK trên pre-lander hoặc trang chuyển hướng của chính họ: một lượt nhấp được xác minh trước khi được chuyển tiếp, nên bot bị chặn ngay tại cửa vào và không bao giờ trở thành lưu lượng đã phân phối.

Yêu cầu duy nhất là một trang có thể chạy SDK: một phán quyết cần tín hiệu trình duyệt, nên một 302 thuần phía máy chủ không có chỗ nào để thu thập chúng — thêm một trang trung gian nhẹ và cơ chế chặn theo thời gian thực tương tự sẽ được áp dụng.

Click token đã ký và Data API nằm bên trên để đối soát giữa cả hai bên; chặn inline theo thời gian thực là cơ chế chính, còn việc làm sạch qua API về sau là phương án dự phòng cho lưu lượng không có trang trung gian.

Hai vai trò

• Nhà quảng cáo (Advertiser) — sở hữu trang đích mà khách truy cập đáp xuống. Chạy Web SDK trên trang đó để lấy một phán quyết cho mỗi lượt truy cập đến, và kéo phán quyết từ Data API để đối soát phần mình bị tính phí.
• Nhà cung cấp (Provider, nguồn lưu lượng / quảng cáo) — gửi lượt nhấp đến. Bên này cần chứng minh chất lượng của những gì mình đã gửi, nên họ phát hành một click token cho mỗi lượt nhấp và sau đó nối báo cáo phân phối của mình với các phán quyết độc lập.

Cả hai bên xác thực với Data API bằng thông tin xác thực ứng dụng của riêng mình và đọc cùng một phán quyết theo từng lượt nhấp, đó chính là điều cho phép họ đối soát mà không cần tin vào nhật ký thô của bên kia.

Luồng đầu cuối

Sơ đồ trình tự bên dưới cho thấy một lượt nhấp di chuyển như thế nào từ lúc nhà cung cấp gửi đi, qua khách truy cập và trang đích của nhà quảng cáo, đến một phán quyết duy nhất mà cả hai tài khoản sau đó đều đọc được từ phía của mình.

Thuộc tính then chốt: cả hai app_id nằm trên cùng một dòng. Nhà quảng cáo đọc nó bằng cách khớp theo advertiser_app_id, nhà cung cấp đọc nó bằng cách khớp theo provider_app_id — hai tài khoản khác nhau, mỗi bên truy vấn bằng App-Key của riêng mình, mỗi bên cùng đáp xuống một phán quyết độc lập. Không bên nào phải để lộ hay tin vào nhật ký thô của bên kia để thống nhất về điều đã xảy ra cho một lượt nhấp nhất định.

Click token

Một click token gắn lượt nhấp được nhà cung cấp gửi đi với phán quyết mà lượt truy cập cuối cùng nhận được. Đó là định danh theo từng lượt nhấp mà cả hai bên thanh toán dựa trên nó. Các trường hợp sử dụng Fraud Prevention khác không cần click token — chúng đối soát phán quyết mà không dùng đến nó.

Luồng:

1. Phát hành — nhà cung cấp lấy một click token đã ký (mỗi lượt nhấp một cái) khi định tuyến khách truy cập về trang đích của nhà quảng cáo.

2. Mang nó trên URL đích — nối token đã phát hành vào URL đích dưới dạng tham số truy vấn:

   https://advertiser.example/lp?click_token=ct_xxxxxxxx

3. Đọc nó trên trang — Web SDK tự động đọc token từ URL. Nếu bạn dùng một tên tham số khác, hãy đặt tokenParam:

   BotSignal.init({ appKey: 'YOUR_APP_KEY', tokenParam: 'click_token' });

4. Đối soát — tra cứu lượt nhấp sau đó qua Data API và nối nó trở lại với báo cáo phân phối của nhà cung cấp.

INFO

Token đã được ký sẵn khi nó được phát hành cho bạn — bạn chỉ cần mang nó tới URL đích. Không có gì để ký hoặc tính toán ở phía bạn.

Tùy chọn tokenParam

Trong kịch bản này, Web SDK có thêm một tùy chọn:

Tùy chọn	Kiểu	Mặc định	Mô tả
tokenParam	string	tự động nhận diện	Tên của tham số truy vấn trên URL mang click token của nhà cung cấp (ví dụ click_token). SDK đọc nó từ URL của trang và gắn phán quyết với lượt nhấp đó. Cứ để mặc định nếu bạn không dùng click token.

Đối soát & thanh toán

Một khi các lượt truy cập mang theo một click token, cả hai bên thanh toán dựa trên cùng những phán quyết độc lập:

• Lấy phán quyết của một lượt nhấp đơn lẻ — ví dụ để khiếu nại hoặc xác nhận một lượt nhấp:

  GET /v1/bot/verdict?click_token=ct_xxx
  X-App-Key: YOUR_APP_KEY
  X-App-Secret: YOUR_APP_SECRET

• Xuất các dòng theo từng lượt nhấp — kéo một khoảng thời gian và nối click_token của mỗi dòng trở lại với nhật ký lượt nhấp của chính bạn:

  GET /v1/bot/export?from=2026-06-01&to=2026-06-30&format=csv
  X-App-Key: YOUR_APP_KEY
  X-App-Secret: YOUR_APP_SECRET

  Mỗi dòng mang click_token của lượt truy cập (khi có), dấu thời gian, và các trường phán quyết (is_bot, score, level, action).

Nhà quảng cáo loại các lượt nhấp bị gắn cờ và lượt nhấp bot khỏi phần mình trả tiền; nhà cung cấp đối soát báo cáo phân phối của mình với cùng những kết luận đó. Vì cả hai đều đọc cùng một phán quyết độc lập, việc thanh toán không phụ thuộc vào nhật ký thô của bất kỳ bên nào.

Bước tiếp theo

• Web SDK — thu thập phán quyết trên trang đích
• Tham chiếu phán quyết — mọi trường và cách hành động với nó
• Data API — kéo và đối soát phán quyết ở phía máy chủ