ProductHub

Продуктовая аналитика: события, воронки и когорты

Продуктовая аналитика — это не дашборд с десятком графиков, а дисциплина, которая отвечает на один вопрос: двигается ли продукт в нужную сторону и почему. Чтобы аналитика отвечала, а не создавала иллюзию контроля, нужно правильно спроектировать события, а потом уметь читать воронки и когорты. Разберём это по шагам.

Модель событий: из чего собирается аналитика

В основе продуктовой аналитики лежат события (events) — факты о том, что пользователь сделал: открыл экран, нажал кнопку, завершил действие. У каждого события есть имя и набор свойств (properties) — контекст: с какого источника пришёл, какой тариф, сколько элементов в корзине. Хорошая модель событий — это словарь, на котором потом задаются все вопросы к продукту.

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

Как спроектировать трекинг-план

Трекинг-план — это таблица, которая описывает каждое событие до того, как его начнут писать в код: имя, когда срабатывает, какие свойства, кто владелец. Он защищает от двух бед: расхождения названий («signup» против «sign_up») и потери смысла через полгода.

  1. Единая нотация имён. Договоритесь о формате (например, object_action: checkout_completed) и держитесь его.
  2. Свойства, а не новые события. Тариф — это свойство события покупки, а не отдельное событие «купил_про». Так отчёты остаются гибкими.
  3. Ключевые действия — в первую очередь. Сначала события вдоль главной воронки (активация → ценность → возврат), потом второстепенное.
  4. Идентификация пользователя. Свяжите анонимные и авторизованные события через стабильный id, иначе воронки и когорты «порвутся» на моменте логина.

Воронки: где и почему теряются пользователи

Воронка (funnel) — это последовательность шагов, по которой вы смотрите, сколько пользователей доходит от одного к другому. Её ценность не в итоговой конверсии, а в том, чтобы найти конкретный шаг, где обваливается переход.

  • Смотрите переходы, а не только итог. Конверсия 4% мало о чём говорит; «80% отваливаются на вводе платёжных данных» — уже гипотеза для фикса.
  • Сегментируйте воронку. Один и тот же шаг может работать по-разному для новых и вернувшихся, для мобильных и десктопа, для разных источников трафика.
  • Фиксируйте окно конверсии. «Дошёл за сессию» и «дошёл за неделю» — это разные воронки; договоритесь о горизонте заранее.

Когортный анализ: остаются ли пользователи

Воронка показывает первый проход, но не отвечает, возвращаются ли люди. На это отвечает когортный анализ: пользователей группируют по периоду первого визита (когорте) и смотрят, какая доля активна через 1, 7, 30 дней. Получается кривая удержания.

Читать её нужно по форме, а не по одному числу: ранний обрыв — проблема активации и онбординга; медленное затухание без плато — продукт не формирует привычку; выход кривой на плато — признак сложившегося ядра и приближения к product/market fit. Подробнее про удержание и отток — в гайде по retention и churn.

Дашборды: как не утонуть в графиках

Дашборд нужен не чтобы «следить за всем», а чтобы быстро замечать отклонения по немногим важным метрикам. Полезный приём — три уровня: одна North Star метрика сверху, под ней 3–5 метрик-драйверов (активация, удержание, выручка), и только ниже — операционные графики для разбора. Если метрика на дашборде ни на что не влияет в ваших решениях — ей там не место.

И помните про честность данных: аналитика отвечает на «что происходит», но не на «почему». Причины проверяются гипотезами и экспериментами, а не додумываются по графику.

Разберите свою задачу по этой логике — бесплатно

ProductHub Deep Dive за ~7 минут превращает вашу продуктовую задачу в план с обоснованием, опираясь на методологию и 200+ реальных проектов агентства. Без воды и коммерческих звонков.

Пройти разбор бесплатно

Частые вопросы

С чего начать настройку продуктовой аналитики?

Не с инструмента, а с вопросов и трекинг-плана. Сформулируйте, какие решения будете принимать по данным, опишите минимальный набор событий вдоль главной воронки (активация → ценность → возврат) с едиными именами и свойствами, и только потом внедряйте трекинг. Так вы избежите сотен мусорных событий.

Чем воронки отличаются от когортного анализа?

Воронка показывает, сколько пользователей доходит от шага к шагу за один проход — это про конверсию здесь и сейчас. Когортный анализ группирует пользователей по периоду первого визита и показывает, какая доля возвращается со временем — это про удержание. Воронка отвечает «дошли ли», когорты — «остались ли».

Сколько событий нужно трекать?

Ровно столько, сколько отвечает на ваши решения. Лучше десяток хорошо описанных событий вдоль ключевой воронки, чем сотни «на всякий случай», в которых никто не разберётся. Расширяйте словарь событий по мере появления новых вопросов к продукту.