---
title: Betrugsprävention — Verdict-Referenz
---

# Verdict-Referenz

Jedes Betrugsprävention-Urteil — ob an Ihren `onVerdict`-Callback im
[Web-SDK](./web-sdk) geliefert oder aus der [Daten-API](./data-api) abgerufen — ist
dasselbe `BotVerdict`-Objekt. Diese Seite dokumentiert jedes Feld und wie Sie darauf
reagieren.

```json
{
  "is_bot": false,
  "score": 18,
  "level": "low",
  "action": "record_only",
  "consistency": { "ok": true },
  "degraded": false
}
```

## Felder

| Feld | Typ | Beschreibung |
| --- | --- | --- |
| `is_bot` | boolean | Das Haupturteil. `true` = der Besuch wird als automatisierter oder ungültiger Datenverkehr beurteilt; `false` = er sieht nach einer echten Person aus. Dies ist das eine Feld, auf das die meisten Integrationen verzweigen. |
| `score` | number (0–100) | Wie verdächtig der Besuch ist. **Höher bedeutet verdächtiger.** Nutzen Sie ihn, um Ihre eigenen Schwellenwerte zu setzen — z. B. Besuche oberhalb einer von Ihnen gewählten Grenze auszuschließen. Der genaue Wert wird von unserem Risikomodell erzeugt und ist nicht dafür gedacht, rückentwickelt zu werden. |
| `level` | enum | Grobe Einstufung des `score`: `low`, `medium`, `high`, `critical`. Praktisch, wenn Sie Kategorien statt einer Rohzahl möchten. |
| `action` | enum | Unsere **empfohlene Behandlung** für den Besuch: `record_only`, `challenge` oder `flag`. Siehe unten. |
| `consistency` | object | Ein signalübergreifendes Konsistenzfazit. Lesen Sie `consistency.ok` (boolean): `true` = die Signale des Besuchs passen wie erwartet zusammen; `false` = etwas ergab keinen Sinn und der Besuch verdient zusätzliche Prüfung. Die interne Aufschlüsselung hinter diesem Fazit wird nicht offengelegt. |
| `degraded` | boolean | `true`, wenn das Urteil nicht vollständig berechnet werden konnte (Dienst nicht erreichbar, Fehler usw.) und ein konservativer Fallback zurückgegeben wurde. Behandeln Sie herabgestufte Urteile als „unbekannt", nicht als „sauber". |

## `action` — was zu tun ist

`action` ist unsere Empfehlung; Sie behalten die Kontrolle über die endgültige
Entscheidung.

| `action` | Bedeutung | Was zu tun ist |
| --- | --- | --- |
| `record_only` | Der Besuch sieht normal aus. | Fahren Sie wie gewohnt fort. Protokollieren Sie nur das Urteil für Reporting und Abstimmung. |
| `flag` | Der Besuch ist verdächtig, aber nicht eindeutig schlecht. | Liefern Sie die Seite weiter aus, markieren Sie den Besuch aber als geringe Qualität — schließen Sie ihn aus Ihren Kennzahlen aus, segmentieren Sie ihn aus nachgelagerten Flüssen heraus und gewichten Sie ihn in Ihren eigenen Entscheidungen (z. B. Conversion-Attribution oder wie sehr Sie dem Besuch vertrauen). |
| `challenge` | Der Besuch ist hochriskant. | Bitten Sie um eine zusätzliche Verifizierung, bevor Sie den Besucher als Mensch behandeln. Mit `escalate: true` des Web-SDK wird das für Sie erledigt (siehe [Eskalation](./web-sdk#eskalation)); andernfalls wenden Sie Ihre eigene Sperre an. |

## Konfigurierbare Behandlungsaktion

Was `action` für einen **hochriskanten** Besuch meldet, ist **pro-App-Konfiguration**,
festgelegt im Dashboard unter den Details Ihrer Anwendung. Das Urteil ist
**serverautoritativ**: `action` wird nur dann zu `challenge` oder `flag`, wenn der
Besuch die Hochrisiko-Stufe erreicht **und** Ihre App mit der entsprechenden Aktion
konfiguriert ist. Unterhalb dieser Stufe bleibt das Urteil `record_only`.

| Einstellung | Bei hohem Risiko zurückgegebene `action` | Bedeutung |
| --- | --- | --- |
| `record_only` (Standard) | `record_only` | Nur aufzeichnen. Das Urteil wird für Reporting und Abstimmung protokolliert; vom Besucher wird nichts verlangt. |
| `challenge` | `challenge` | Löst ein Re-Verifizierungs-CAPTCHA aus. Das Web-SDK zeigt eine Challenge an (das Styling wird über `challengeConfig` des SDK gesteuert). |
| `flag` | `flag` | Markiert den Besuch. Das Urteil trägt `flag`; Ihre Integration entscheidet, wie darauf reagiert wird (blockieren / segmentieren / behandeln). |

Da die Entscheidung serverseitig getroffen wird, bleibt Ihr Code einfach: Lesen Sie
`verdict.action` in `onVerdict` und reagieren Sie darauf — fortfahren, blockieren oder
das SDK eine Challenge anzeigen lassen. Sie müssen das Risiko nicht selbst neu
ableiten.

### `escalate_result`

Vorhanden, nachdem eine verwaltete Captcha-Eskalation gelaufen ist — d. h. wenn `action` den Wert `challenge` hatte und das SDK das Captcha ausgeführt hat. `null`, wenn keine Eskalation lief. Wird außerdem an `onEscalateDone(passed, detail)` übergeben.

| Feld | Beschreibung |
|---|---|
| `passed` | ob der Besucher das Captcha bestanden hat |
| `token` | das Captcha-Pass-Token — **prüfe es serverseitig**, um das Bestehen zu bestätigen (verlasse dich nicht allein auf das clientseitige `passed`) |
| `challenge_id` | die Captcha-Challenge-ID |
| `cid` | die Click-ID, an die diese Eskalation gebunden ist, sofern ein Click-Token vorhanden war |

## `level` vs. `score`

`level` ist nur eine Einstufung des `score`, bereitgestellt zur Bequemlichkeit:

| `level` | Nutzen Sie es, wenn |
| --- | --- |
| `low` | Als sauberen Datenverkehr behandeln. |
| `medium` | Grenzwertig — in Ordnung aufzuzeichnen, erwägen Sie den Ausschluss aus hochwertigen Funnels. |
| `high` | Stark verdächtig — markieren und ausschließen. |
| `critical` | Fast sicher ungültig — markieren/ausschließen und idealerweise eskalieren. |

::: tip Wählen Sie das Feld, das zu Ihrer Pipeline passt
- Einfache Ja/Nein-Sperre → auf **`is_bot`** verzweigen.
- Empfehlungsgesteuert → auf **`action`** verzweigen.
- Eigene Schwellenwerte → auf **`score`** verzweigen (oder **`level`** für Kategorien).
:::

## Umgang mit herabgestuften Urteilen

Wenn `degraded` `true` ist, wurde das Urteil nicht vollständig berechnet. Der Fallback
ist bewusst konservativ (`is_bot: false`, `action: record_only`), sodass echte Nutzer
niemals blockiert werden. Behandeln Sie diese für das Reporting als **unbekannt**,
statt sie als bestätigt-sauberen Datenverkehr zu zählen.

## Nächste Schritte

- [Web-SDK](./web-sdk) — Urteile auf Ihrer Seite empfangen
- [Daten-API](./data-api) — Urteile und Statistiken serverseitig abrufen