Иерархия метрик (с курса ProductStar)

Michael Karpov
Nov 19, 2019 · Unlisted

Михаил Карпов, Product Director Skyeng

Зачем нужна иерархия метрик?

  • помогает фокусироваться на важных метриках и обнаружить точки роста
  • помогает при приоритизации фичей

Когда у вас есть идея фичи удобно её “наложить” на иерархию метрик и понять на какую из метрик больше всего напрямую повлияет фича. Чем ближе данная метрика к “вершине” иерархии метрик (ключевой метрике вашего продукта) тем больше у этой фичи шансов быть успешной.

Алгоритм составления

Удобно визуализировать на MindMap(например, MindMeister, Mind42, Miro) или на листе/флипчарте

  1. Определяем ключевую метрику вашей компании (например, “Выручка”)
  2. Определяем какая ключевая метрика нашего продукта коммитит в ключевую метрику вашей компании (пусть также будет “Выручка”)
  3. Задаём себе вопрос какие 3–5 основных метрик больше всего влияют на ключевую метрику вашего продукта (допустим, это будут “Средний чек”, “Частота покупок”, “Число пользователей” и “% платящих”) — это будут метрики I-го уровня
  4. К каждой из метрик первого уровня задаём вопрос “Какие под-метрики сильнее всего влияют на данную метрику?” (допустим на “Средний чек” влияют “Средняя стоимость товаров” и “Среднее число товаров в заказе”) — это будут метрики II-го уровня
  5. Теперь берём метрики II-го уровня и доходим до метрик III-го уровня и далее — в целом, разумно погрузится до IV-V уровня (в зависимости от размеров и сложности вашего продукта) — строим до того уровня пока это считаем разумным (и есть возможность влиять на метрики данного уровня)

