Клиентские метрики без user_id

Большая часть клиентской аналитики опирается на user_id - идентификатор клиента.

Пользователь → действия → история → повторные визиты → поведение во времени.

И когда user_id нет, ломается не написание SQL-запроса - ломается логика вопросов, которые вообще можно задавать данным.

Одна из самых неприятных фраз, которую аналитик может услышать в начале проекта:

Есть метрики, которые принципиально живут без пользователя.

- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.

Это агрегаты "по событиям".
Им не важно, кто именно сделал действие - важно, что действие произошло.

Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.

Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".

- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.

Все эти метрики - не про события.
Они про людей.

А без user_id "человек" в данных перестаёт существовать.

И когда user_id отсутствует, бизнес начинает выкручиваться.

Вместо user_id появляются:

Это не плохие решения.
Это компромиссы.

Каждый такой "заменитель пользователя" решает одну задачу и ломает другую.

Телефон:
- отлично для CRM
- плохо для веба и офлайна

Cookie:
- хорошо для сессий
- бесполезно для долгой аналитики

Email:
- стабилен
- но есть одноразовые email-ы

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

В итоге бизнес не считает "пользователей".
Он считает версии пользователей.

Из-за этого появляются странные эффекты:

И это не всегда ошибка данных
Это ограничение идентификации.

Важно понимать:
отсутствие user_id - это не техническая проблема, а продуктовая.

Она говорит о том, как система была спроектирована изначально:

Поэтому аналитика без user_id возможна.
Но она всегда:

Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.

Лучше честно сказать:

Данные могут существовать без user_id.
Запросы SQL может работать без user_id.
Отчёты можно построить без user_id.

Но аналитика поведения - нет.

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

Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.

Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.