Ієрархія показників

Ієрархія показників

Ієрархія показників пов'язує стратегічну мету компанії зі щоденними рішеннями команд. Це кероване «дерево» від North Star Metric (NSM) і бізнес-підсумків до драйверів, операційних KPI і guardrails (обмежень безпеки). Нижче - як спроектувати, задокументувати і експлуатувати таку ієрархію.

1) Навіщо потрібна ієрархія

Єдиний фокус: всі команди тягнуть в одну сторону, конфлікти метрик мінімальні.
Прозора причинність: зрозуміло, чому NSM рухається (дерево драйверів).
Швидкість рішень: локальні метрики безпосередньо пов'язані з бізнес-ефектом.
Стійкість: guardrails запобігають «побічні ефекти» оптимізації.

2) Шари і терміни

North Star Metric (NSM): головна метрика цінності (наприклад, «Місячні активні платять користувачі»).
Бізнес-підсумки: виручка, маржа, GGR, частка ринку, NPS - асоційовані, але не завжди NSM.
Дерево драйверів: розкладання NSM на фактори: обсяг × конверсія × частота × середній чек і т.д.
Командні KPI: показники, якими реально управляє команда (воронки, latency, PR-AUC тощо).
Guardrails: обмеження: FPR≤x%, p95 latency≤y, частка zhalob≤z - «гальма» при зростанні.
Процесні метрики: швидкість релізів, якість даних, SLO оновлень - підтримують систему.

3) Як вибрати North Star

Критерії: відображає цінність для користувача, корелює з довгостроковим доходом, чутлива до змін продукту, зрозуміла і стійка до маніпуляцій.

• Продукт B2C: 'WAU платять'або'Сесії з успішним цільовою дією/місяць'.
• Маркетплейс: «Завершені успішні угоди/місяць».
• ML-платформа: «Частка запитів, обслужених моделлю з SLA ≤ X мс і калібруванням в допуску».

4) Побудова дерева драйверів (Driver Tree)

1. Визначте формулу NSM.
2. Розкладіть на мультиплікативні/адитивні фактори.
3. Додайте шар керованих важелів.
4. Прив'яжіть листові метрики до команд.
5. Для кожного вузла - власник і цільові рівні.

NSM: Активные платящие (MAPU)
= Активные пользователи × Доля платящих × Средняя частота платежей × Средний чек
├─ Активные пользователи = Трафик × Активация × Удержание
│  ├─ Трафик = Органический + Платный (CR кампаний, CAC)
│  ├─ Активация = Конверсия онбординга (шаги воронки)
│  └─ Удержание = D7/D30, когорты
├─ Доля платящих = Propensity-модели + Офферы (guardrail: RG/фрод)
├─ Частота = Миссии/квесты, контент-ротация
└─ Средний чек = Прайсинг, бандлы (guardrail: жалобы/возвраты)

5) Каскадування цілей (OKR/KPI)

Корпоративний рівень: NSM + 3-5 драйверів (рік/квартал).
Функції/продукти: піддерева драйверів (цільові Δ).
Команди: KPI на листах дерева; цілепокладання у форматі OKR (Commit/Stretch).
Індивідуально: задачні метрики (через внесок у командний KPI).

• На один рівень - ≤7 метрик (перевантаження вбиває фокус).
• Всі цілі - прив'язані до унікального вузла дерева (без дублювання).
• Для конфліктуючих пар - явний пріоритет і/або компроміс через guardrails.

6) Guardrails: як задати «бортики»

• Якість/досвід: p95 latency, crash-free%, відмовостійкість.
• Етика/комплаєнс: FPR антифрода, частка скарг, RG-індикатори.
• Дані: Freshness, Completeness, PSI дрейфу.
• Фінанси: маржинальність ≥ X, chargeback rate ≤ Y.

Guardrails - обов'язковий рядок в кожному OKR/паспорті метрики; спрацьовування блокує rollout.

7) Формули, джерела та семантичний шар

Всі метрики дерева визначаються в семантичному шарі (єдині визначення, ролапи, календар, валюти/таймзони).
Версіонування: `METRIC_NAME_vN`; будь-яка правка формули = нова версія + backfill/звірка.
Паспорт метрики (коротко): код, визначення, формула/SQL, джерела, гранулярність, сегменти за замовчуванням, одиниці/валюта, SLO свіжості і доступності, власники, guardrails, історія змін.

