---
title: Betrugsprävention — Anzeigenbetrug
---
# Anzeigenbetrug
Dies ist ein **Szenario-Leitfaden**. Die Kernintegration ist unverändert — Sie laden
das [Web-SDK](../web-sdk), lesen ein [Urteil](../verdict-reference) und rufen Daten aus
der [Daten-API](../data-api) genau so ab, wie auf diesen Seiten beschrieben. Diese
Seite fügt die wenigen Besonderheiten hinzu, die nur das Anzeigenbetrug-Szenario
benötigt.
Der Schutz vor Anzeigenbetrug filtert Bot- und ungültigen Datenverkehr aus bezahlten
Kampagnen heraus, sodass Werbetreibende und Werbeplattformen für echte Klicks und
Impressionen zahlen — nicht für gefälschtes Volumen. Was es von den anderen
Anwendungsfällen unterscheidet, ist, dass **ein Dritter den Besucher liefert** und
beide Seiten sich auf ein unabhängiges, per-Klick gefälltes Mensch-/Bot-Fazit einigen
müssen.
## Echtzeit-Blockierung an der Quelle
Fraud Prevention läuft inline am Eintrittspunkt und liefert ein Urteil in Echtzeit — es ist kein nachträglicher Bericht. Wer die Seite besitzt, auf der der Besucher landet, kann sofort auf dieses Urteil reagieren:
- **Werbetreibende** betreiben das SDK auf der Landingpage: ungültiger Datenverkehr wird erkannt — und optional mit einem Challenge belegt — in dem Moment, in dem er eintrifft, bevor er in den Funnel gelangt oder die Berichterstattung verzerrt.
- **Traffic-Plattformen** betreiben das SDK auf ihrer eigenen pre-lander- oder Weiterleitungsseite: ein Klick wird verifiziert, *bevor* er weitergeleitet wird, sodass Bots am Eintritt gestoppt werden und nie zu ausgeliefertem Datenverkehr werden.
Die einzige Voraussetzung ist eine Seite, die das SDK ausführen kann: ein Urteil benötigt Browser-Signale, daher hat eine reine serverseitige 302-Weiterleitung keinen Ort, um sie zu erfassen — fügen Sie eine leichtgewichtige Zwischenseite hinzu, und dieselbe Echtzeit-Blockierung greift.
Das signierte Click-Token und die Data API setzen darauf auf, um beide Seiten abzustimmen; die Echtzeit-Inline-Blockierung ist der primäre Mechanismus, und das nachträgliche API-Scrubbing ist der Rückfall für Datenverkehr ohne Zwischenseite.
## Die zwei Rollen
- **Werbetreibender (Advertiser)** — besitzt die Landingpage, auf der der Besucher
ankommt. Betreibt das Web-SDK auf dieser Seite, um ein Urteil für jeden eintreffenden
Besuch zu erhalten, und ruft Urteile aus der Daten-API ab, um abzustimmen, wofür ihm
in Rechnung gestellt wurde.
- **Anbieter (Provider)** (Datenverkehrs-/Werbequelle) — liefert den Klick. Er muss die
**Qualität dessen, was er gesendet hat, nachweisen**, also stellt er pro Klick ein
Click-Token aus und verknüpft später seinen Lieferbericht mit den unabhängigen
Urteilen.
Beide Seiten authentifizieren sich gegenüber der [Daten-API](../data-api) mit ihren
eigenen Anwendungsanmeldedaten und lesen dasselbe Per-Klick-Urteil, was es ihnen
ermöglicht, sich abzustimmen, ohne den Rohlogs der jeweils anderen Seite vertrauen zu
müssen.
## Ende-zu-Ende-Ablauf
Die folgende Sequenz zeigt, wie ein Klick von der Lieferung des Anbieters über den
Besucher und die Landingpage des Werbetreibenden bis zu einem einzigen Urteil
gelangt, das **beide Konten später von ihrer eigenen Seite lesen**.
```mermaid
sequenceDiagram
autonumber
participant P as Anbieter (Konto B)
participant V as Besucher
participant A as Werbetreibenden-Seite + SDK
participant F as Betrugsprävention-API
P->>P: click_token signieren (bot_kid + secret, trägt pkid)
P->>V: Link mit ?_ctk=click_token ausliefern
V->>A: Klick → Landen auf Werbetreibenden-Seite (URL trägt _ctk)
A->>A: SDK liest _ctk aus der URL
A->>F: Verschlüsselter POST /bot/verify
(app_key = Werbetreibender, click_token = vom Anbieter signiert)
F->>F: app_key → advertiser_app_id,
pkid verifizieren → provider_app_id, Urteil fällen,
eine Zeile mit beiden app_ids schreiben
F-->>A: verdict → onVerdict
A->>A: Gemäß verdict.action behandeln (aufzeichnen / blockieren / Challenge)
Note over P,F: Abstimmung (kontenübergreifend)
A->>F: GET /v1/bot mit Werbetreibenden-App-Key
F-->>A: Dieselbe Zeile (über advertiser_app_id abgeglichen)
P->>F: GET /v1/bot mit Anbieter-App-Key
F-->>P: Dieselbe Zeile (über provider_app_id abgeglichen)
```
Die entscheidende Eigenschaft: **beide app_ids liegen in derselben Zeile.** Der
Werbetreibende liest sie über `advertiser_app_id` abgeglichen, der Anbieter liest sie
über `provider_app_id` abgeglichen — zwei verschiedene Konten, jedes mit seinem eigenen
App-Key abfragend, jedes beim selben unabhängigen Urteil landend. Keine Seite muss die
Rohlogs der anderen offenlegen oder ihnen vertrauen, um sich darüber zu einigen, was
bei einem bestimmten Klick geschehen ist.
## Click-Tokens
Ein **Click-Token** verknüpft einen vom Anbieter gelieferten Klick mit dem Urteil, das
der Besuch letztlich erhält. Es ist der Per-Klick-Bezeichner, auf den sich beide
Parteien einigen. Die anderen Betrugsprävention-Anwendungsfälle brauchen keine
Click-Tokens — sie stimmen Urteile ohne sie ab.
Der Ablauf:
1. **Ausstellen** — der Anbieter erhält ein signiertes Click-Token (eins pro Klick),
wenn er einen Besucher zur Landingpage des Werbetreibenden leitet.
2. **In der Ziel-URL mitführen** — hängen Sie das ausgestellte Token als
Query-Parameter an die Landing-URL an:
```
https://advertiser.example/lp?click_token=ct_xxxxxxxx
```
3. **Auf der Seite lesen** — das [Web-SDK](../web-sdk) liest das Token automatisch aus
der URL. Wenn Sie einen anderen Parameternamen verwenden, setzen Sie `tokenParam`:
```js
BotSignal.init({ appKey: 'YOUR_APP_KEY', tokenParam: 'click_token' });
```
4. **Abstimmen** — schlagen Sie den Klick später über die Daten-API nach und verknüpfen
Sie ihn wieder mit dem Lieferbericht des Anbieters.
::: info
Das Token ist bereits signiert, wenn es Ihnen ausgestellt wird — Sie müssen es nur
**bis zur Landing-URL durchführen**. Auf Ihrer Seite gibt es nichts zu signieren oder
zu berechnen.
:::
### `tokenParam`-Option
Das Web-SDK erhält in diesem Szenario eine zusätzliche Option:
| Option | Typ | Standard | Beschreibung |
| --- | --- | --- | --- |
| `tokenParam` | string | automatisch erkannt | Name des URL-Query-Parameters, der das Anbieter-Click-Token trägt (z. B. `click_token`). Das SDK liest ihn aus der Seiten-URL und verknüpft das Urteil mit diesem Klick. Lassen Sie ihn unbesetzt, wenn Sie keine Click-Tokens verwenden. |
## Abstimmung & Abrechnung
Sobald Besuche ein Click-Token tragen, einigen sich beide Seiten auf dieselben
unabhängigen Urteile:
- **Das Urteil eines einzelnen Klicks abrufen** — zum Beispiel um einen Klick
anzufechten oder zu bestätigen:
```bash
GET /v1/bot/verdict?click_token=ct_xxx
X-App-Key: YOUR_APP_KEY
X-App-Secret: YOUR_APP_SECRET
```
- **Zeilen pro Klick exportieren** — rufen Sie einen Zeitraum ab und verknüpfen Sie das
`click_token` jeder Zeile wieder mit Ihren eigenen Klick-Logs:
```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
```
Jede Zeile trägt das `click_token` des Besuchs (sofern vorhanden), den Zeitstempel
und die Urteilsfelder (`is_bot`, `score`, `level`, `action`).
Der Werbetreibende schließt markierte und Bot-Klicks aus dem aus, wofür er zahlt; der
Anbieter stimmt seinen Lieferbericht mit denselben Fazits ab. Da beide das **gleiche
unabhängige Urteil** lesen, hängt die Abrechnung nicht von den Rohlogs einer der beiden
Seiten ab.
## Sicherheitsmodell
Die `cid` und das Click-Token reisen in der URL mit, behandle sie daher als Bezeichner — nicht als Anmeldedaten:
- **Das Lesen eines Urteils erfordert App-Key + App-Secret.** Die Data API authentifiziert jeden Aufruf mit deinem App-Secret (in konstanter Zeit verglichen) und gibt nur Zeilen zurück, in denen deine App der Advertiser oder der Provider ist. Eine `cid` allein ruft nichts ab — ein Dritter, der sie aus der URL kopiert, hat kein Secret und ist keine Partei der Zeile.
- **Der Provider ist durch Signatur gebunden.** Das Click-Token ist HMAC-signiert mit dem Secret des Providers und trägt dessen `pkid`; es kann nicht gefälscht werden, und eine `cid` kann nur einmal beansprucht werden (Replay-geschützt).
- **Optional auch den Advertiser binden.** Signiere den `app_key` des Ziel-Advertisers als `aud` in das Token. Die Verifizierung verlangt dann, dass der app_key der Seite mit `aud` übereinstimmt, sodass ein für Advertiser A ausgestelltes Token kein Urteil bei Advertiser B zuordnen kann. Lässt du `aud` weg, darf jede Advertiser-Seite das Token annehmen.
Nettoeffekt: Ein Urteil für eine `cid` ist nur für die beiden daran gebundenen Apps lesbar — den Advertiser, dessen Seite das SDK ausführte, und den Provider, dessen Token vorgelegt wurde — wobei sich jeder mit seinem eigenen App-Secret authentifiziert.
## Nächste Schritte
- [Web-SDK](../web-sdk) — Urteile auf der Landingpage sammeln
- [Verdict-Referenz](../verdict-reference) — jedes Feld und wie Sie darauf reagieren
- [Daten-API](../data-api) — Urteile serverseitig abrufen und abstimmen