Посчитать и систематизировать: зачем бизнесу иерархия метрик и как ее создать — на примере Hoff

Выручка, число заявок и покупок, средний чек, маржинальность — все эти классические метрики служат основой для ��изнес-решений. Но просто собирать их недостаточно: важно еще и выстроить иерархию. Как и зачем это делать, рассказал руководитель группы аналитики данных Егор Лысянский.

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

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

Иерархия метрик помогает решать и другие задачи бизнеса — разберем их на примере продукта.

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

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

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

Продуктовым командам проще общаться, когда у них есть общее понятийное поле. В частности, это помогает четко определить зоны ответственности, найти пересечения таких зон и «слепые зоны» — то есть те, за которые никто не отвечает. В моей практике был случай, когда один продакт-менеджер отвечал за корзину, второй — за чекаут, но между корзиной и чекаутом стоял этап авторизации: чтобы сделать заказ, нужно было залогиниться. У этого этапа не было ответственных — поэтому, когда произошел небольшой сбой и 10% пользователей не могли авторизоваться, никто не понял, что случилось.

Рассмотрим создание иерархии на примере нашего клиента — мультиформатного ритейлера мебели и товаров для дома Hoff. Коллеги обратились к нам за консультацией по построению отдела продуктовой аналитики в e-commerce, а мы в числе прочего порекомендовали им разработать иерархию метрик. При этом в компании была довольно подробная факторная модель с четырьмя ключевыми зонами: трафик, конверсия, средний чек и выкуп. Это неплохой подход, но в случае с Hoff его было недостаточно — в активно растущей компании с большим числом продуктовых команд и пересекающихся зон ответственности стало сложно синхронизировать действия. Поэтому коллеги с радостью поддержали нашу идею.

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

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

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

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

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

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

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

Зачем это нужно? Мы понимаем, что каждая продуктовая фича влияет на какую-то метрику (или несколько метрик). Но эта метрика может находиться довольно далеко от ключевой метрики бизнеса — выручки. Соответственно, мы не видим, как именно изменение фичи отразится на выручке.

Чуть выше я говорил, что менеджеры не могли объективно оценить удобство заполнения данных на чекауте. Между тем при вводе адреса доставки на сайте использовался сервис по нормализации адресов: то есть пользователь начинал вводить город и улицу — и ему предлагались варианты в выпадающем списке. Проблема в том, что в реестре есть не все данные: например, в него не всегда оперативно добавляют новостройки. А если адрес отсутствует в списке, пользователь не может оформить заказ.

Сам сервис по нормализации утверждал, что в реестре есть 99,9% адресов, то есть на новостройки и небольшие дома в поселках приходилось всего 0,1% адресов. Но в структуре аудитории Hoff этот 0,1% вырастал до 5%, поскольку профиль компании — мебель и товары для дома, и среди ее клиентов много тех, кто недавно купил квартиру и сейчас ее обустраивает.

Итак, мы видим: если исправить проблему и добавить возможность заполнить адрес вручную, чекаут будет на 5% успешнее. Но бизнесу этот показатель ни о чем не говорит — чтобы с ним работать, его нужно конвертировать в деньги. И вот тут на помощь приходит математическая модель: с ней мы можем посчитать, сколько прибыли принесут эти 5%. У нас получилось несколько десятков миллионов рублей в квартал. Конечно, ради такого стоит внести изменения.

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