Идентифицировать пользователя без использования cookie

Как с помощью данных DFP идентифицировать пользователей, если cookie использовать ненадёжно или невозможно.

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

Предположим, вам нужно понять, что с вашим сервисом взаимодействует один и тот же пользователь или одно и то же устройство. Например:

  • посчитать, сколько уникальных пользователей увидели рекламную кампанию;

  • понять, что один человек несколько раз проходит один и тот же опрос;

  • найти клиентские устройства, активность которых на ресурсе нежелательна;

  • узнать пользователя, даже если он возвращается на сайт из режима инкогнито.

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

Можно также смотреть на IP, user-agent, JA3/JA4 и похожие признаки. Но это тоже не всегда помогает. IP может быть динамическим или скрываться за VPN. User-agent часто совпадает у разных пользователей. JA3/JA4 описывают сетевые параметры соединения, но не всегда достаточно точно описывают клиентское окружение.

DFP даёт более надёжный параметр — user_id. Это стабильный идентификатор клиентского окружения: он описывает связку браузер+устройство и устойчив к изменениям. Например, если пользователь:

  • включит инкогнито;

  • включит VPN;

  • обновит ОС;

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

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

user_id останется тем же самым, если это тот же браузер и то же устройство.

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

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

Подготовка

Интегрируйте DFP со своим сайтом по нашей инструкции.

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

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

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

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

  • Ответ старше нескольких секунд — отклоните результат DFP. Фронтенд должен заново вызвать DFP, получить свежий payload и отправить его на бэкенд. Если свежий payload получить не удалось, не используйте этот результат для идентификации пользователя.

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

4. Найдите в базе данных записи с таким user_id.

Для этого сценария важно хранить строки с индексированным user_id. Тогда бэкенд сможет быстро искать все события, связанные с одним и тем же клиентским окружением.

Например:

Событие user_id

visit_71a2

user_4b8c21

survey_answer_19d4

user_4b8c21

ad_click_83f1

user_91f03d

5. Обработайте запрос в зависимости от результата поиска по БД:

  • Записи с таким user_id уже есть — значит, вы уже видели это клиентское окружение раньше.

  • Записей с таким user_id нет — значит, для вашей базы это новое клиентское окружение. Обработайте его как новое. После этого сохраните текущее событие вместе с user_id.

Дальнейшая логика зависит от вашей задачи. Например, если вы:

  • проводите опрос — можно не засчитывать повторный ответ с тем же user_id;

  • считаете уникальных пользователей в рекламной кампании — можно считать несколько действий с одним user_id как активность одного уникального пользователя;

  • защищаете ресурс от нежелательной активности — можно сохранять user_id устройств, которые уже нарушали правила, и внимательнее проверять их следующие действия.

Для этого сценария советуем также обращать внимание на bot_score.

Высокие значения могут означать, что запрос выполняет автоматизация или что пользователь пытается подменить параметры клиентской стороны, которые DFP анализирует. Значения bot_score:

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

  • От 0.4 до 0.5 — есть умеренный риск автоматизации. Советуем также проверить параметры hosting, vpn, geo, incognito и уже после принимать решение.

  • Больше 0.5 — вероятнее всего, запрос отправил бот.