広告不正

これは シナリオガイド です。コア連携は変わりません——Web SDK を読み込み、判定を読み、Data API からデータを取得する、というそれらのページに記載のとおりです。本ページでは、広告不正シナリオだけが必要とするわずかな固有要素を補足します。

広告不正対策は、ボットと無効トラフィックを有料投放から締め出し、広告主と広告プラットフォームが本物のクリックとインプレッションに対してのみ——虚偽のボリュームではなく——支払うようにします。他のユースケースと異なる点は、訪問者を第三者が届ける ことであり、双方が独立したクリック単位の人間 / ボット結論で合意する必要があることです。

源流でのリアルタイム遮断

Fraud Prevention はエントリーポイントで inline に動作し、判定をリアルタイムで返します——事後レポートではありません。訪問者が着地するページを所有する者は、その判定に基づいて即座に対処できます：

広告主 はランディングページで SDK を実行します：無効トラフィックは到達した瞬間に検出され——オプションで Challenge を提示——ファネルに入る前、レポートを歪める前に止められます。
トラフィックプラットフォーム は自前の pre-lander またはリダイレクトページで SDK を実行します：クリックは転送される前に検証されるため、ボットは入口で止められ、配信トラフィックになることはありません。

唯一の前提は、SDK を実行できるページがあることです：判定にはブラウザ信号が必要なため、純粋なサーバーサイドの 302 にはそれを収集する場所がありません——軽量な中間ページを 1 枚追加すれば、同じリアルタイム遮断が適用されます。

署名済み click token と Data API はその上に乗り、両サイドの突き合わせを行います。リアルタイムの inline 遮断が主要なメカニズムであり、事後の API スクラビングは中間ページがないトラフィック向けのフォールバックです。

2 つの役割

広告主（Advertiser） — 訪問者が到達するランディングページを所有します。そのページ上で Web SDK を実行して到達する各アクセスの判定を取得し、Data API から判定を取得して、自分が課金された分を突き合わせます。
サービス提供者（Provider、トラフィック / 広告ソース） — クリックを配信します。 自分が送ったものの品質を証明する 必要があるため、クリックごとにクリックトークンを発行し、後で自分の配信レポートを独立した判定と突き合わせます。

双方は自分のアプリケーション認証情報で Data API に認証し、同じクリック単位の判定を読み取ります。これにより、互いの生ログを信頼せずとも突き合わせができます。

エンドツーエンドのフロー

下のシーケンスは、1 つのクリックが provider の配信から、訪問者と広告主のランディングページを経て、両アカウントが後にそれぞれ自分の側から読み取る 単一の判定に至るまでを示します。

決定的な性質はこうです。両方の app_id が同じ行に存在します。 広告主は advertiser_app_id で一致させてそれを読み、provider は provider_app_id で一致させてそれを読みます——2 つの異なるアカウントが、それぞれ自分の App-Key で問い合わせ、それぞれ同じ独立した判定に着地します。どちらの側も、あるクリックで何が起きたかについて合意するために、相手の生ログを露出させたり信頼したりする必要はありません。

クリックトークン

クリックトークン（click token） は、provider が配信したクリックを、そのアクセスが最終的に受け取る判定と結びつけます。これは双方が精算の拠り所とするクリック単位の識別子です。不正対策の他のユースケースはクリックトークンを必要としません——それらはトークンなしで判定を突き合わせます。

フロー：

発行 — provider は、訪問者を広告主のランディングページへルーティングする際に、署名済みのクリックトークン（クリックごとに 1 つ）を取得します。
遷移先 URL に付与する — 発行されたトークンを、ランディング URL にクエリパラメータとして付与します。
```
https://advertiser.example/lp?click_token=ct_xxxxxxxx
```
ページで読み取る — Web SDK が URL からトークンを自動的に読み取ります。別のパラメータ名を使う場合は tokenParam を設定します。
js
```
BotSignal.init({ appKey: 'YOUR_APP_KEY', tokenParam: 'click_token' });
```
突き合わせる — 後で Data API 経由でそのクリックを照会し、provider の配信レポートに結合します。

INFO

トークンはあなたに発行される時点で既に署名済みです——あなたは それをランディング URL までそのまま運ぶ だけでよいのです。あなたの側で署名や計算を行うものは何もありません。

`tokenParam` オプション

このシナリオでは、Web SDK に追加のオプションが 1 つ加わります。

オプション	型	デフォルト	説明
`tokenParam`	string	自動検出	provider のクリックトークンを運ぶ URL クエリパラメータの名前（例：`click_token`）。SDK がそれをページ URL から読み取り、判定をそのクリックに結びつけます。クリックトークンを使わない場合は未設定のままにします。

突き合わせと精算

アクセスがクリックトークンを運ぶようになると、双方は同じ独立した判定で精算します。

単一クリックの判定を取得する — 例えば 1 つのクリックを争う、または確認する場合：
bash
```
GET /v1/bot/verdict?click_token=ct_xxx
X-App-Key: YOUR_APP_KEY
X-App-Secret: YOUR_APP_SECRET
```
クリック単位の行をエクスポートする — 時間範囲を取得し、各行の click_token をあなた自身のクリックログに結合します：
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
```
各行は、そのアクセスの click_token（存在する場合）、タイムスタンプ、判定フィールド（is_bot、score、level、action）を含みます。

広告主はフラグ付き／ボットのクリックを支払い対象から除外し、provider は同じ結論に対して自分の配信レポートを突き合わせます。双方が読むのは 同じ独立した判定 なので、精算はどちらの側の生ログにも依存しません。

次のステップ

Web SDK — ランディングページで判定を収集する
Verdict リファレンス — すべてのフィールドと、その対処方法
Data API — サーバーサイドで判定を取得・突き合わせる

広告不正 ​

源流でのリアルタイム遮断 ​

2 つの役割 ​

エンドツーエンドのフロー ​

クリックトークン ​

tokenParam オプション ​

突き合わせと精算 ​

次のステップ ​