Продуктовая аналитика ломается не в дашборде, а в названиях событий и границах метрик

Продуктовая аналитика ломается не в дашборде, а в названиях событий и границах метрик

Если команда меряет всё подряд, графики есть, а ответов нет. Для старта достаточно 3 слоёв: бизнес-метрика, продуктовая воронка, операционные события. Всё остальное — поддерживающие поля, а не новые KPI.

Схема, которая обычно спасает:
— одно событие = одно действие пользователя;
— имя события = глагол + объект: signup_submit, checkout_start;
— параметры = только то, что помогает сегментировать: источник, тариф, экран, тип устройства.
Если в одном событии живут и клик, и успех, и ошибка — отчёты начинают врать.

Самая частая ошибка — смешивать событие и результат. Например, purchase как факт оплаты и как попытку оплаты. Из-за этого ломаются воронки, ретеншн и cohort-анализ: шаги дублируются, а «падение» оказывается артефактом схемы трекинга.

Перед запуском новой схемы проверьте три вещи: можно ли восстановить воронку по событиям, не теряется ли пользователь между шагами, и есть ли один источник правды для каждой метрики. Если ответ «нет» хотя бы на один пункт, сначала чините трекинг, потом строите отчёт.