Как интерпретировать ответ DFP

У вас сервис с бесплатным лимитом: можно бесплатно сгенерировать 10 отчётов в месяц. Кто-то пытается обойти ограничение: чистит cookie, открывает инкогнито, включает VPN и снова приходит как будто впервые.

Если лимит привязан только к cookie или IP, такой обход может сработать. Но если вы учитываете user_id, то видите, клиентское окружение не изменилось. Тогда можно выдавать сообщение: бесплатный объём уже использован.

У вас есть промоакция или приветственный бонус. Один человек создаёт десять аккаунтов, чтобы получить бонус десять раз.

Если у этих аккаунтов один и тот же user_id, это не стопроцентное доказательство нарушения, но сильный сигнал. Вы можете не выдавать бонус автоматически, ограничить количество участий с одного user_id или отправить такие аккаунты на проверку.

Пользователь раньше входил в аккаунт из одного user_id, а теперь тот же токен или cookie приходит из другого окружения.

Это может быть признаком кражи cookie или токена. В таком случае можно сбросить сессию и попросить пользователя войти заново.

У вас есть форма регистрации. В обычный день через неё создают 200 аккаунтов, а сегодня внезапно создали 5000.

Если у значительной части таких запросов высокий bot_score, они идут из хостинговых сетей и ведут себя похоже, стоит включить дополнительную проверку при регистрации: CAPTCHA, одноразовый код, лимит запросов или ручную модерацию.

У вас есть форма заявки. Бот массово отправляет фейковые заявки, и менеджеры тратят время на несуществующих клиентов.

В этом случае можно не блокировать форму целиком, а менять реакцию по уровню риска: обычные запросы пропускать, подозрительные отправлять на дополнительную проверку, а запросы с высоким bot_score блокировать.

Ваш сайт содержит данные, которые нельзя массово выгружать. Можно поставить лимит запросов по user_id и выдавать проверки при высоком bot_score.

У вас сервис, где пользователи создают аккаунты и получают пробный период. За короткое время приходит много регистраций из хостинговых сетей, с высоким bot_score и похожими параметрами окружения.

Это похоже на массовую автоматизированную регистрацию. Можно показать дополнительную проверку, ограничить количество регистраций, временно замедлить поток или отправить часть заявок на модерацию.

Обычный пользователь всегда заходил в личный кабинет из домашней или мобильной сети. Теперь попытка сменить пароль приходит из хостинговой сети.

Это повод запросить дополнительное подтверждение.

У вас есть промокод для новых пользователей: один человек может применить его только один раз.

Пользователь создаёт первый аккаунт, применяет промокод и получает скидку. Потом открывает сайт в инкогнито, создаёт второй аккаунт с того же user_id и снова пытается применить промокод.

Один user_id у двух аккаунтов сам по себе ещё не доказывает нарушение: одним компьютером могли пользоваться два разных человека. Но incognito: true добавляет важный контекст. Пользователь создаёт новый аккаунт в режиме, который помогает скрыть браузерное состояние: cookie, локальное хранилище и историю сессии.

Поэтому сценарий больше похож на попытку обойти правило акции. В таком случае можно не только отказать во втором применении промокода, но и ограничить первый аккаунт: например, заморозить промобонусы и отправить аккаунт на проверку.

Так система реагирует не на сам факт инкогнито, а на схему: пользователь уже получил выгоду и пытается повторить её через второй аккаунт в приватном режиме.

У вас сервис с региональными ценами. Пользователь пытается зарегистрироваться, но у него включён VPN.

Возможно, он просто использует VPN постоянно. А может быть, это способ привязать аккаунт к другому региону, где цены ниже. Вы выдаёте страницу: отключите VPN, чтобы продолжить регистрацию доступна только без VPN. Когда пользователь придёт без VPN, он сможет вернуться к форме и создать аккаунт.

У вас началась волна подозрительных регистраций. По одному запросу ничего необычного не видно, но в потоке появляется повторяющийся набор признаков: десктопное устройство, Linux, один и тот же браузерный движок, хостинговая подсеть и средний bot_score.

mobile, os и engine вместе с другими сигналами помогают описать автоматизированный паттерн и точнее настроить правила: например, отправлять такие регистрации на дополнительную проверку или ограничивать частоту запросов.