Top.Mail.Ru
Статьи

Иерархия метрик


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

Откуда взялась модель

К концепции иерархии метрик я пришел, когда работал в LAF24, чтобы попытаться разрешить противоречие вида «сайт как продукт». Противоречие простое и банальное: есть сайт, на котором продаются товары. Является ли в этом случае сайт продуктом или всего лишь точкой контакта, где совершается определенная конверсия?


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

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

Так чем же тогда является сайт — omnichannel touchpoint или search product? Ответ, конечно же, один единственный — и тем, и другим.

Смысл модели на примере LAF24


Сайт как продукт


Иерархия метрик строится сверху вниз. Вершина иерархии метрик продукта — это North Star метрика, определяющая его ценность. Какая ценность сайта как движка для поиска автозапчастей с точки зрения клиента? В том, чтобы я, как пользователь, на любой свой запрос смог найти нужную автозапчасть. Причем не абы какую, а правильно подобранную.

Автобизнес по сложности ассортимента превосходит все остальные отрасли, т.к. крупные сети торгуют автозапчастями разных брендов автомобилей (это около 15-20 тысяч модификаций автомобилей), к каждой модификации которого привязано порядка двух тысяч деталей. А еще есть понятие кроссировки — это когда один товар можно заменить на другой. А еще на каждый такой товар есть 10-20-30-40-50 предложений от разных поставщиков. Тем самым количество уникальных объектов, которым приходится управлять в режиме реального времени — это порядка 3-4 миллионов. А это я еще услуги сюда не добавил, которые каждая на свою категорию автозапчастей в рамках конкретной модификации. Поэтому качество связей «правильности» подбора при таком количестве данных — одна из важнейших задач. Для её решения в компаниях используются десятки людей для ручной верификации данных (а мы использовали data science).

North Star этой иерархии будет «Количество правильных подобранных автозапчастей», но в отличие от продажи телефонов в автобизнесе запчасть, как правило, НЕ ищут по названию или категории. Вариантов поиска несколько, и чтобы ключевая ценность сохранялась, мы должны предоставить возможность правильного подбора для всех вариантов поиска запчастей, т.е. North Star декомпозируется на количество подобранных автозапчастей каждым конкретным способом.

Каждый способ уникален и совершенно не связан с другим ни с точки зрения интерфейса, ни с точки зрения реально используемых данных (ну почти — мы для решения этой проблемы построили внутренний продукт PIMS, Product Information Management System). Например, чтобы мне подобрать какой-либо товар по автомобилю, мне нужно сначала выбрать бренд автомобиля, потом серию, потом поколение, потом модификацию, потом найти категорию автозапчастей и только уже после этого мне откроется перечень подходящих деталей.


Этот user flow представляет собой обычную воронку, но в рамках иерархии «перевернутую». При этом логика расчет конверсий остаётся той же самой: абсолютные значения перемножаются с конверсией и являются новыми вводными для следующего этапа, которые также перемножаются с конверсий и т.д. до самого конца, пока от запросов поиска по автомобилю мы не придем к количеству найденных таким образом автозапчастей. Это второй принцип иерархии — к метрикам одного уровня должны применяться какие-то математические операции таким образом, чтобы на выходе получалась метрика уровня выше. Метрики для других вариантов поиска декомпозируются аналогично исходя из своего контекста.

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


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

На примерах точки роста обозначены как текст с голубой подложкой, к которому ведут стрелочки.

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

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


Cайт как omnichannel touchpoint



Представим сайт как точку на customer journey map клиента компании. Какая ключевая ценность может быть этой точки? Для чего она нужна? С точки зрения омниканальной модели сайт играет несколько ролей:
  • Во-первых, является интернет-магазином, на котором клиент может самостоятельно найти и оформить заказ.
  • Во-вторых, местом приземления трафика для дальнейшей его конвертации либо в заказ, либо в звонок, либо в чат, либо в обратный звонок.

Тем самым мы можем сказать, что North Star сайта как точки будет являться количество достигнутых целей (goal completion rate), который декомпозируется на четыре возможных цели: заказ, звонок, чат, обратный звонок.


