---
title: Fraud Prevention — Справочник по вердиктам
---

# Справочник по вердиктам

Каждый вердикт Fraud Prevention — доставлен ли он в ваш колбэк `onVerdict` в
[Web SDK](./web-sdk) или получен из [Data API](./data-api) — это один и тот же объект
`BotVerdict`. На этой странице описано каждое поле и как на него реагировать.

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

## Поля

| Поле | Тип | Описание |
| --- | --- | --- |
| `is_bot` | boolean | Основной вердикт. `true` = визит признан автоматизированным или недействительным трафиком; `false` = он выглядит как реальный человек. Это единственное поле, по которому ветвится большинство интеграций. |
| `score` | number (0–100) | Насколько подозрителен визит. **Чем выше, тем подозрительнее.** Используйте его, чтобы задать собственные пороги — например, исключать визиты выше выбранной вами отсечки. Точное значение производится нашей моделью рисков и не предназначено для обратной разработки. |
| `level` | enum | Грубая полоса значения `score`: `low`, `medium`, `high`, `critical`. Удобно, когда нужны корзины вместо сырого числа. |
| `action` | enum | Наша **рекомендуемая обработка** визита: `record_only`, `challenge` или `flag`. См. ниже. |
| `consistency` | object | Вывод о согласованности между сигналами. Читайте `consistency.ok` (boolean): `true` = сигналы визита сходятся как ожидалось; `false` = что-то не сошлось, и визит заслуживает дополнительного внимания. Внутренняя детализация, стоящая за этим выводом, не раскрывается. |
| `degraded` | boolean | `true`, когда вердикт не удалось полностью вычислить (сервис недоступен, ошибка и т. д.) и был возвращён консервативный запасной вариант. Относитесь к деградированным вердиктам как к «неизвестно», а не «чисто». |

## `action` — что делать

`action` — это наша рекомендация; окончательное решение остаётся за вами.

| `action` | Значение | Что делать |
| --- | --- | --- |
| `record_only` | Визит выглядит нормально. | Продолжайте как обычно. Просто логируйте вердикт для отчётности и сверки. |
| `flag` | Визит подозрителен, но не однозначно плох. | Продолжайте показывать страницу, но пометьте визит как низкокачественный — исключите его из метрик, выделите из нижестоящих потоков и учтите его вес в собственных решениях (например, в атрибуции конверсий или в том, насколько вы доверяете визиту). |
| `challenge` | Визит высокорисковый. | Запросите одну дополнительную проверку, прежде чем относиться к посетителю как к человеку. С опцией `escalate: true` в Web SDK это делается за вас (см. [Эскалацию](./web-sdk#escalation)); иначе примените собственный шлюз. |

## Настраиваемое действие обработки

То, что `action` сообщает для **высокорискового** визита, — это **конфигурация на
уровне приложения**, задаваемая в панели управления в деталях вашего приложения.
Вердикт **авторитетен на стороне сервера**: `action` становится `challenge` или `flag`,
только когда визит достигает высокорисковой полосы **и** ваше приложение настроено на
соответствующее действие. Ниже этой полосы вердикт остаётся `record_only`.

| Настройка | `action`, возвращаемое при высоком риске | Значение |
| --- | --- | --- |
| `record_only` (по умолчанию) | `record_only` | Только запись. Вердикт логируется для отчётности и сверки; от посетителя ничего не запрашивается. |
| `challenge` | `challenge` | Запуск повторной проверки CAPTCHA. Web SDK показывает challenge (стилизация управляется через `challengeConfig` в SDK). |
| `flag` | `flag` | Пометка визита. Вердикт несёт `flag`; ваша интеграция сама решает, как на это реагировать (блокировать / сегментировать / обработать). |

Поскольку решение принимается на стороне сервера, ваш код остаётся простым: читайте
`verdict.action` в `onVerdict` и реагируйте на него — продолжайте, блокируйте или
позвольте SDK показать challenge. Вам не нужно заново выводить риск самостоятельно.

### `escalate_result`

Присутствует после того, как отработала управляемая эскалация captcha — то есть когда `action` был `challenge` и SDK запустил captcha. `null`, если эскалации не было. Также передаётся в `onEscalateDone(passed, detail)`.

| поле | описание |
|---|---|
| `passed` | прошёл ли посетитель captcha |
| `token` | pass token captcha — **проверьте его на сервере**, чтобы подтвердить прохождение (не доверяйте только клиентскому `passed`) |
| `challenge_id` | id challenge captcha |
| `cid` | click id, с которым связана эта эскалация, если был передан click token |

## `level` и `score`

`level` — это просто разбивка `score` на полосы, предоставляемая для удобства:

| `level` | Когда использовать |
| --- | --- |
| `low` | Считайте чистым трафиком. |
| `medium` | Пограничный — записывать можно, стоит рассмотреть исключение из высокоценных воронок. |
| `high` | Сильно подозрительный — пометьте и исключите. |
| `critical` | Почти наверняка недействительный — пометьте/исключите и, в идеале, эскалируйте. |

::: tip Выбирайте поле под ваш конвейер
- Простой шлюз да/нет → ветвитесь по **`is_bot`**.
- На основе рекомендации → ветвитесь по **`action`**.
- Собственные пороги → ветвитесь по **`score`** (или по **`level`** для корзин).
:::

## Обработка деградированных вердиктов

Когда `degraded` равно `true`, вердикт не был полностью вычислен. Запасной вариант
намеренно консервативен (`is_bot: false`, `action: record_only`), поэтому реальные
пользователи никогда не блокируются. В отчётности относитесь к таким визитам как к
**неизвестным**, а не считайте их подтверждённо чистым трафиком.

## Дальнейшие шаги

- [Web SDK](./web-sdk) — получайте вердикты на вашей странице
- [Data API](./data-api) — получайте вердикты и статистику на стороне сервера