---
title: Fraud Prevention — Chống gian lận quảng cáo
---
# 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](../web-sdk), đọc một [phán quyết](../verdict-reference), và kéo dữ liệu từ
[Data API](../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](../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**.
```mermaid
sequenceDiagram
autonumber
participant P as Nhà cung cấp (tài khoản B)
participant V as Khách truy cập
participant A as Trang nhà quảng cáo + SDK
participant F as Fraud Prevention API
P->>P: Ký click_token (bot_kid + secret, mang theo pkid)
P->>V: Gửi link kèm ?_ctk=click_token
V->>A: Nhấp → đáp xuống trang nhà quảng cáo (URL mang _ctk)
A->>A: SDK đọc _ctk từ URL
A->>F: POST mã hóa /bot/verify
(app_key = nhà quảng cáo, click_token = do nhà cung cấp ký)
F->>F: app_key → advertiser_app_id,
xác minh pkid → provider_app_id, ra phán quyết,
ghi một dòng mang cả hai app_id
F-->>A: verdict → onVerdict
A->>A: Xử lý theo verdict.action (ghi nhận / chặn / challenge)
Note over P,F: Đối soát (xuyên tài khoản)
A->>F: GET /v1/bot với App-Key của nhà quảng cáo
F-->>A: Cùng một dòng (khớp theo advertiser_app_id)
P->>F: GET /v1/bot với App-Key của nhà cung cấp
F-->>P: Cùng một dòng (khớp theo provider_app_id)
```
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](../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`:
```js
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:
```bash
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:
```bash
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.
## Mô hình bảo mật
`cid` và click token đi trong URL, vì vậy hãy coi chúng là định danh — không phải thông tin xác thực:
- **Đọc một phán quyết cần App-Key + App-Secret.** Data API xác thực mọi lệnh gọi bằng app secret của bạn (so sánh theo thời gian hằng số) và chỉ trả về các hàng mà ứng dụng của bạn là advertiser hoặc provider. Một `cid` đơn lẻ không lấy được gì — một bên thứ ba sao chép nó từ URL không có secret và không phải là một bên của hàng đó.
- **provider bị ràng buộc bằng chữ ký.** Click token được ký HMAC bằng secret của provider và mang `pkid` của provider; nó không thể bị giả mạo, và một `cid` chỉ có thể được nhận một lần (chống phát lại).
- **Tùy chọn ràng buộc cả advertiser.** Ký `app_key` của advertiser đích vào token dưới dạng `aud`. Khi đó việc xác minh yêu cầu app_key của trang khớp với `aud`, nên một token cấp cho advertiser A không thể quy phán quyết cho advertiser B. Bỏ `aud` thì bất kỳ trang advertiser nào cũng có thể chấp nhận token.
Hiệu quả thực: phán quyết cho một `cid` chỉ có thể đọc được bởi hai ứng dụng được ràng buộc với nó — advertiser có trang đã chạy SDK và provider có token được xuất trình — mỗi bên xác thực bằng App-Secret của riêng mình.
## Bước tiếp theo
- [Web SDK](../web-sdk) — thu thập phán quyết trên trang đích
- [Tham chiếu phán quyết](../verdict-reference) — mọi trường và cách hành động với nó
- [Data API](../data-api) — kéo và đối soát phán quyết ở phía máy chủ