Дерево KPI (KPI Tree Template)

NRR → retention + expansion − contraction. Expansion → adoption × eligible accounts × conversion to upsell. Тогда маркетинг и CS видят не один итоговый процент, а конкретные рычаги.

• Между уровнями есть объяснимая causal logic.
• Нет vanity metrics, не влияющих на outcome.
• Формулы зафиксированы.
• Guardrails не дают оптимизировать одну метрику ценой бизнеса.

Шаблон особенно полезен, если одной метрикой пользуются несколько команд, данные собираются из разных систем или расчёт влияет на бюджет и решения. Для одноразового анализа допустима облегчённая версия, но definition и источник данных всё равно должны быть указаны. Чем дольше живёт показатель, тем важнее governance и change log.

• Начните с решения и бизнес-вопроса, а не с доступных таблиц. Это определит, какие метрики и уровень детализации действительно нужны.
• Зафиксируйте definitions, grain, time window и source of truth до построения расчётов. Одинаковое название не гарантирует одинаковую метрику.
• Проверьте качество данных: полноту, дубли, пропуски, изменения tracking и структурные разрывы во времени.
• Для прогнозов и моделей явно храните assumptions, диапазоны и сценарии. Не маскируйте неопределённость одной точной цифрой.
• Назначьте owner и cadence пересмотра. Аналитический артефакт без ответственного и правил обновления быстро перестаёт быть источником истины.

Команда раскладывает NRR на retention, expansion и contraction, а дальше — на adoption и eligible accounts. Так итоговая метрика превращается в управляемые drivers.

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

• У каждой метрики есть точная definition.
• Источник данных и grain указаны.
• Метод позволяет ответить именно на поставленный вопрос.
• Неопределённость, лаги и limitations не скрыты.
• Есть owner и правило обновления.

Пересматривайте определения при изменении tracking, CRM, data model, business logic или accounting rules. Любое изменение формулы должно иметь change log, дату вступления в силу и оценку влияния на исторические сравнения.

Нужно ли хранить все метрики в одном документе?

Нет. Канонический dictionary и measurement plan должны быть связаны, но operational dashboards могут показывать только релевантный subset.

Что делать, если источники дают разные цифры?

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

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

По cadence бизнеса и при изменении данных. Forecast и campaign metrics могут обновляться часто, definitions и governance — реже, но обязательно после системных изменений.

• Measurement Plan
• Metric Dictionary
• Dashboard Specification

• North Star Framework
• AARRR

• KPI Tree
• Leading & Lagging Metrics
• Guardrail Metrics