Метрики продукта: что считать, чтобы принимать решения

Если в отчёте растёт число регистраций, а пользователи не возвращаются и не доходят до оплаты, продукт не обязательно стал лучше. Чтобы метрики помогали принимать решения, свяжите бизнес-результат с конкретным действием пользователя, задайте формулы и проверяйте качество событий. Ниже — практическая схема для цифрового продукта на примере B2B-сервиса; она не привязана к конкретной платформе аналитики.

Начните не с графика, а с решения

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

Для базового набора достаточно трёх уровней:

• Результат для бизнеса: например, число активных платящих аккаунтов или регулярная выручка. Выберите показатель, который отражает цель продукта, а не просто доступен в отчёте.
• Ценность для пользователя: действие, после которого человек получает пользу. Для сервиса совместной работы это может быть завершённая командой задача, а не сам факт открытия страницы.
• Ограничитель: показатель, который не должен ухудшиться из-за изменений. Например, доля ошибок при сохранении данных, отмены подписки или обращения в поддержку.

Не складывайте эти показатели в одну формулу без ясной причины. Бизнес-результат показывает, куда движется продукт, поведение помогает объяснить движение, а ограничитель ловит цену улучшения. Рост активаций при одновременном росте ошибок — не однозначная победа.

Метрика становится полезной, когда по ней можно принять решение и заранее понятно, какое действие пользователя должно измениться.

Выберите способ измерения под вопрос

У продукта нет единственного «главного» графика на все случаи. Выбор зависит от того, что именно вы проверяете: ценность, путь до целевого действия или возвращение пользователей. Эти способы дополняют друг друга, но отвечают на разные вопросы.

Когда что выбирать

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

Когорта — группа пользователей, объединённая общим признаком, например неделей регистрации. Удержание когорты показывает, какая часть этой группы вернулась или выполнила целевое действие через выбранный интервал. [1]

Зафиксируйте определения до запуска аналитики

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

Представим условные данные за одну неделю: из 100 новых аккаунтов 32 создали проект, а 18 из этих 32 пригласили коллегу. В этой иллюстрации конверсия от регистрации до создания проекта — 32%, а от проекта до приглашения — 56%. Эти цифры не являются отраслевым ориентиром: они только показывают, как считать этапы и находить место, где стоит проверить продуктовую гипотезу.

Перед тем как строить дашборд, запишите для каждой метрики:

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

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

Проверьте события и знаменатели

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

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

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

Что ломается в реальном продукте

• Оптимизация регистрации вместо ценности. Команда упрощает форму и получает больше аккаунтов, но не проверяет, дошли ли новые пользователи до полезного действия. Добавьте следующий этап воронки и удержание.
• Среднее скрывает различия. Общий показатель может выглядеть стабильным, когда новые и возвращающиеся пользователи ведут себя по-разному. Сегментируйте по важным признакам, но не плодите десятки срезов без конкретного вопроса.
• Изменилось определение события. После переименования или смены логики старые и новые данные могут оказаться несопоставимыми. Зафиксируйте дату изменения и не склеивайте ряды без проверки.
• Событие есть, результата нет. Клик по кнопке не доказывает, что данные сохранились или операция завершилась. Там, где важен результат, измеряйте подтверждённое завершение и сопоставляйте его с ошибками.

Инвалидация старых данных, настройка конкретной аналитической платформы и дизайн A/B-тестов — отдельные темы; здесь речь о выборе и проверке продуктовых метрик.

Что сделать дальше

Выберите один продуктовый вопрос, опишите полезное действие и составьте определения трёх показателей: результата, поведения и ограничителя. Затем проверьте их на небольшом интервале данных вручную: сравните число уникальных пользователей в знаменателе с сырыми событиями, найдите дубли и пропуски. Только после этой проверки выносите метрики на постоянный дашборд. Дальше следите не за количеством графиков, а за тем, меняется ли поведение нужной группы и не ухудшается ли ограничитель.

Источники: Google Research описывает модель HEART для измерения пользовательского опыта; документация PostHog показывает работу с продуктовыми событиями и аналитикой. Подходы в статье не привязаны к версии конкретной платформы: названия полей и возможности интерфейса сверяйте с документацией установленной версии.