Идентификация пользователей в продуктовой аналитике

Идентификация определяет, какие события относятся к одному пользователю, аккаунту или устройству. Ошибка на этом уровне меняет все отчёты: воронка распадается на две половины, retention завышается, а действия коллег объединяются в один профиль.

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

Основные идентификаторы

Anonymous ID

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

User ID

Стабильный внутренний идентификатор авторизованного пользователя. Он не должен меняться вместе с email или отображаемым именем.

Account ID

Идентификатор организации, рабочего пространства или клиента. В B2B он нужен для активации команды, adoption и retention аккаунта.

Object ID

Идентификатор заказа, проекта или другой сущности, если именно она проходит сценарий.

Переход от анонимного к авторизованному

Типичный путь:

1. браузер создаёт anonymous_id;
2. пользователь изучает продукт;
3. проходит регистрацию или вход;
4. система получает user_id;
5. события после входа отправляются с user_id;
6. связь анонимной истории выполняется по явному правилу.

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

Несколько устройств

Один человек использует ноутбук и телефон. До авторизации это две анонимные истории. После входа их можно связать через user_id, сохраняя исходные device/anonymous идентификаторы для диагностики.

Не пытайтесь угадывать пользователя по отпечатку устройства. Для продуктовой аналитики обычно достаточно явной авторизации и псевдонимных ключей.

Выход из аккаунта

После logout:

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

Распространённая ошибка — следующий человек на общем устройстве продолжает отправлять события с прежним user_id.

Пользователь в нескольких аккаунтах

В B2B один user_id может состоять в нескольких рабочих пространствах. Account_id должен соответствовать активному контексту события.

Не храните единственный «текущий аккаунт» как неизменное свойство пользователя. При переключении контекста отчёты иначе соединят действия разных клиентов.

Подробнее об уровне организации — аналитика аккаунтов B2B SaaS.

Слияние профилей

Слияние должно быть:

• детерминированным;
• объяснимым;
• идемпотентным;
• защищённым от объединения разных людей;
• проверяемым на тестовом сценарии.

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

Email — плохой технический ключ

Email может:

• измениться;
• отличаться регистром;
• быть общим;
• переиспользоваться;
• содержать персональные данные;
• отсутствовать в части событий.

Используйте внутренний id. Email передавайте только при наличии конкретной законной и продуктовой необходимости, с соответствующим контролем доступа.

Удаление и блокировка

Определите:

• что происходит с идентификатором после удаления;
• можно ли переиспользовать логин;
• как сохраняется агрегированная история;
• как исключается дальнейшая отправка;
• как выполняются применимые запросы по данным;
• кто имеет доступ к процедуре.

Не превращайте удалённого пользователя в нового под тем же ключом.

Проверки качества

Ищите:

• события после logout со старым user_id;
• один anonymous_id у большого числа user_id;
• один user_id с невозможным количеством устройств;
• события без account_id после выбора контекста;
• резкие скачки merge;
• отрицательное время между регистрацией и анонимным действием;
• смешение тестовых и рабочих профилей;
• действия в аккаунте после удаления членства.

Общий чек-лист есть в статье качество данных продуктовой аналитики.

Пример теста

Проверьте руками:

1. открыть сайт без входа;
2. совершить несколько действий;
3. зарегистрироваться;
4. продолжить работу;
5. выйти;
6. войти другим пользователем;
7. переключить аккаунт;
8. открыть историю каждого профиля.

Ожидаемая связь должна быть записана до теста. Если команда не может объяснить каждое событие, агрегатам рано доверять.

Приватность по умолчанию

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

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

Итог

Надёжная идентификация разделяет устройство, пользователя, аккаунт и объект. Связывайте истории только по явным правилам, корректно обрабатывайте вход, выход и смену контекста и проверяйте сценарий на исходных событиях.