Продуктовая команда гордится своим дашбордом — на нём отображается сорок с лишним показателей: DAU, MAU, время в приложении, количество кликов, конверсия по каждому шагу воронки, NPS, отток и десятки других. При этом на вопрос генерального директора "как дела у продукта" никто не может дать однозначный ответ за 30 секунд — метрики существуют россыпью, без иерархии, показывающей, какие из них действительно определяют успех бизнеса, а какие второстепенны.
Отслеживание десятков метрик без структуры — это не аналитика, а шум; продуктовые метрики становятся полезными только тогда, когда выстроены в явную иерархию, связывающую действия команды с результатом для бизнеса.
Происхождение и исследовательская база
Систематизация продуктовых метрик как отдельной дисциплины развивалась в рамках продуктового менеджмента 2010-х годов вместе с распространением специализированных фреймворков (AARRR/Pirate Metrics Дейва Макклюра, North Star Metric, HEART Framework от Google) — общая идея в том, что отдельные фреймворки решают конкретные задачи (воронка роста, единая метрика фокуса, метрики пользовательского опыта), а Product Metrics Framework как общий подход задаёт принципы выбора и структурирования метрик независимо от того, какой конкретный фреймворк используется.
Ключевые идеи и принципы
Принцип: Иерархия метрик от бизнес-результата к операционным действиям
Метрики выстраиваются в дерево: на вершине — метрика, отражающая ключевой бизнес-результат (например, North Star Metric), ниже — метрики, которые на неё влияют (по воронке или по функциональным областям), и в самом низу — операционные метрики конкретных команд. Такая иерархия позволяет любому сотруднику понимать, как его ежедневная работа связана с общим результатом.
Принцип: Разделение input-метрик и output-метрик
Output-метрики (результат — выручка, retention) показывают, что произошло, но не подсказывают, что делать дальше; input-метрики (действия — количество фичей, скорость релизов, качество онбординга) находятся под прямым контролем команды и являются рычагами, влияющими на output. Хороший набор метрик включает оба типа в явной причинно-следственной связи.
Принцип: Ограниченное число ключевых метрик на каждом уровне
На каждом уровне иерархии выбирается небольшое число метрик (обычно 3-5), а не весь возможный набор доступных данных — это заставляет команду делать явный выбор о том, что действительно важно отслеживать, вместо попытки следить за всем одновременно.
Ограничения, слепые зоны и критика
Излишняя фокусировка на ограниченном наборе метрик рискует упустить важные сигналы, не попавшие в выбранный набор — особенно ранние признаки проблем, которые ещё не отразились на ключевых показателях. Метрики также могут стать объектом манипуляции (Goodhart's Law) — когда метрика становится целью, она перестаёт быть хорошим индикатором, если команда начинает оптимизировать именно её значение в ущерб реальному пользовательскому опыту.
Типовые ошибки
Ошибка 1: Отслеживается множество метрик без явной иерархии и связи с бизнес-результатом.
Дашборд содержит десятки показателей, но никто не может объяснить, какие из них действительно критичны, а какие второстепенны.
Как избежать: Выстроить явную иерархию от ключевого бизнес-результата к операционным метрикам команд, ограничив число ключевых метрик на каждом уровне.
Ошибка 2: Отслеживаются только output-метрики без input-метрик, объясняющих причины.
Команда видит падение retention, но не имеет входных метрик (скорость онбординга, качество первого опыта), которые могли бы подсказать, что именно нужно исправить.
Как избежать: Для каждой ключевой output-метрики определить входные метрики, находящиеся под прямым контролем команды.
Главное, что нужно знать
Продуктовые метрики становятся полезным инструментом управления только тогда, когда выстроены в явную иерархию, связывающую бизнес-результат с операционными действиями команды через ограниченный набор ключевых показателей на каждом уровне. Разделение метрик на output (результат) и input (рычаги, находящиеся под контролем команды) превращает набор чисел в инструмент принятия решений, а не просто в отчётность.
План внедрения
Неделя 1: определить ключевую бизнес-метрику верхнего уровня (например, North Star Metric).
Неделя 2: выстроить дерево метрик, определяющих ключевую метрику, ограничив 3-5 показателями на уровне.
Неделя 3: для каждой output-метрики определить input-метрики, находящиеся под контролем команды.
Неделя 4: внедрить регулярную отчётность по построенной иерархии, отказаться от нерелевантных показателей.
Далее: периодически пересматривать иерархию при изменении бизнес-приоритетов.
Книги по теме
Croll A., Yoskovitz B. — «Lean Analytics» (2013). Систематическое руководство по выбору правильных метрик на разных стадиях развития продукта.