Дерево метрик: как строить и не сломать бизнес

Даниил Фенелонов 26 апреля 2026 г. 8 минут чтения

Содержание

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

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

Сегодня разберём, как строить, на что напарываться и когда одного дерева недостаточно.

Дисклеймер

Я думаю, описание дерева метрик, данное в этом посте, дает более явное понимание того, что из себя оно представляет. Большинство гайдов заключаются в том, что “а вот давайте посмотрим дерево для сервиса”. Сверху будет Revenue (а почему?). В этом гайде важно, что метрика у бизнеса может быть любая, главное, чтобы дерево удовлетворяло главным условиям

Что такое дерево метрик

Дерево метрик – это декомпозиция бизнес-метрики на составляющие, связанные математически. Важно понимать, что это не список важных метрик, не логическая цепочка “Что на что влияет”, а структура, где каждый узел раскладывается на дочерние через конкретную операцию: умножение, сложение или деление.

Это даёт два огромных преимущества аналитику или владельцу бизнеса или бизнес-юнита.

Диагностика. Метрика упала, то вы идёте по дереву вниз и находите ветку, которая провалилась. Не гадаете, а проверяете уровень за уровнем.

Приоритизация. Хотите вырастить revenue, то считаете чувствительность каждой ветки (что будет, если эту метрику улучшить на 10%) и выбираете самую рычажную.

Как строить: сверху вниз

Начинаем с North Star метрики, той, которая лучше всего отражает ценность бизнеса. Для e-commerce это обычно revenue, для соцсети DAU, для SaaS – MRR. В целом для каждого бизнеса ключевая метрика своя, для этого гайда это не важно. Итак, выбрали ключевую метрику. Дальше раскладываем математически.

Пример

Давайте в качестве примера рассмотрим e-commerce бизнес.

Верхний уровень:

\text{Revenue} = \text{Users} \times \text{Conversion} \times \text{AOV}

Каждый компонент раскладывается дальше:

\text{Users} = \text{New Users} + \text{Returning Users}

\text{Conversion} = \text{Add to Cart Rate} \times \text{Checkout Rate} \times \text{Payment Success Rate}

\text{AOV} = \text{Items per Order} \times \text{Avg Item Price}

И так далее. Каждый уровень можно раскрывать глубже, пока не дойдёте до метрики, на которую можно непосредственно повлиять.

Дерево метрик e-commerce: Revenue раскладывается на Users × Conversion × AOV, каждый компонент декомпозируется дальше на 3-4 уровня

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

Правила декомпозиции

Каждый уровень представляет собой математическую операцию. Если нельзя записать формулу, связывающую родителя с детьми, то это не дерево метрик. Рассуждение “Revenue зависит от UX” – гипотеза, а не декомпозиция.

Проверка: числа должны сходиться. Подставьте реальные значения в каждый узел. Если $\text{Users} \times \text{Conversion} \times \text{AOV} \neq \text{Revenue}$ , то у вас ошибка в структуре.

MECE* на каждом уровне. Дочерние метрики должны быть взаимоисключающими и исчерпывающими. Users = New + Returning представляют собой MECE, а Users = Mobile + Paid — нет (пересечение: пользователь может быть и mobile, и paid).

MECE (Mutually Exclusive, Collectively Exhaustive) – принцип из консалтинга. Означает две вещи:

Mutually Exclusive: элементы не пересекаются. Каждый объект попадает только в одну категорию.

Collectively Exhaustive: элементы покрывают всё. Ничего не пропущено.

Подводный камень №1: две North Star метрики

Иногда одной метрики наверху недостаточно. И если проигнорировать это — дерево будет врать.

Маркетплейс

У маркетплейса на самом деле две компоненты здоровья: спрос (покупатели, GMV) и поставка (продавцы, ассортимент). Если поставить наверх только GMV, команда начнёт оптимизировать крупных продавцов, потому что у них оборот больше. Мелкие продавцы не получают трафик, уходят, ассортимент сужается. Через полгода крупный продавец уходит к конкуренту, и supply-сторона схлопывается.

GMV росло каждый месяц. Дерево метрик было зелёным. А бизнес стал хрупким.

Подписочный бизнес

Revenue растёт, поэтому подняли цену на 20%. Дерево с revenue наверху показывает рост. Но retention тихо падает: часть пользователей не готовы платить больше и уходят. Через два квартала отток съедает весь рост от повышения цены.

Что делать

Если у бизнеса два показателя здоровья, например, growth и retention, demand и supply, revenue и engagement, то нужны два дерева или одно дерево с двумя корнями. И между ними зона конфликта: набор метрик, которые при оптимизации одного корня ухудшают другой.

Две North Star метрики маркетплейса: GMV (demand) и Active Sellers (supply) с зоной конфликта между ними

Зона конфликта представляет собой не проблему, а доп информацию. Она показывает, где нужен trade-off, а не бездумная оптимизация.

Подводный камень №2: метрики в дереве не независимы

\text{Revenue} = \text{Users} \times \text{ARPU}

