Документация
Панель управления API

Обнаружить мультиаккаунтинг

Как с помощью данных DFP понять, что один человек злонамеренно создаёт много аккаунтов, чтобы обойти правила вашего сервиса.

Какую проблему решаем

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

Обычно такие попытки сложно поймать только по имейлу, IP-адресу или cookie. Имейл можно сменить, IP может быть динамическим или скрываться за VPN, а в веб-сценарии cookie легко обойти, открыв сайт в инкогнито. Формально каждый аккаунт будет выглядеть как новый пользователь.

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

Как настроить

На вашем бэкенде

Подготовка

  1. Интегрируйте DFP по нашей инструкции со своим сайтом или мобильным приложением.

  2. Опираясь на особенности своего сервиса, решите, каким сделать лимит аккаунтов для одного user_id. Например:

    • 1 аккаунт — если важен жёсткий лимит;

    • 2–3 аккаунта — если вы допускаете, что одним устройством могут пользоваться несколько человек;

    • другое значение — если для вашего продукта нормально, что с одного устройства создают больше аккаунтов.

Подробнее о user_id

user_id — стабильный идентификатор клиентского окружения.

Говоря проще, это ID, который описывает уникальную связку «конкретный браузер + конкретное устройство» (DFP для сайта) или уникальное устройство (DFP для мобильного приложения). ID остаётся стабильным, даже когда пользователь меняет разные настройки. Например, если он:

  • включит VPN;

  • обновит ОС;

  • поменяет время на компьютере/телефоне;

  • откроет инкогнито в браузере;

  • обновит версию браузера.

ID будет тем же самым, ведь главный критерий выполняется: устройство и браузер остались те же. А вот если пользователь откроет другой браузер или сделает запрос с нового устройства, вы увидите другой ID.

Протестируйте эту механику сами: мы встроили виджет DFP прямо на эту страницу, он покажет ваш текущий User ID. Экспериментируйте, пробуйте открывать страницу из разных источников и с разными настройками — вы убедитесь, что всё работает ровно так, как мы описали.

Настройка бэкенда

  1. Расшифруйте ответ DFP.

  2. Проверьте timestamp. Это важно для защиты от replay-атак:

    • Ответ свежий — можно переходить к следующему шагу.

    • Ответ старше нескольких секунд — отклоните результат DFP и не выполняйте регистрацию. Клиент (браузер или мобильное приложение) должен заново вызвать DFP, получить свежий payload и отправить его на бэкенд. Если свежий payload получить не удалось, попросите пользователя попробовать регистрацию ещё раз.

  3. Проверьте поле white_bot (доступно только для интеграции DFP на сайт).

    Если значение true, это маркер доверенного трафика — рекомендуем автоматически разрешить действие. При white_bot: false переходите к следующему шагу.

    Для доверенных запросов DFP не вычисляет user_id и возвращает пустую строку ("user_id": ""), поэтому использовать его для поиска пользователей нельзя.

  4. Получите user_id из ответа DFP.

  5. Проверьте, сколько аккаунтов уже связано с этим user_id:

    • Аккаунтов меньше лимита — регистрация допустима. Создайте аккаунт и сохраните связь account_id с user_id.

    • Число аккаунтов достигло лимита — пользователь пытается злоупотребить сервисом. Откажите в регистрации.

Если ваш сервис предполагает, что пользователи могут регистрироваться только вручную (без использования автоматизации), советуем добавить дополнительную фильтрацию по bot_score.

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

  • Меньше 0.4 — признаков автоматизации нет. Зарегистрируйте аккаунт.

  • От 0.4 до 0.5 — есть умеренный риск автоматизации. Запросите дополнительную проверку, например, выдайте CAPTCHA.

  • Больше 0.5 — высокий риск автоматизации. Откажите в регистрации.

На стороне Servicepipe

Можем взять реализацию этой логики на себя.

Мы будем хранить связь между user_id и идентификаторами аккаунтов вашего сервиса. Если с одного user_id пытаются зарегистрировать больше аккаунтов, чем разрешено по вашим правилам, DFP пришлёт вам сигнал: пользователь пытается обойти ограничение.

Такую механику мы настраиваем индивидуально по запросу. Наши инженеры согласуют с вами, какой лимит использовать, как передавать информацию об аккаунтах в Servicepipe и в каком формате возвращать результат.

Напишите нам, мы обсудим решение и реализуем его под ваш сценарий.