В итоге у вас получится примерно такая иерархия (https://mm.tt/1369696540?t=LW7q1QV7uz):

Image for post
Image for post
https://mm.tt/1369696540?t=LW7q1QV7uz

Нюансы и детали

  • Как простой вариант для старта — я бы предложил вам брать “Выручку” как основную метрику продукта (если у вас нет каких-то иных вводных от руководства компании)
  • По-хорошему список подметрик должен быть настолько полным, чтобы только они могли повлиять на их “родительскую” метрику — таким образом “родительская” метрика полностью состоит и зависит от подметрик
  • Как элементы иерархии стоит включать именно измеримые метрики (а не фичи)
  • Иерархия строится сверху-вниз (от целей компании до метрик, связанных с отдельными фичами)
  • Иерархию метрик обычно составляют разово и обновляют не часто — только при сильных изменениях (раз в год, допустим)
  • Между элементами различных ветвей иерархии метрик вполне могут быть взаимовлияние — в таком случае их можно визуально соединить пунктиром (чтобы учитывать данный факт при принятии решений). Также подметрика может влиять на несколько родительских метрик — но подметрику всё равно стоит вписывать именно к той метрике, на которую она имеет наибольшее влияние

Что дальше с этим делать?

  • Взять свой бэклог и разложить фичи из него по метрикам из иерархии метрик — чем ближе в метрика к верхушке, тем больше шансов у фичи быть успешной (конечно, тут стоит учитывать ещё некоторый коэффициент “плеча” изменения метрики — то есть если вы супер-сильно измените метрику IV-уровня, то это опередит по полезности слабое изменение метрики II-го уровня)
  • Изучить метрики I-го и II-го уровня, сфокусироваться на них и провести брейншторм, определить какие новые фичи могут забустить данные фокусные метрики — затем включить фичи в бэклог вашего продукта

Частотные ошибки

  1. Целеполагание: проверьте что как верхушку иерархии вы выбрали действительно самую важную метрику (подсказка — прочекайтесь с руководителем + по-дефолту можете взять метрику “Выручка продукта”). Действительно ли вы больше всего хотите именно “Число заказов”, а не “Общую выручку” или “% соотношения выручки на одного пользователя к цене его привлечения”?
  2. Проверьте что каждый элемент вашей иерархии является измеримой метрикой (не надо вписывать в иерархию фичи). Иногда вы хотите выделить набор метрик (какую-то из ветвей) и пометить что она полностью в ответственности какого-то из направлений (Маркетинга, Поддержки, …) — это ОК, можно это сделать дополнительным визуальным выделением или подсветить эти элементы определённым цветом, чтобы проще ориентироваться по иерархии
  3. Фокус на метрики, а не на фичи: когда будете соотносить идеи фичей и метрики — то стоит идеи фичей вписывать рядом (или в комментарии) с названием метрики на которую они влияют, но не как отдельный элемент иерархии
  4. Проверьте что у вас в иерархии не зашкаливает число “ванильных метрик” — иначе вы рискуете погнаться накручивать их, упуская ключевые метрики продукта
  5. Не стоит напрямую привязывать подметрику к нескольким “родительским” метрикам — иначе вам будет сложно принимать решения. В крайнем случае — одну связь сделайте основной, а другие обозначьте пунктиром. Конечно, одни метрики влияют на другие, но важно уметь держать фокус и выделять на какую из метрик происходит наибольшее влияние

Ответы на вопросы

На слайде про иерархию метрик было сказано, что фичи нужно ассоциировать с метрикой, и чем ближе эта метрика к глобальной, тем важнее фича. Можешь объяснить подробнее почему это так?
Ведь при построении иерархии мы стремимся разбить метрику на подметрики, из которых она состоит. Как в таком случае, можно повлиять на метрику из уровня 1, не повлияв ни на одну метрику из уровня 2?

Тут нюанс в том, что часто фича влияет сразу на несколько подметрик (допустим, и на “Среднее число товаров в Корзине”, и “Среднее число товаров в Избранном”) — тогда будет неправильно “привязывать” фичу к одной из подметрик и стоит остановиться на “родительской метрике ”метрике — “Среднее число товаров в заказе”.

Чаще всего чем ближе метрика к ключевой метрике продукта, тем больше шансов, что фича “зайдёт” (так как каждая ступенька от подметрики к метрике несёт некоторую вероятность ослабления влияния одной метрики на родительскую и соотвественно статистические потери). Если мы точно знаем что при запуске фича повлияет на нужную нам верхнеуровневую метрику — это здорово, так как не приходится надеяться что “запуск фичи повлияет на метрику уровня IV, а та повлияет на метрику уровня III, а та наконец-то повлияет на метрику уровня II”(тут всегда есть вероятность что на одном из этих этапов произойдёт потеря и влияние не будет настолько сильным как ожидалось).

Интересует вопрос по поводу фундаментальных фич. Если взять пример из лекции с просмотром видео, очень сложно сказать на какую метрику повлияет фича “реализация видео плеера”, без нее вся иерархия оказывается бессмысленной. Мой вопрос заключается в том, выносим ли мы такие “очевидные” задачи за скобки при таком подходе? Делим ли мы фичи на обязательные и необязательные?

Да, технические метрики тоже стоит обязательно включать в иерархию метрик, так как они напрямую влияют на выручку продукта. Например, есть метрика “Длительность просмотра видеозаписи” и на неё будет влиять “%видеозаписей без обрывов просмотра” — и вот на эту техническую метрику будет влиять фича “Качество видео-плеера”.

Не могу распутаться. У меня есть идея нового продукта = приложение для кормящих мам, где учет рутины, статьи, аудио с белым шумом и вот это вот все. Я якобы провел опрос (буду перепроводить на форумах, ибо понимание пришло после проведения), якобы подтвердил что проблема есть.
Дальше определил первую бизнес цель — 200К активных пользователей. Дальше попытался разбить на метрики, которые могут ее достичь. https://mm.tt/1353341843?t=4FWfHkjndv
Определил ключевые 3 и попробовал в них покреативить фичи. Что-то даже получилось.
НО. Я так и не понимаю, где тут планируется разработка самого приложения. Или это и есть при построении иерархии метрик, и я не правильно определяю метрики для нового приложения, которые влияют на запуск?

В данном случае, я бы предложил так:

  • Ключевая метрика продукта — “Выручка”
  • Метрики I-го уровня: “Число активных пользователей”, “% платящих”, “Выручка с пользователя за месяц”
  • “Число активных пользователей” разобьётся на метрики II-го уровня такие как “% людей проходящих онбординг” и Retention (зависит от типа продукта, допустим 7го и 30го дня)
  • В “% платящих”, например, попадёт метрика “Как часто пользователь видит оффер с покупкой”
  • В “Выручка с пользователя за месяц” попадут метрики связанные со стоимостью и количеством ваших услуг
  • Маркетинговые метрики воронки и стоимости привлечения можно (для упрощения схемы) вынести в отдельную иерархию-воронку (там ключевой метрикой будет стоимость привлечения CAC, и как подметрики попадут срезы по различным каналам привлечения, которые разобьются на подметрики стоимости привлечения по каналу и конверсии в установку/регистрацию) — скорее всего руководство компании будет просить от вас соблюсти баланс Выручки и приемлемого CAC

Если у вас ещё остались вопросы — приходите в личку @michailkarpov — подскажу нюансы и дополню данное объяснение 😃

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store