дерево метрикдекомпозицияпродуктовая аналитикаSQLметрики

Дерево метрик: как построить и декомпозировать

2026-07-10 12 мин

Коротко: Дерево метрик строится сверху вниз: берёте одну главную цель бизнеса или продукта, а затем раскладываете её на множители и слагаемые так, чтобы между родителем и детьми была точная формула. Мультипликативная декомпозиция режет метрику на произведение (GMV = заказы × средний чек), аддитивная — на сумму (выручка = сумма по каналам). Главное правило: если между узлом и его детьми нельзя написать знак равенства с числами, это не дерево метрик, а просто список показателей рядом.

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

Что такое дерево метрик и зачем оно аналитику?

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

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

Зачем это аналитику на практике:

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

Как выбрать вершину дерева метрик?

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

Хорошая вершина проходит три проверки:

Типичные вершины по типу бизнеса:

Тип бизнесаЧастая вершинаПочему
МаркетплейсGMVОборот отражает и спрос, и предложение
Подписочный SaaSMRR или LTVПовторяющаяся выручка = здоровье модели
Медиа / контентDAU или время в продуктеВовлечение = основа монетизации
E-commerceВыручка или AOV × заказыПрямая связь с деньгами

Частая ошибка — брать две вершины сразу («растим и выручку, и retention»). Тогда получаются два дерева, и при конфликте целей команда не знает, что важнее. Вершина должна быть одна; всё остальное — либо её дети, либо guardrail-метрики сбоку.

Как работает мультипликативная декомпозиция?

Мультипликативная декомпозиция — это разложение метрики в произведение множителей. Между родителем и детьми стоит знак умножения, и при перемножении детей получается ровно родитель.

Классический пример для маркетплейса:

GMV = Число заказов × Средний чек

Дальше каждый множитель раскладывается ещё глубже:

Число заказов = Число пользователей × Конверсия в заказ × Заказов на покупателя
Средний чек   = Число позиций в заказе × Средняя цена позиции

Красота мультипликативного разложения — в интерпретации. Если GMV вырос на 10%, а число пользователей на 10% при неизменной конверсии и чеке, вывод однозначный: рост чисто за счёт трафика, качество продукта не изменилось.

Ещё один канонический пример — воронка, которая целиком мультипликативна:

Оплаты = Визиты × CR в регистрацию × CR в корзину × CR в оплату

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

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

Как работает аддитивная декомпозиция?

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

Типичные разрезы для суммы:

Выручка = Выручка_органика + Выручка_платный + Выручка_email + Выручка_прочее

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

На практике дерево смешанное: верхние уровни часто аддитивные (разрез по каналам), а внутри каждого канала — мультипликативные (визиты × конверсия × чек). Это нормально и даже желательно:

GMV = GMV_мобайл + GMV_десктоп                         (аддитивно)
GMV_мобайл = Визиты_мобайл × CR_мобайл × Чек_мобайл    (мультипликативно)

Такая структура позволяет сначала понять, какой сегмент просел (аддитивный слой), а потом — из-за какого фактора внутри него (мультипликативный слой).

Как проверить, что дерево сходится по числам?

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

Для аддитивного узла:

Родитель_из_детей = сумма всех детей
Расхождение = (Родитель_прямой - Родитель_из_детей) / Родитель_прямой * 100%

Для мультипликативного узла:

Родитель_из_детей = произведение всех детей
Расхождение = (Родитель_прямой - Родитель_из_детей) / Родитель_прямой * 100%

Допустимое расхождение — доли процента (округления, микро-задержки в ETL). Если видите 5-15% — где-то ошибка. Частые причины:

Быстрый скрипт проверки сходимости аддитивного узла на Python:

import pandas as pd

# факт по каждому каналу и общий прямой замер
children = pd.Series({
    "organic": 4_120_000,
    "paid": 2_980_000,
    "email": 640_000,
    "referral": 310_000,
})
parent_direct = 8_050_000  # прямой SELECT SUM(revenue) без разбивки

parent_from_children = children.sum()
diff_pct = (parent_direct - parent_from_children) / parent_direct * 100

print(f"Сумма детей:   {parent_from_children:,}")
print(f"Прямой замер:  {parent_direct:,}")
print(f"Расхождение:   {diff_pct:.2f}%")

if abs(diff_pct) > 0.5:
    print("Дерево НЕ сходится — ищи потерянный сегмент или двойной учёт")

