Продуктовые метрики: что считать в первые месяцы после запуска

В первые месяцы после запуска стоит считать немного метрик, но правильных: сколько пользователей доходят до ключевого действия (активация), сколько возвращаются через неделю и месяц (удержание) и где они отваливаются по пути (воронка). Количество регистраций и просмотров почти ничего не говорит о том, нужен ли продукт. Главное — заранее решить, какие события отслеживать, и собирать их с первого дня.

Разберём, какие метрики важны молодому продукту, как их посчитать и как не утонуть в дашбордах.

Почему не стоит считать всё подряд?

Считать всё подряд не стоит, потому что десятки графиков создают ощущение контроля, но не помогают принимать решения. Молодому продукту нужны ответы на три вопроса: понимают ли люди ценность, возвращаются ли они и что им мешает.

Метрики-пустышки, которые радуют, но мало говорят:

• общее число регистраций — без активации это просто любопытство;
• просмотры страниц и время на сайте — не отличают интерес от путаницы;
• число скачиваний приложения — без удержания это деньги на рекламу впустую;
• накопительные графики, которые растут всегда, даже когда продукт стоит на месте.

Хорошая метрика меняет решение: если она упала, вы знаете, что делать дальше.

Какие метрики важны в первые месяцы?

В первые месяцы важны активация, удержание, воронка ключевого сценария и, если продукт платный, конверсия в оплату. Вместе они показывают, дошёл ли пользователь до ценности, вернулся ли за ней снова и где продукт его теряет.

Метрика	Что показывает	Как считать
Активация	Доля новых пользователей, дошедших до ключевого действия	Совершили ключевое действие за N дней / зарегистрировались
Удержание	Возвращаются ли пользователи	Доля когорты, активной на 7-й, 30-й день
Воронка	Где теряются пользователи в ключевом сценарии	Конверсия между шагами сценария
Конверсия в оплату	Готовы ли платить	Оплатили / активировались
Отток	Сколько платящих уходит	Отменили подписку за месяц / платили в начале месяца

Что считать ключевым действием

Ключевое действие — момент, когда пользователь впервые получил ценность продукта. Для сервиса заказа еды — первый оформленный заказ, для CRM — первая добавленная сделка, для онлайн-школы — первый пройденный урок. Если вы не можете назвать это действие, сначала сформулируйте его — от этого зависит всё остальное.

Фото: Unsplash

Как посчитать удержание по когортам?

Удержание по когортам считают так: пользователей группируют по неделе регистрации и для каждой группы смотрят, какая доля была активна через одну, две, четыре недели. Когорты показывают, становится ли продукт лучше: если новые когорты удерживаются лучше старых, изменения работают.

Пример запроса по таблице событий в PostgreSQL:

WITH cohorts AS (
    SELECT user_id, date_trunc('week', min(created_at)) AS cohort_week
    FROM events
    WHERE name = 'signed_up'
    GROUP BY user_id
),
activity AS (
    SELECT DISTINCT e.user_id, c.cohort_week,
           (date_trunc('week', e.created_at) - c.cohort_week) / interval '1 week' AS week_n
    FROM events e
    JOIN cohorts c USING (user_id)
    WHERE e.name = 'order_created'
)
SELECT cohort_week, week_n, count(*) AS active_users
FROM activity
GROUP BY cohort_week, week_n
ORDER BY cohort_week, week_n;

Делите число активных в каждой неделе на размер когорты — получите таблицу удержания. Если кривая удержания со временем выходит на плато, у продукта есть аудитория, которой он нужен. Если уходит в ноль — ценность пока не найдена.

Как настроить сбор событий?

Сбор событий настраивают по плану трекинга: заранее описывают, какие действия пользователей записывать, с какими параметрами и как их называть. Без плана события добавляют хаотично, называют по-разному, и через три месяца им нельзя доверять.

Правила, которые мы используем:

1. Составьте план трекинга до разработки: событие, когда отправляется, какие параметры.
2. Называйте события единообразно: объект и действие в прошедшем времени — order_created, lesson_completed.
3. Важные события отправляйте с сервера, а не только из браузера: блокировщики рекламы и закрытые вкладки не должны терять данные об оплатах.
4. Храните сырые события в своей базе или хранилище, даже если используете внешнюю аналитику.
5. Проверяйте события при каждом релизе — сломанный трекинг обнаруживают обычно слишком поздно.

Как превратить метрики в решения?

Метрики превращаются в решения, когда у каждой есть владелец, целевое значение и регулярный разбор. Раз в неделю команда смотрит на несколько главных чисел, ищет причины изменений и выбирает, что проверить дальше.

Что помогает:

• одна главная метрика на квартал, вокруг которой строится бэклог;
• гипотеза для каждой крупной задачи: какую метрику и насколько она должна сдвинуть;
• сравнение ожидаемого и фактического эффекта после релиза;
• разговоры с пользователями — числа показывают «что», интервью объясняют «почему».

Выбирать, какую гипотезу проверять следующей, помогают методы приоритизации — об этом в статье приоритизация бэклога.

Коротко

• В первые месяцы считайте активацию, удержание, воронку ключевого сценария и конверсию в оплату.
• Определите ключевое действие — момент, когда пользователь получает ценность.
• Удержание по когортам показывает, становится ли продукт лучше со временем.
• Составьте план трекинга до разработки, называйте события единообразно, важные отправляйте с сервера.
• Разбирайте метрики еженедельно и связывайте каждую крупную задачу с ожидаемым эффектом.