Anzeigenbetrug

Dies ist ein Szenario-Leitfaden. Die Kernintegration ist unverändert — Sie laden das Web-SDK, lesen ein Urteil und rufen Daten aus der Daten-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 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.

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 liest das Token automatisch aus der URL. Wenn Sie einen anderen Parameternamen verwenden, setzen Sie tokenParam:

   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:

  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:

  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.

Nächste Schritte

• Web-SDK — Urteile auf der Landingpage sammeln
• Verdict-Referenz — jedes Feld und wie Sie darauf reagieren
• Daten-API — Urteile serverseitig abrufen und abstimmen