Здесь сумма детей — 8 050 000, прямой замер — 8 050 000, расхождение 0%. Если бы забыли канал referral, получили бы 7 740 000 и расхождение 3,85% — сразу видно, что ветка неполная. Отработать такую проверку на настоящих таблицах можно в Python-тренажёре.

Как построить дерево метрик для маркетплейса?

Соберём дерево целиком на примере маркетплейса, где вершина — GMV. Спускаемся сверху вниз, на каждом шаге выбирая тип декомпозиции.

Уровень 0 (корень):

GMV

Уровень 1 — аддитивно по стороне рынка нет смысла, зато мультипликативно:

GMV = Число заказов × Средний чек

Уровень 2 — раскладываем оба множителя:

Число заказов = Активные покупатели × Заказов на покупателя
Средний чек   = Позиций в заказе × Цена за позицию

Уровень 3 — раскладываем активных покупателей мультипликативно через воронку:

Активные покупатели = Аудитория × Конверсия визита в покупку

И параллельно даём аддитивный разрез по платформам поверх всего:

GMV = GMV_iOS + GMV_Android + GMV_Web

Листья-рычаги, до которых мы дошли, — это то, чем управляет команда:

Теперь ценность видна: если GMV просел, вы идёте по дереву и находите, что упала конверсия визита в покупку на Android — а не «всё плохо». Родственный разбор кейса с оборотом и take rate есть в статье про GMV и take rate маркетплейса. Тренировать декомпозицию на устных кейсах удобно через мок-интервью с AI — там как раз просят «разложи метрику вслух».

Как посчитать каждый узел дерева в SQL?

Дерево бесполезно, пока каждый узел не превращён в запрос. Хорошая практика — один CTE на узел, чтобы дерево в коде повторяло дерево на схеме. Возьмём аддитивно-мультипликативную структуру из примера выше.

Считаем базовые узлы одним проходом:

WITH base AS (
    SELECT
        platform,
        COUNT(DISTINCT session_id)                             AS visits,
        COUNT(DISTINCT CASE WHEN o.order_id IS NOT NULL
                            THEN o.buyer_id END)               AS active_buyers,
        COUNT(o.order_id)                                      AS orders,
        SUM(o.gmv)                                             AS gmv
    FROM sessions s
    LEFT JOIN orders o
        ON o.session_id = s.session_id
       AND o.status = 'paid'
    WHERE s.event_date >= DATE '2026-06-01'
      AND s.event_date <  DATE '2026-07-01'
    GROUP BY platform
)
SELECT
    platform,
    gmv,
    orders,
    active_buyers,
    visits,
    -- узлы-множители
    ROUND(gmv * 1.0 / NULLIF(orders, 0), 2)          AS avg_check,
    ROUND(orders * 1.0 / NULLIF(active_buyers, 0), 2) AS orders_per_buyer,
    ROUND(active_buyers * 100.0 / NULLIF(visits, 0), 2) AS cr_visit_to_buy_pct
FROM base
ORDER BY gmv DESC;

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

Теперь аддитивная проверка: сумма по платформам должна дать общий GMV.

WITH by_platform AS (
    SELECT platform, SUM(gmv) AS gmv
    FROM orders
    WHERE status = 'paid'
      AND order_date >= DATE '2026-06-01'
      AND order_date <  DATE '2026-07-01'
    GROUP BY platform
),
total AS (
    SELECT SUM(gmv) AS gmv_direct
    FROM orders
    WHERE status = 'paid'
      AND order_date >= DATE '2026-06-01'
      AND order_date <  DATE '2026-07-01'
)
SELECT
    (SELECT SUM(gmv) FROM by_platform) AS gmv_from_children,
    total.gmv_direct,
    ROUND(
        (total.gmv_direct - (SELECT SUM(gmv) FROM by_platform))
        * 100.0 / NULLIF(total.gmv_direct, 0), 4
    ) AS diff_pct
FROM total;

Если diff_pct не ноль — в разрезе по платформам потерялась строка (например, platform IS NULL). Такие запросы удобно отрабатывать в SQL-тренажёре на живых таблицах, а базу оконных функций и GROUP BY подтянуть в курсе по SQL с нуля. Если конверсии и агрегации пока даются тяжело, начните с разбора GROUP BY и HAVING и воронки в SQL.

Какие ошибки делают дерево метрик бесполезным?

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

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

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

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

Посчитай каждый узел дерева на реальных данных
Разбери формулы связи на практике: SQL-тренажёр и справочник метрик с формулами и примерами. Первые 5 задач бесплатно.
Открыть тренажёр метрик →

Похожие статьи