Рассмотрим количество заказов — видим классическую воронку: чтобы оформить заказ, нужно добавить в корзину, чтобы добавить в корзину, нужно найти товар, чтобы найти товар, нужен кто-то (трафик). Но, секундочку, ведь именно «Количество правильно подобранных автозапчастей» — это North Star сайта, как продукта!

Что это значит? Это значит, что работая над повышением ценности сайта, как поискового продукта, продакт-менеджер (или хрен знает еще кто) всё равно будет влиять на ключевой показатель сайта как omnichannel touchpoint.

Влияя на ценность, мы влияем на деньги.

Но с другой стороны это же самое значит, что улучшение конверсии в корзину или заказ, или звонок, или чат, или обратный звонок НЕ являются действиями, влияющими на ценность сайта как поискового продукта. И это совершенно нормально. Проблема тут заключается лишь в том, что ответственность за повышение этих показателей зачастую в ecommerce проектах перекладывают на продакт менеджеров, но продакт менеджер, по смыслу своей деятельности, должен отвечать за увеличение ценности продукта, а не эффективности ecommerce или omnichannel touchpoint. Для этого есть другая роль — ecommerce manager или marketing manager.

Смысл модели на примере TextBack


Иерархия метрик продукта

TextBack — это платформа для рассылок в мессенджерах. Работает на b2b2c-рынке. Продукт позволяет бизнесу автоматизировать коммуникации со своими клиентами в мессенджерах через рассылки, чат-боты и цепочки сообщений. Т.е. бизнес приходит в продукт, набирает базу лидов или загружает свою базу контактов, создает рассылки/настраивает цепочки и отправляет их по этой базе по выбранным каналам, например, WhatsApp или ВКонтакте. Все очень похоже на email-маркетинг.



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

Из чего состоит количество целевых действий за период? Из среднего количество целевых действий с одной рассылки на количество запущенных кампаний рассылок. Из чего складывается среднее количество? Из количества просмотров рассылки на CTR. Из чего складывается количество просмотров? Из количества рассылок конкретным клиентам на Open Rate. При этом количество рассылок конкретным клиентам складывает из количества лидов в базе, умноженное на коэффициент сегментации (ведь не всем же нужно отправлять конкретную кампанию рассылки). Декомпозировать можно и глубже, но для примера пока хватит — хотелось показать, что смысл математики весьма простой.

Математика скоринга и плечо метрик

Предположим, что в среднем значения показателей продукта большей части клиентов примерно такие:
  • Lead Count = 10.000 (т.е. в базе у клиента есть 10.000 его клиентов)
  • Segmentation Rate = 90% (т.е. клиент отправляет одну рассылку почти на всю свою базу)
  • Open Rate = 80% (в мессенджерах конверсия в просмотр намного выше, чем в email)
  • CTR = 20% (т.е. 20% из тех, кто открыл рассылку кликнули на CTA-элемент)
  • Message Campaign Count = 4 (т.е. за период клиент отправляет только четыре рассылки).

Goal Count = (((Lead Count * Segmentation Rate) * Open Rate) * CTR) * Message Campaign Count

Математика нам говорит, что 5.760 целей будет достигнуто при текущих показателях (5.760 конечных клиентов перейдут на целевую страницу клиента TextBack за период).

А теперь предположим, что у меня есть две фичи. Одна потенциально может увеличить Open Rate на 2 п.п., а вторая CTR на 0,4 п.п. Предположим, что время их реализации, как и наша уверенность в этих оценках, примерно одинаковые. Какую фичу будем делать первой? С точки зрения иерархии метрик продукта — ту, что больше влияет на North Star. В нашем случае, это первая фича: она дает 5.904 (Open Rate) против 5.875,2 (CTR) достигнутых целей.

В рамках иерархии метрик, метрика North Star здесь — это значение impact в таких скоринговых моделях, как ICE или RICE.

Иерархии метрик как инструмент анализа ценностного предложения и бизнес-модели компании



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

Проведем анализ, каким образом ценность продукта участвует в формировании прибыли компании. В каком месте здесь пересекаются метрики иерархии продукта с метриками иерархии компании? Это тот вот оранжевый кусочек — количество лидов. Но, подождите, ведь количество лидов не несет само по себе ценности — это вообще входные данные для того, чтобы пользоваться сервисом. Ценность ведь продукта не в том, чтобы залить туда свою базу лидов, а в том, чтобы рассылать этой базе лидов рассылки и конвертить их в целевое действие.

