Продуктовые метрики (Product Metrics Framework)

Продуктовая команда гордится своим дашбордом — на нём отображается сорок с лишним показателей: DAU, MAU, время в приложении, количество кликов, конверсия по каждому шагу воронки, NPS, отток и десятки других. При этом на вопрос генерального директора "как дела у продукта" никто не может дать однозначный ответ за 30 секунд — метрики существуют россыпью, без иерархии, показывающей, какие из них действительно определяют успех бизнеса, а какие второстепенны.

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

Происхождение и исследовательская база

Систематизация продуктовых метрик как отдельной дисциплины развивалась в рамках продуктового менеджмента 2010-х годов вместе с распространением специализированных фреймворков (AARRR/Pirate Metrics Дейва Макклюра, North Star Metric, HEART Framework от Google) — общая идея в том, что отдельные фреймворки решают конкретные задачи (воронка роста, единая метрика фокуса, метрики пользовательского опыта), а Product Metrics Framework как общий подход задаёт принципы выбора и структурирования метрик независимо от того, какой конкретный фреймворк используется.

Важно понимать, что Product Metrics Framework не заменяет и не поглощает специализированные фреймворки — это соотношение уровня абстракции, а не конкуренции: AARRR (Pirate Metrics) даёт готовую структуру метрик воронки роста (Acquisition-Activation-Retention-Referral-Revenue), North Star Metric — методику выбора единственной метрики фокуса всей компании, а HEART Framework (Google, Rodden/Hutchinson/Fu, 2010) — структуру метрик именно пользовательского опыта (Happiness, Engagement, Adoption, Retention, Task success). Каждый из них — самостоятельная, отдельно документированная методика; Product Metrics Framework задаёт общий принцип иерархии (см. ниже), в рамках которого выбранная North Star Metric может занять верхний уровень дерева, а метрики AARRR или HEART — стать output- или input-метриками на более низких уровнях.

Ключевые идеи и принципы

1. Принцип: Иерархия метрик от бизнес-результата к операционным действиям

   Метрики выстраиваются в дерево: на вершине — метрика, отражающая ключевой бизнес-результат (например, North Star Metric), ниже — метрики, которые на неё влияют (по воронке или по функциональным областям), и в самом низу — операционные метрики конкретных команд. Такая иерархия позволяет любому сотруднику понимать, как его ежедневная работа связана с общим результатом.

2. Принцип: Разделение input-метрик и output-метрик

   Output-метрики (результат — выручка, retention) показывают, что произошло, но не подсказывают, что делать дальше; input-метрики (действия — количество фичей, скорость релизов, качество онбординга) находятся под прямым контролем команды и являются рычагами, влияющими на output. Хороший набор метрик включает оба типа в явной причинно-следственной связи.

3. Принцип: Ограниченное число ключевых метрик на каждом уровне

   На каждом уровне иерархии выбирается небольшое число метрик (обычно 3-5), а не весь возможный набор доступных данных — это заставляет команду делать явный выбор о том, что действительно важно отслеживать, вместо попытки следить за всем одновременно.

4. Принцип: Actionable-метрики вместо vanity-метрик

   Термин vanity metric («тщеславная метрика») ввели в широкий оборот именно Алистер Кролл и Бенджамин Йоскович в книге «Lean Analytics» (2013, см. блок «Книги по теме» ниже) — это показатель, который почти всегда растёт (число регистраций, суммарные скачивания, общее число просмотров за всё время) и приятно смотрится на графике, но не подсказывает, какое конкретное действие предпринять дальше. Ему противопоставляется actionable-метрика — показатель, изменение которого прямо указывает на конкретное действие (например, конверсия из триала в оплату по когорте: если она падает, ясно, что чинить онбординг именно этой когорты). При построении иерархии метрик (см. предыдущий принцип) в неё осознанно включают actionable-метрики на input-уровне и просеивают vanity-метрики, которые лишь создают иллюзию прогресса.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: Отслеживается множество метрик без явной иерархии и связи с бизнес-результатом.

   Дашборд содержит десятки показателей, но никто не может объяснить, какие из них действительно критичны, а какие второстепенны.

   Как избежать

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

