Клиентские метрики без 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 не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!