Формула простая. Кажется: увеличь количество пользователей, revenue вырастет пропорционально. Но если вы привлекаете дешёвый трафик (performance-кампании с широким таргетингом), Users растёт, а ARPU падает. Новые пользователи покупают меньше. Чистый эффект на revenue может быть нулевым или даже отрицательным.

Это не баг дерева. Метрики-сиблинги (дети одного узла) почти всегда коррелированы. Вот несколько примеров:

Users ↑ → ARPU ↓: дешёвый трафик разбавляет качество
Conversion ↑ → AOV ↓: агрессивные скидки повышают конверсию, но снижают чек
New Users ↑ → Retention ↓: виральный рост привлекает нецелевую аудиторию

Что делать

Для каждой пары родитель-ребёнок задавайте вопрос: если я изменю одного ребёнка, что произойдёт с другим? Если ответ «ничего», то отлично, метрики независимы. Если ответ «второй поедет в обратную сторону», то вы нашли точку конфликта, и оптимизировать нужно аккуратно.

Практический приём: при анализе изменений всегда раскладывайте эффект на объём и качество. Users вырос на 20%, ARPU упал на 10%, чистый эффект на Revenue = +8%. Без разложения вы бы увидели только +8% и не поняли, что происходит внутри.

Подводный камень №3: метрика-прокси, которая живёт своей жизнью

Вы раскладываете Retention и решаете мерить его через $\text{DAU}/\text{MAU}$ (stickiness). Команда начинает оптимизировать DAU: пуши, нотификации, геймификация. DAU растёт. Стикинес растёт. Все счастливы.

Но это не настоящий retention. Пользователи открывают приложение, потому что их дёргают пушами, проводят 10 секунд и закрывают. Engagement нулевой, монетизация не растёт, а через месяц пользователи выключают уведомления и уходят.

Метрика-прокси разошлась с тем, что она должна была измерять.

Что делать

У каждой метрики в дереве должен быть guardrail — контрметрика, которая сигнализирует, что оптимизация пошла не туда.

Примеры:

Метрика	Guardrail
DAU	Avg Session Duration, Actions per Session
Автоматизация	VOC
Conversion Rate	Return Rate, Refund Rate
New Users	Day 7 Retention, CAC
Revenue	Gross Margin, Churn Rate
CTR (рекомендации)	Time on Content, Unsubscribe Rate

Guardrail не обязан расти. Он обязан не падать, пока основная метрика растёт. Если основная метрика растёт, а guardrail падает — вы оптимизируете прокси, а не реальность.

Как использовать дерево на практике

Сценарий 1: Диагностика

Давайте представим, что Revenue упал на 12% за 4 недели.

Шаг 1. Открываем дерево. Revenue = Users × Conversion × AOV. Смотрим, что изменилось.

Шаг 2. Users остался без изменений. AOV без изменений. Conversion упала на 11%. Идём глубже.

Шаг 3. Conversion = Add to Cart × Checkout × Payment Success. Add to Cart стабилен. Checkout в норме. Payment Success упал с 98% до 87%.

Шаг 4. Payment Success по платёжным методам: оплата по карте в норме, Apple Pay упал до 64%. Проверяем и оказалось, что сломалась интеграция после обновления (или 2022 года) SDK.

Без дерева вы бы открыли дашборд, увидели красный Revenue, и начали гадать. С деревом вы определите причину в 4 шага.

Диагностика падения Revenue на 12%: зелёные узлы в норме, красная ветка ведёт от Conversion через Payment Success к сломанной интеграции Apple Pay SDK

Сценарий 2: Приоритизация

Теперь давайте представим, что вы хотите вырастить Revenue на 15%. Что улучшать?

Текущие значения: Users = 100K, Conversion = 3%, AOV = $50.

Рычаг	Рост на 10%	Эффект на Revenue
Users: 100K → 110K	+10K users	+$15K (+10%)
Conversion: 3% → 3.3%	+0.3 п.п.	+$15K (+10%)
AOV: $50 →$ 55	+$5 per order	+$15K (+10%)

Математически одинаковый эффект, но теперь задайте вопрос: что дешевле и быстрее сдвинуть на 10%? Привлечь на 10% больше пользователей (маркетинговый бюджет)? Поднять конверсию на 0.3 п.п. (A/B-тесты с чекаутом)? Увеличить средний чек на $5 (upsell, бандлы)?

Дерево не даёт ответ, но даёт хорошую фактуру для вопроса.

Итого

Дерево метрик – это не mindmap и не список важных метрик. Каждая связь представляет собой математическую формула. Если числа не сходятся — дерево неправильное.

Одной North Star не всегда достаточно. Если у бизнеса два “здоровья”, то нужны два корня и осознанная зона конфликта между ними.

Метрики-сиблинги коррелированы. Users ↑ → ARPU ↓ — классика. Всегда раскладывайте эффект на объём и качество.

Каждой метрике — guardrail. Без контрметрики вы рискуете оптимизировать прокси, а не реальность.

Дерево представляет из себя живую сущность. Оно меняется, когда меняется продукт. Зафиксируйте его, повесьте в Confluence, и обновляйте раз в квартал. Это не разовое упражнение, а инструмент ежедневной работы.

Поделиться в Telegram