KPI tree: как построить дерево метрик продукта

Зачем нужно дерево метрик

Типичный продакт держит в голове 30 метрик и не понимает, как они связаны. На стендапе говорят «упал retention», и дальше идёт разговор «может, реклама, может, фича, может, сезонность». Если бы было дерево — было бы видно, какая ветка просела и куда копать.

KPI tree (или метрическое дерево) — иерархия метрик, где наверху ключевая бизнес-метрика, а внизу операционные, на которые команды влияют напрямую. Это не художественная схема, а рабочий инструмент дискавери и аналитики.

Главная польза не в красивой картинке, а в том, что вы заранее понимаете, какая метрика к какой ведёт. Когда что-то падает — есть карта, по которой искать причину.

Структура KPI tree

В дереве три уровня:

1. North Star Metric — главная метрика продукта. Одна на весь продукт. Отражает реальную ценность для пользователя и бизнеса.
2. Драйверы (input metrics) — 3–5 метрик, через которые North Star можно сдвинуть. Обычно через арифметическую формулу: «выручка = пользователи × ARPU».
3. Операционные метрики — то, на что команды влияют конкретными действиями. Конверсии воронки, скорость загрузки, доля повторных покупок.

Связи в дереве должны быть формульными, не «по ощущениям». Если связь нельзя записать в виде уравнения или сильной корреляции — её в дереве не должно быть.

Как раскладывать North Star

Самый частый способ — арифметическая декомпозиция. Берёте North Star и раскладываете на множители или слагаемые.

Выручка = Активные пользователи × Конверсия в платных × ARPU платящего

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

Активные пользователи = Новые + Возвращающиеся
Новые = Источники трафика × Конверсия в регистрацию
Возвращающиеся = Retention 7 × Retention 30 × ...

Останавливаетесь на уровне, где у каждой нижней метрики есть владелец из конкретной команды. Иначе дерево теряет операционный смысл.

Альтернативный способ — по AARRR-воронке: Acquisition → Activation → Retention → Revenue → Referral. Подходит для b2c-продуктов с массовой воронкой.

Пример для SaaS-продукта

Возьмём Telegram-приложение для подготовки к собесам. North Star — еженедельные активные пользователи (WAU), которые сделали 3+ тренировки.

WAU 3+ тренировок
├── Новые активированные
│   ├── Регистрации в неделю
│   │   ├── Трафик из канала А
│   │   ├── Трафик из канала Б
│   │   └── Conversion rate визит → регистрация
│   └── Activation rate (первые 3 тренировки за 7 дней)
│       ├── Доля прошедших онбординг
│       └── Доля сделавших 3 тренировки в первые 3 дня
└── Возвращающиеся
    ├── Retention 7 дня
    ├── Retention 30 дня
    └── Reactivation rate (вернулись после 14 дней)
        ├── Push-OPN (open rate уведомлений)
        └── Email-CTR

Это ориентир, не догма. Реальное дерево часто шире и держится на дашборде, чтобы команды видели, какая метрика просела.

Связь KPI tree и OKR

Дерево метрик — фундамент. OKR на квартал ставятся на конкретные ветки дерева:

• North Star — постоянное наблюдение.
• Раз в квартал команда выбирает 1–2 ветки, по которым ставит OKR.
• KR измеряется метриками с этой ветки.

Например: команда роста выбирает ветку «Activation rate». KR — «увеличить долю прошедших онбординг с 55% до 70% за квартал». Все спринтовые задачи внутри квартала привязываются к этой ветке.

Без дерева OKR превращаются в произвольные «делаем что-то». С деревом видно, какую часть продукта команда сейчас двигает.

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

• Слишком глубоко. 5–6 уровней дерева превращаются в «всё связано со всем», и пользоваться им невозможно. 2–3 уровня — норма.
• Связи без формул. Если «retention» висит под «выручкой» через стрелку и не уточнено, как одна влияет на другую — это не KPI tree, это карта на салфетке.
• Дерево не обновляется. Раз в полгода стоит пересматривать: какие метрики устарели, появились ли новые драйверы, изменилось ли пользовательское поведение.
• Несколько North Star. По определению она одна. Если у вас три — выберите одну, остальные станут драйверами.
• Дерево без owners. У каждой ветки нижнего уровня должна быть команда, которая её двигает. Иначе дерево декоративное.

Связанные темы

• OKR vs KPI: разница
• AARRR пиратские метрики
• HEART framework Google
• RFM-анализ для продакта

FAQ

Должно ли дерево быть формальным?

Желательно. Если связи между метриками не формульные, дерево превращается в обои. Минимум — стрелки с пометкой «через что влияет».

Сколько уровней должно быть в дереве?

Обычно 3 уровня хватает: North Star → драйверы → операционные. Глубже — рискуете утонуть.

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

Раз в 6–12 месяцев или после крупного изменения в продукте (новый сегмент, новая монетизация, выход на новый рынок).

Дерево метрик и юнит-экономика — одно и то же?

Нет. Юнит-экономика — частный случай: декомпозиция выручки и затрат на одного пользователя. KPI tree шире и охватывает не только финансовые метрики.

Кто строит KPI tree в команде?

Обычно продакт-аналитик совместно с продактом и финансами. Дерево должно быть согласовано на уровне руководства, иначе разные команды будут опираться на разные метрики.

Можно ли построить KPI tree на маленьком продукте?

Можно и нужно. Чем раньше зафиксированы North Star и драйверы — тем меньше потом конфликтов между командами и тем понятнее, на что тратить ресурс.

---

Тренируйте работу с метриками и фреймворками — откройте Карьерник с 1500+ вопросами для собесов на продакта и аналитика.