2. Ошибка 2: Отслеживаются только output-метрики без input-метрик, объясняющих причины.

   Команда видит падение retention, но не имеет входных метрик (скорость онбординга, качество первого опыта), которые могли бы подсказать, что именно нужно исправить.

   Как избежать

   Для каждой ключевой output-метрики определить входные метрики, находящиеся под прямым контролем команды.

3. Ошибка 3: метрика становится целью премирования или отчётности без независимой проверки её достоверности.

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

   Как избежать

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

4. Ошибка 4: North Star выбирается как метрика, удобная для отчётности, а не как метрика, реально отражающая ценность для пользователя.

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

   Как избежать

   North Star должна отражать момент, когда пользователь реально получил ценность от продукта (для Airbnb — количество забронированных ночей, а не выручка платформы), выручка при этом отслеживается отдельной метрикой более низкого уровня.

5. Ошибка 5: иерархия строится один раз и не пересматривается при изменении продукта или стратегии.

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

   Как избежать

   закладывать регулярный пересмотр иерархии (например, раз в квартал или при смене продуктовой стратегии) как явный процесс, а не разовое упражнение.

План внедрения

1. Неделя 1: определить ключевую бизнес-метрику верхнего уровня (например, North Star Metric).

2. Неделя 2: выстроить дерево метрик, определяющих ключевую метрику, ограничив 3-5 показателями на уровне.

3. Неделя 3: для каждой output-метрики определить input-метрики, находящиеся под контролем команды.

4. Неделя 4: внедрить регулярную отчётность по построенной иерархии, отказаться от нерелевантных показателей, и запланировать периодический независимый аудит методологии расчёта ключевых метрик.

   Далее: периодически пересматривать иерархию при изменении бизнес-приоритетов.

Как реализовать этот план с помощью фрейма «Продуктовые метрики» в OrgDevTools

Фрейм методики в OrgDevTools — не набор карточек, а настоящая визуальная иерархия из трёх уровней, соединённых линиями связи: на вершине — единственная карточка «Ключевая метрика (North Star)» с полями названия и текущего значения/цели; на втором уровне — произвольное число output-метрик (результат), каждая из которых визуально соединена линией с North Star; на третьем уровне — произвольное число input-метрик (рычаги под контролем команды), где для каждой input-метрики нужно явно отметить чипами, на какую именно output-метрику она влияет, — эта связь визуализируется отдельной линией другого цвета.

Вердикт фрейма проверяет заполнение иерархии последовательно сверху вниз: сначала требует задать North Star, затем — хотя бы одну output-метрику, влияющую на неё, и только затем — input-метрики, явно связанные хотя бы с одной output-метрикой (не просто перечисленные без связи) — именно эта последняя проверка прямо защищает от Ошибки 2 (input-метрики существуют, но не привязаны ни к одному результату, то есть непонятно, на что реально влиять).

Связь с планом внедрения из блока выше прямая: на неделе 1 плана заполняется верхняя карточка North Star; на неделе 2 — карточки output-метрик второго уровня (с автоматической прорисовкой соединительных линий к North Star по мере добавления каждой карточки); на неделе 3 — карточки input-метрик с обязательной привязкой чипами к output-метрикам, что и есть содержание этой недели плана в буквальном, а не переносном смысле; на вкладке «Итоги» фрейм показывает не просто список введённых значений, а именно тот последовательный вердикт готовности иерархии, который описан выше, — это и есть проверка полноты недели 4 плана.

Книги по теме

Croll A., Yoskovitz B. — «Lean Analytics» (2013). Систематическое руководство по выбору правильных метрик на разных стадиях развития продукта.

Goodhart C. — «The Problems of Monetary Governance: The British Experience» (Monetary Economics Papers, 1975). Первоисточник закона Гудхарта о разрушении статистической закономерности под давлением управления.