8) Частоти вимірювання та SLO

Операційні метрики: хв/год (SLO лаг ≤ 10-15 хв).
Продукт/маркетинг: день/тиждень (обов'язковий УоУ/сезонна нормалізація).
Фінансові: тиждень/місяць (звірки з бухгалтерією).
ML-метрики продакшену: потоково + відкладені офлайн-оцінки (OOT).

У кожної метрики на дашборді показуйте: «оновлено X хв назад» і плановий SLO.

9) Дашборди та огляди

Executive шар: NSM + ключові драйвери, alert-віджети guardrails.
Domain шар: воронки, когорти, внесок факторів (водоспади/декомпозиції).
Ops/ML шар: SLA, помилки, дрейф, калібрування, latency p95/p99.
Ритуали: daily (операційка), weekly (тактика), monthly/QBR (стратегія/OKR).
На оглядах використовуйте дерево: показуйте вузол, відхилення, гіпотези, план.

10) Прив'язка до відповідальності (RACI)

• Responsible: команда-власник KPI.
• Accountable: лідер домену/продукту.
• Consulted: аналітика/дані/комплаєнс.
• Informed: суміжні команди/топ-менеджмент.

Конфлікти показників вирішуються на рівні загального дерева за участю Accountable.

11) Приклади «міні-дерев» по доменах

• 'Залучені якісні користувачі = Трафік × Частка кваліфікованих лідів × CR в реєстрацію × Брендова частка'
• Guardrails: SAS≤targeta, Brand Safety, spam rate.

• 'WAU = DAU × Частота × Stickiness'
• Guardrails: crash-free ≥ 99. 5%, скарги ≤ порогу.

• 'Виручка = Активні платять × Частота платежів × Середній чек'
• Guardrails: refund%, chargeback rate, RG-індикатори.

• 'Бізнес-ефект = Перекриті втрати − Вартість помилкових блокувань'
• Основні KPI: PR-AUC, Recall@FPR≤x%, Coverage; Guardrails: latency p95, частка апеляцій.

12) Анти-патерни

Неузгоджені визначення: «Retention» вважається по-різному - лікується семантичним шаром і версіями.
Оптимізація проксі: зростання кліків без зростання NSM - захищайте через NSM і guardrails.
Занадто багато метрик: «панель літака» - залиште ≤7 на рівень.
Немає власника: метрика «нічия» швидко деградує.
Тихі правки формул: завжди - нова версія + changelog.

13) Шаблони артефактів

A. Паспорт вузла дерева

Вузол: `RETENTION_D30`

Роль у дереві: драйвер NSM

Формула (семантичний об'єкт): посилання/код

Сегменти: країна/канал/платформа

Власник: Product Analytics

Цілі (квартал): Commit/Stretch

Guardrails: churn скарг ≤ X, data freshness ≤ 1 год

Ризики/припущення: сезонність, мікс трафіку

Дата/версія: 2025-Q4, v2

B. карта каскаду цілей (приклад)

NSM (компанія): MAPU +8% YoY

Продукт: Retention D30 + 2 п.п.

Команда Онбординг: Активована реєстрація + 5 п.п.

Маркетинг: Якісні ліди + 12% при CAC ≤ таргету

Монетизація: ARPPU + 6% при refund% ≤ порогу

C. runbook відхилень

Подія: просадка DAU −10% DoD

Дії: перевірка свіжості даних → інциденти релізів → канали трафіку → регіони/платформи → RCA і план

14) Чек-лист впровадження ієрархії

• Визначена NSM і її зв'язок з цінністю/виручкою
• Побудовано і задокументовано дерево драйверів (власники, формули, джерела)
• Для кожного вузла - цілі, guardrails, частота оновлення і SLO
• Метрики заведені в семантичному шарі, версії і словник термінів узгоджені
• Налаштовані дашборди по шарах і ритуали огляду (daily/weekly/monthly/QBR)
• RACI закріплений; конфлікти KPI і пріоритети описані
• Runbooks на типові відхилення; алерти на NSM/guardrails
• План ревізії дерева раз на квартал; видалення застарілих вузлів

Підсумок

Ієрархія показників - це NSM → дерево драйверів → командні KPI → guardrails, закріплені в семантичному шарі і підключені до ритмів управління. Така конструкція робить цілі прозорими, відповідальність - явною, а зміни - вимірними і контрольованими.