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

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

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

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

В своем канале Аналитика FM начала серию постов про метрики в разных бизнесах.
Являются ли эти метрики или формулы их вычисления универсальными для разных бизнес направлений.

Об этом и об аналитике в целом рассказываю у себя в канале.
Канал веду с нуля подписчиков.
Присоединяйся, если хочешь разобраться в SQL, python и мышлении аналитика.

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

user_id у нас нет

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

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

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

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

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

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

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

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

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

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

• номер телефона

• email

• cookie

• device_id

• хэш паспорта

• комбинации из "телефон + дата рождения + регион"

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

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

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

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

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

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

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

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

• пользователей стало больше, но денег больше не стало

• retention упал, но продажи выросли

• конверсия пляшет, а поведение вроде то же

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

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

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

• думали ли о пользователе как о сущности

• или думали только о событиях и операциях

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

• менее точная

• более приближённая

• и требует аккуратной интерпретации

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

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

Мы считаем это так, потому что другого способа у нас нет

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

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

НО... Главный НО...

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

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

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

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!