Оранжевым выделена метрика, которая общая для иерархии метрик продукта и иерархии метрик компании. Такие метрики в терминологии иерархии называются traction-метриками, т.к. напрямую связаны с увеличением денег компании.

Т.е. любое повышение ценности продукта не позволяет с текущих клиентов брать больше. Другими словами, компания тратит деньги и время в улучшение ценности продукта, но это увеличение ценности не приводит к увеличению прибыли. В основу экономики тарифа взят не тот ресурс (goal count), который ценен для клиента, а тот, который проще всего монетизировать (lead count).

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


Что такое ценность? Это степень, в которой продукт закрывает потребности пользователей (решает проблемы клиентов). В b2b для доказательства приносимой ценности используются case study, который невозможен без приведения конкретных показателей эффективности. В случае продукта TextBack — это количество целевых действий за период, как главная метрика ценности продукта.

Восприятие ценности / ценностное предложение в первую очередь влияет на конверсию из трафика в регистрацию (лид) / триал (проспект), но только его одного недостаточно, чтобы создать покупку. На конверсию в покупку влияет оффер (стоимость) этого ценностного предложения, который выражен в стоимости тарифа.

Здесь мы снова приходим к противоречию, ведь я, как клиент, вижу ценность в goal count, а оффер мне делают по лидам. Т.е. я должен что-то отдать компании (заплатить за лидов) еще до того, как компания что-то отдала мне (получить профит с рассылок). Вот последний момент и рассмотрим подробнее.

Иерархия метрик клиента


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

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

При этом оборот с одного вебинара состоит из количество пришедших на конверсию в покупку на средний чек. Количество пришедших зависит от количества регистраций на конверсию в посещение вебинара. Количество регистраций от количество посетителей лендинга на конверсию в регистрацию на вебинар. А вот уже количество посетителей лендинга и зависит от того, какое количество просмотров рассылки TextBack было, умноженное на CTR.

Зеленым отмечены те метрики, которые пересекаются в иерархии метрик продукта и иерархии метрик клиента.

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

Конкуренция за долю в кошельке клиента


Построенная иерархия метрик клиента в контексте анализируемого продукта показывает еще одну важную деталь — это точку конкуренции за кошелек клиента.

Тот же пример с сегментов вебинаров. У них есть лендинги, на которые идет трафик. Рассылки, обеспечиваемые продуктом TextBack, составляют только часть этого трафика, наравне с органикой, рекламными кампаниями или даже конкурентными продуктами. Точкой конкуренции здесь будет метрика «Количество посетителей лендинга», которая складывается из метрик Open Count и CTR рассматриваемого продукта.

Коммерческая цель любого продукта в этом контексте — вытеснить доли других продуктов, влияющие на эту метрику, чтобы оставаться полноправным лидером. Каким образом это сделать? Показывать эффективность большую, чем это делают конкуренты. В данном случае — генерить больше просмотров рассылок и конверсии с них. Или же заходить на территорию конкурентов, начиная решать проблему клиента их способами, превращая изначальный продукт в экосистему вокруг решения проблемы клиента.

Итого

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

Планируется еще одна статья, в которой я покажу, каким образом иерархию метрик можно использовать для поиска драйверов роста.

P.S.

Конечно же, не я придумал использовать древовидные структуры для конфигурации метрик. Например, подобные штуки уже давно применял Михаил Карпов еще во Вконтакте, а сейчас и в SkyEng. Подобные структуры используются для объяснения сложно составных формул, вроде LTV или моделей юнит-экономики — ничего не ново под луной =) 

Update

Никита Ефимов подсказал, что год назад Елена Серёгина как раз раскрывала эту тему на Product Sense. А еще есть потрясающая статья от неё. Поэтому свои слова про первенство я вынужден забрать назад, да и вообще изменить термин «пирамида» (он раньше был использовать в статье) на «иерархию», как более правильно отображающий смысл.
Продакт-менеджмент