Иерархия метрик продукта: как связать UX-решения с бизнес-показателями
Основной чат
Чат для вайбкодеров: новости, гайды, поиск исполнителей, маркетплейс и разбор реальных кейсов.
Дизайнер переделал онбординг. Пользователи стали проходить его быстрее. Дизайнер доволен. Продакт смотрит на выручку — она не выросла. «Зачем вы вообще это делали?»
Это классический разрыв между UX-метриками и бизнес-метриками. Дизайнер оптимизировал одно, бизнес ожидал другого. Никто не виноват — просто не было общего языка.
Иерархия метрик — это и есть тот общий язык. Система, которая показывает: вот бизнес хочет X, вот X складывается из Y и Z, вот Y напрямую зависит от того, что делает дизайнер.
Зачем вообще нужна иерархия
Метрики без иерархии — это набор цифр. Каждый смотрит на своё: маркетинг на CAC, продакт на retention, дизайнер на task completion rate. Цифры не противоречат друг другу, но и не складываются в картину.
Иерархия отвечает на вопрос «почему эта метрика важна». Не просто «retention вырос на 3%» — а «retention вырос на 3%, значит через полгода выручка вырастет примерно на X, потому что вот эта связь».
Три вещи, которые даёт иерархия:
Приоритизация. Когда ясно, что на что влияет, легко решить, что делать сначала. Не по ощущениям, а по цепочке.
Обоснование решений. «Я хочу переделать форму регистрации» — слабо. «Форма регистрации — узкое место в воронке, которое режет conversion rate, а CR напрямую влияет на revenue» — сильно.
Обнаружение конфликтов. Иногда оптимизация одной метрики вредит другой. Иерархия помогает увидеть это заранее.
Три уровня метрик
Любой продукт можно описать через три уровня метрик. Называют их по-разному, но суть одна.
Уровень 1: Бизнес-метрики
Это то, что считает CFO и CEO. Деньги, рост, устойчивость бизнеса.
- Revenue / MRR / ARR — выручка, помесячная и годовая
- Profit margin — маржинальность
- LTV (Lifetime Value) — сколько денег приносит один пользователь за всё время
- CAC (Customer Acquisition Cost) — сколько стоит привлечь одного пользователя
- LTV/CAC ratio — основной показатель здоровья бизнеса (нормой считается 3:1 и выше)
- Churn rate — процент пользователей, которые уходят за период
На этом уровне дизайнер обычно не работает напрямую. Но именно здесь нужно понимать, что считается успехом.
Уровень 2: Продуктовые метрики
Это то, что измеряет продуктовая команда. Показатели поведения пользователей в продукте.
- DAU / MAU — ежедневные и ежемесячные активные пользователи
- Retention Rate — какой процент пользователей возвращается (D1, D7, D30)
- Activation Rate — дошли ли пользователи до момента ценности
- Engagement — глубина использования продукта
- NPS (Net Promoter Score) — готовность рекомендовать
- Feature adoption — используют ли конкретные фичи
Здесь дизайнер уже влияет напрямую — через UX, информационную архитектуру, онбординг.
Уровень 3: UX-метрики
Это то, что измеряет дизайнер. Показатели качества конкретного взаимодействия.
- Task success rate — процент пользователей, успешно выполнивших задачу
- Time on task — сколько времени уходит на выполнение
- Error rate — как часто пользователи ошибаются
- SUS (System Usability Scale) — субъективная оценка удобства
- HEART-метрики — Happiness, Engagement, Adoption, Retention, Task Success
- Conversion rate в воронке — процент перехода между шагами
Это метрики конкретных экранов, флоу, компонентов.
Как связать уровни: дерево метрик
Иерархия работает как дерево. Верхний уровень — бизнес-метрика. Она декомпозируется в продуктовые метрики. Те декомпозируются в UX-метрики.
Вот пример для SaaS-продукта:
Revenue
├── Новые платящие пользователи
│ ├── Трафик на сайт
│ ├── Conversion rate (landing → регистрация)
│ │ ├── Task completion rate на форме регистрации
│ │ └── Error rate на шагах формы
│ └── Activation rate (регистрация → первое ценное действие)
│ ├── Time to value (как быстро пользователь дошёл до ценности)
│ └── Onboarding completion rate
└── Удержание существующих пользователей
├── D30 Retention
│ ├── DAU/MAU ratio
│ └── Feature adoption rate ключевых фич
└── Expansion revenue (апгрейды)
├── Использование premium-фич
└── Частота использования
Это не единственный возможный вид дерева — он будет разным для разных продуктов и бизнес-моделей. Но принцип один: каждая верхнеуровневая метрика объясняется через нижнеуровневые.
Как читать дерево
Сверху вниз: «Что влияет на revenue? → Новые пользователи и retention. Что влияет на Conversion rate? → Task completion на форме регистрации и error rate».
Снизу вверх: «Мы улучшили error rate на форме регистрации. Что это значит для бизнеса? → Выше conversion rate → больше новых платящих → выше revenue».
Второй путь — это то, как дизайнер обосновывает свою работу бизнесу.
Практика: как строить дерево для своего продукта
Шаг 1: Зафиксируй главную бизнес-метрику
Это North Star Metric или просто главный KPI, который важен бизнесу прямо сейчас. Не три метрики и не «ну, нам важно всё» — одна.
Примеры: Monthly Recurring Revenue, количество активных пользователей, объём транзакций.
Шаг 2: Разложи её на компоненты
Любую метрику можно математически разложить. Revenue = Количество пользователей × ARPU. DAU = Новые пользователи + Вернувшиеся − Ушедшие. Retention = 1 − Churn.
Это не гипотезы — это математические тождества. Используй их как каркас.
Шаг 3: Для каждого компонента найди продуктовый драйвер
«Что в продукте влияет на этот компонент?» Retention обычно зависит от engagement с ключевыми фичами, от качества онбординга, от того насколько быстро пользователь достигает ценности.
Шаг 4: Для каждого продуктового драйвера найди UX-метрику
«Как это измерить в интерфейсе?» Engagement с фичей → feature adoption rate, time spent in feature. Качество онбординга → onboarding completion rate, time to completion, drop-off points.
Шаг 5: Проверь связи
Связь между уровнями должна быть логически обоснована. «Если task completion rate на онбординге вырастет, activation rate тоже должен вырасти» — это гипотеза, которую можно проверить.
Распространённые ошибки при построении иерархии
Ошибка 1: Слишком много метрик на каждом уровне
Если на уровне UX-метрик у вас 40 показателей — это не иерархия, это таблица данных. На каждом уровне должно быть 3–7 ключевых метрик.
Ошибка 2: Связи «по ощущениям»
«Мы думаем, что это влияет на то» — не годится. Связи должны быть либо математически выведены, либо подтверждены данными. Гипотезы нужно явно помечать как гипотезы.
Ошибка 3: Статичное дерево
Продукт меняется, фокус бизнеса меняется — и дерево метрик должно меняться. Ревизия раз в квартал — минимум.
Ошибка 4: Ориентация на то, что легко измерить
Клики, просмотры, время на сайте — это легко посчитать. Но они часто не коррелируют с тем, что важно бизнесу. Строй иерархию от бизнес-цели вниз, а не от данных вверх.
Ошибка 5: Путаница метрик и целей
Метрика — это измерение. Цель — это желаемое значение метрики. «Retention» — метрика. «Retention D30 ≥ 40%» — цель. Не перепутай их в дереве.
Дизайнер и метрики: три модели взаимодействия
В разных командах дизайнер работает с метриками по-разному.
Модель 1: Дизайнер получает метрики сверху
Продакт ставит задачу с метрикой: «Нужно поднять conversion rate на онбординге с 60% до 75%». Дизайнер решает задачу.
Плюсы: чёткая задача, понятен критерий успеха. Минусы: дизайнер не понимает контекст, может оптимизировать не то.
Модель 2: Дизайнер участвует в выборе метрик
Команда вместе решает, что считать успехом для конкретного проекта. Дизайнер предлагает UX-метрики, которые связаны с продуктовыми целями.
Плюсы: дизайнер понимает задачу целиком, метрики осмысленные. Минусы: требует зрелости команды и доверия.
Модель 3: Дизайнер самостоятельно строит и предлагает метрики
Дизайнер приходит к продакту с готовой цепочкой: «Я предлагаю изменить форму, это должно поднять task completion rate, что связано с activation rate, который напрямую влияет на revenue».
Плюсы: максимальное влияние и ответственность. Минусы: нужно глубокое понимание бизнеса и данных.
Третья модель — это уровень senior/lead дизайнера. Именно для неё нужна иерархия метрик.
Как разные типы продуктов строят иерархию
E-commerce
GMV (Gross Merchandise Value)
├── Количество заказов
│ ├── Conversion rate (сессия → заказ)
│ │ ├── Add to cart rate
│ │ ├── Cart abandonment rate
│ │ └── Checkout completion rate
│ └── Повторные заказы
│ └── Retention rate покупателей
└── Средний чек
├── Средний размер корзины
└── Upsell/cross-sell rate
Дизайнер здесь работает прежде всего с воронкой — от карточки товара до подтверждения заказа. Ключевые метрики: add to cart rate, checkout completion rate, cart abandonment rate по шагам.
SaaS (подписка)
MRR (Monthly Recurring Revenue)
├── Новые подписки
│ ├── Trial-to-paid conversion
│ │ ├── Activation rate (trial → aha moment)
│ │ └── Engagement во время trial
│ └── Количество trial-регистраций
└── Удержание подписок
├── Churn rate
│ ├── Feature adoption (используют ли ключевые фичи)
│ └── Engagement trend (растёт или падает)
└── Expansion revenue (апгрейды)
Ключевая задача дизайна в SaaS — ускорить путь пользователя к «aha moment» и обеспечить постоянный engagement с фичами, за которые он платит.
Маркетплейс (двусторонний)
Маркетплейс сложнее — здесь две стороны и метрики нужны для каждой.
GMV
├── Сторона спроса (покупатели/заказчики)
│ ├── Conversion rate (поиск → заказ)
│ ├── Retention покупателей
│ └── Средний чек
└── Сторона предложения (продавцы/исполнители)
├── Supply quality (рейтинги, отзывы)
├── Retention поставщиков
└── Time to fill (скорость закрытия заказа)
Дизайнер маркетплейса работает с двумя разными пользователями с разными задачами и часто с разными интерфейсами.
Когда метрики лгут: ловушки для дизайнера
Иерархия метрик помогает не только видеть связи, но и замечать, когда данные вводят в заблуждение.
Ловушка «хорошая метрика, плохой продукт»
Task completion rate 95% на форме — отлично. Но пользователи заполняли её по 12 минут и ненавидели каждую секунду. SUS-оценка 42/100.
Метрики не противоречат, но картина разная. Нужно смотреть на несколько связанных метрик вместе.
Ловушка «корреляция вместо каузальности»
Внедрили новый дашборд — retention вырос. Кажется, связь есть. Но одновременно запустили email-кампанию и улучшили мобильное приложение. Что именно повлияло?
Без контролируемых экспериментов (A/B-тестов) невозможно установить причинно-следственную связь. Корреляция — это гипотеза, не факт.
Ловушка «ванильных метрик»
Некоторые метрики выглядят хорошо по определению. «Нас лайкнули 10 000 раз» — и что? Количество лайков само по себе не объясняет, помогает ли продукт пользователям достигать целей.
Ванильные метрики — те, которые сложно связать с бизнес-результатом. В иерархию они не попадают.
Ловушка «оптимизации локального оптимума»
Улучшили форму регистрации — conversion rate вырос с 40% до 55%. Победа? Нет, если activation rate упал с 70% до 50%, потому что в продукт пошли нецелевые пользователи.
Оптимизация отдельной метрики без понимания системы может ухудшить итоговый результат.
Метрики и дизайн-решения: как строить аргументацию
Когда дизайнер приходит с предложением к продакту или бизнесу, структура аргумента должна идти по иерархии метрик.
Слабый аргумент: «Я хочу переделать страницу оплаты, потому что она выглядит устаревшей».
Сильный аргумент: «На шаге оплаты у нас 38% drop-off. Это снижает checkout completion rate до 62%, что режет конверсию всей воронки. По нашим расчётам, поднятие checkout completion до 75% даст +18% к количеству заказов в месяц. Я предлагаю переработать шаг оплаты, начиная с упрощения формы и добавления индикатора безопасности».
Разница — в том, что второй аргумент идёт по дереву метрик сверху вниз. Бизнес-эффект понятен, предложение конкретно.
Как начать прямо сейчас
Если у вас ещё нет иерархии метрик, начать можно за один рабочий день.
Утро: Соберите данные. Возьмите любой аналитический дашборд и выпишите все метрики, которые там есть. Не оценивайте — просто соберите.
Обед: Поговорите с продактом или CEO. Один вопрос: «Какая метрика для нас сейчас самая важная?» Это ваш верхний уровень.
После обеда: Постройте первый черновик дерева. Не идеальный — просто разложите: что влияет на главную метрику, что влияет на это.
Вечер: Пройдитесь по дереву вместе с командой. Где связи неочевидны — поставьте вопрос. Где чего-то не хватает — добавьте.
Черновое дерево лучше отсутствия дерева. Его можно уточнять по мере работы.
Чеклист: иерархия метрик готова, если…
- Есть одна ключевая бизнес-метрика сверху
- Каждый уровень имеет не больше 5–7 метрик
- Связи между уровнями объяснены (математически или через данные)
- Для каждой UX-метрики понятно, как её измерить
- Дизайнер может объяснить любое своё решение через цепочку метрик
- Дерево обновляется раз в квартал или при смене фокуса бизнеса
- Гипотезы о связях явно помечены как гипотезы
- Команда согласована по иерархии (не только дизайнер её знает)
Что дальше
Иерархия метрик — это фундамент. На нём строится всё остальное: выбор North Star Metric, построение дашборда, A/B-тесты, аргументация дизайн-решений.
Следующий шаг — научиться выбирать одну главную метрику из всего дерева и не терять из виду остальные. Это тема North Star Metric — о ней отдельная статья в этой серии.
Как метрики меняются при масштабировании продукта
Иерархия метрик не постоянна. По мере роста продукта и бизнеса фокус смещается — и дерево метрик должно меняться вместе с ним.
Стадия: Product-market fit (0→1)
На этой стадии главный вопрос — работает ли продукт вообще? Создаёт ли он ценность для пользователей?
Ключевые метрики стадии:
- Retention первых пользователей (есть ли хоть кто-то, кто возвращается?)
- NPS (рекомендуют ли они продукт?)
- Качественная обратная связь
На этой стадии Revenue — плохая главная метрика. Даже с плохим UX можно продать первым клиентам на энтузиазме. Это не доказывает, что продукт работает.
UX-метрики на этой стадии: Task success rate на ключевых сценариях и время до первого ценного результата.
Стадия: Growth (1→N)
Продукт работает, нужно масштабировать.
Фокус смещается на:
- Acquisition efficiency (CAC, conversion funnel)
- Retention at scale (удерживаем ли мы разнородную аудиторию?)
- Activation (успевают ли новые пользователи увидеть ценность?)
UX-метрики фокусируются на воронке привлечения и онбординге — там самые большие потери при масштабировании.
Стадия: Maturity
Продукт зрелый, рост замедляется.
Фокус на:
- Expansion revenue (больше от существующих пользователей)
- Efficiency (снижение CAC, снижение стоимости обслуживания)
- Defense (удержание перед конкурентами)
UX-метрики смещаются в сторону engagement и depth-of-use: используют ли пользователи весь потенциал продукта, а не только базовые функции.
Метрики и приоритизация дизайн-задач
Иерархия метрик — это не только теория. Это рабочий инструмент для принятия решений о том что делать.
Как использовать иерархию для приоритизации бэклога
У тебя есть 15 задач в бэклоге. Как выбрать с чего начать?
Шаг 1. Для каждой задачи определи: какую метрику она должна улучшить?
Шаг 2. Найди эту метрику в дереве. На каком уровне она находится?
Шаг 3. Каков потенциал улучшения? Если эта метрика вырастет на 10% — что происходит выше по дереву?
Шаг 4. Оцени усилие. Большое влияние + маленькое усилие = начинай отсюда.
Пример приоритизации
Бэклог задач:
- A: Переделать главную страницу (влияет на: first impression, нет чёткой метрики)
- B: Упростить форму заявки (влияет на: conversion rate → revenue)
- C: Добавить тёмную тему (влияет на: satisfaction, косвенно retention)
- D: Исправить ошибки в мобильной форме оплаты (влияет на: checkout completion → revenue)
- E: Улучшить онбординг шаг 3 (влияет на: activation rate → retention → revenue)
Приоритизация через иерархию метрик:
- D (критическая ошибка в оплате, прямое влияние на revenue)
- B (конверсия напрямую в revenue)
- E (activation rate → retention → долгосрочный revenue)
- C (retention через satisfaction, косвенное влияние)
- A (влияние неизмеримо без конкретной метрики)
Это не идеальный алгоритм — но это намного лучше приоритизации «по ощущениям».
Как рассказывать о метриках разным аудиториям
Дизайнер работает с разными людьми: CEO, продактом, разработчиком, другими дизайнерами. Для каждого — свой язык.
Для CEO
Говори в терминах денег и рисков. Не «retention вырос», а «retention вырос на 3%, это транслируется в +Х рублей выручки через 6 месяцев по нашим расчётам».
CEO думает: «Это важно? Сколько стоит? Когда окупится?»
Для продакта
Говори о продуктовых метриках и гипотезах. «Activation rate 38%, это ниже бенчмарка в 55%. Предполагаем что причина в шаге 3 онбординга — там 42% drop-off. Предлагаем тест нового флоу».
Продакт думает: «Что делаем, почему именно это, как измеряем результат?»
Для разработчика
Говори о конкретных задачах и их приоритете. «Error rate на форме оплаты — 12%, это критично. Пользователи не могут ввести CVV на мобайле. Это блокирует конверсию».
Разработчик думает: «Что конкретно нужно исправить и насколько это срочно?»
Для других дизайнеров
Говори о дизайн-решениях и их обосновании. «Мы убрали поле "Телефон" из формы. Task completion rate вырос с 67% до 84%. Конкретная проблема была в том что пользователи не понимали зачем телефон нужен при онлайн-регистрации».
Другой дизайнер думает: «Почему именно это решение, какие были альтернативы, что из этого можно применить у меня?»
ИИ и иерархия метрик: как Claude помогает построить дерево
Построить дерево метрик с нуля — задача на несколько часов: нужно понять бизнес-модель, выписать метрики, найти связи. ИИ сокращает это до 20–30 минут.
Вот как это работает на практике.
Промпт: построить первое дерево метрик
Я продуктовый дизайнер в [тип продукта: SaaS / e-commerce / маркетплейс / мобильное приложение].
Наша бизнес-модель: [например, подписка $29/мес, freemium с конверсией в платный план]
Главная бизнес-метрика: [например, MRR или количество активных подписчиков]
Построй дерево метрик: разложи главную метрику на продуктовые компоненты, а продуктовые — на UX-метрики, которые дизайнер может измерить и улучшить.
Покажи дерево в виде структуры с отступами. Для каждой UX-метрики укажи: как именно её измерить (инструмент или способ).
Claude вернёт дерево под вашу конкретную бизнес-модель — не абстрактный шаблон.
Промпт: найти слабые места в текущем дереве
Вот наше текущее дерево метрик:
[вставь дерево]
Найди в нём:
1. Метрики без чёткой связи с бизнес-результатом
2. Уровни с пробелами (что-то важное не измеряется)
3. Метрики, которые легко «нагеймингуются» (хорошо растут без реального улучшения продукта)
Предложи конкретные исправления.
Промпт: перевести дизайн-задачу на язык метрик
Часто дизайнер знает, что хочет сделать, но не знает, как обосновать бизнесу.
Я хочу переделать [конкретный экран или флоу].
Помоги мне выстроить аргументацию через метрики:
1. Какую UX-метрику это должно улучшить?
2. Как эта UX-метрика связана с продуктовыми KPI?
3. Как продуктовые KPI связаны с бизнес-метриками?
4. Предложи формулировку для разговора с CEO или CPO.
Контекст продукта: [кратко опиши]
Как использовать ИИ для регулярной ревизии дерева
Раз в квартал задай Claude:
У нас изменился фокус: [например, раньше были в стадии роста, теперь переходим к монетизации / запускаем B2B-продажи / выходим на новый рынок].
Вот текущее дерево метрик:
[вставь дерево]
Какие метрики нужно добавить, убрать или поменять в приоритете под новый фокус? Объясни логику каждого изменения.
Это занимает 10 минут вместо воркшопа на полдня.