Обнаружить мультиаккаунтинг
Как с помощью данных DFP понять, что один человек злонамеренно создаёт много аккаунтов, чтобы обойти правила вашего сервиса.
Какую проблему решаем
Предположим, у вас есть промоакция или приветственный бонус. Один человек создаёт десять аккаунтов, чтобы получить бонус десять раз.
Обычно такие попытки сложно поймать только по имейлу, IP-адресу или cookie. Имейл можно сменить, IP может быть динамическим или скрываться за VPN, а cookie легко обойти, открыв сайт в инкогнито. Формально каждый аккаунт будет выглядеть как новый пользователь.
DFP помогает с этим бороться. Благодаря ему вы видите, из какого окружения создаётся аккаунт. Если один человек пытается зарегистрировать больше аккаунтов, чем считаете допустимым, можно отказать в регистрации.
Как настроить
На вашем бэкенде
Подготовка
-
Интегрируйте DFP со своим сайтом по нашей инструкции.
-
Опираясь на особенности своего сервиса, решите, каким сделать лимит аккаунтов для одного
user_id. Например:-
1 аккаунт — если важен жёсткий лимит;
-
2–3 аккаунта — если вы допускаете, что одним устройством могут пользоваться несколько человек;
-
другое значение — если для вашего продукта нормально, что с одного устройства создают больше аккаунтов.
-
Подробнее о user_id
user_id — стабильный идентификатор клиентского окружения.
Говоря проще, это ID, который описывает уникальную связку браузер + конкретное устройство. Он остаётся стабильным, даже когда пользователь меняет у себя настройки. Например, если он:
-
включит VPN;
-
откроет инкогнито;
-
обновит ОС;
-
поменяет время на компьютере;
-
обновит версию браузера.
ID будет тем же самым, ведь главный критерий выполняется: устройство и браузер остались те же.
А вот если откроет другой браузер или сделает запрос с нового устройства, вы увидите новый ID. Потому что для каждой пары браузер + устройство ID уникален.
Протестируйте, как это работает, в нашем playground: открывайте его из разных браузеров, включайте и выключите VPN, переходите в инкогнито или меняйте настройки устройства. Вы увидите, что User ID будет меняться только в двух случаях: если изменилось устройство или браузер. В остальных останется прежним.
Настройка бэкенда
-
Расшифруйте ответ DFP.
-
Проверьте
timestamp. Это важно для защиты от replay-атак:-
Ответ свежий — можно переходить к следующему шагу.
-
Ответ старше нескольких секунд — отклоните результат DFP и не выполняйте регистрацию. Фронтенд должен заново вызвать DFP, получить свежий
payloadи отправить его на бэкенд. Если свежийpayloadполучить не удалось, попросите пользователя попробовать регистрацию ещё раз.
-
-
Получите
user_idиз ответа DFP. -
Проверьте, сколько аккаунтов уже связано с этим
user_id:-
Аккаунтов меньше лимита — регистрация допустима. Создайте аккаунт и сохраните связь
account_idсuser_id. -
Число аккаунтов достигло лимита — пользователь пытается злоупотребить сервисом. Откажите в регистрации.
-
|
Если ваш сервис предполагает, что пользователи могут регистрироваться только вручную (без использования автоматизации), советуем добавить дополнительную фильтрацию по Её можно добавить последним шагом в сценарий. Будет работать так: если число аккаунтов с этим
|
На стороне Servicepipe
Можем взять реализацию этой логики на себя.
Мы будем хранить связь между user_id и идентификаторами аккаунтов вашего сервиса. Если с одного user_id пытаются зарегистрировать больше аккаунтов, чем разрешено по вашим правилам, DFP пришлёт вам сигнал: пользователь пытается обойти ограничение.
Такую механику мы настраиваем индивидуально по запросу. Наши инженеры согласуют с вами, какой лимит использовать, как передавать информацию об аккаунтах в Servicepipe и в каком формате возвращать результат.
Напишите нам, мы обсудим решение и реализуем его под ваш сценарий.