Дашборд продуктового дизайнера: какие метрики мониторить и как их читать

Большинство дизайнеров смотрят на аналитику раз в месяц — когда продакт присылает отчёт или когда что-то явно сломалось. Это реактивный подход: узнаёшь о проблеме тогда, когда она уже нанесла ущерб.

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

Но дашборд работает только тогда, когда на него смотрят. А смотрят только на тот, который показывает нужные метрики в понятном виде. Это и есть задача этой статьи — разобраться, что именно должно быть на дашборде продуктового дизайнера.

## Зачем дизайнеру свой дашборд

Продакт-менеджер смотрит на продуктовые метрики. Маркетолог — на трафик и CAC. Аналитик — на всё сразу. У дизайнера — свой угол зрения.

Дизайнер отвечает за качество взаимодействия. Значит, дашборд должен показывать:

• Насколько легко пользователи выполняют ключевые задачи
• Где в интерфейсе есть проблемы
• Как изменения в дизайне влияют на поведение

Это не то же самое, что общий продуктовый дашборд. Там — retention, revenue, DAU. Здесь — task completion, error rate, flow completion, time on task.

## Структура дашборда: три уровня

Хороший дашборд читается за 5 минут. Это значит, что информация должна быть структурирована по приоритету.

### Уровень 1: Сигналы тревоги (смотреть ежедневно)

Метрики, которые при отклонении требуют немедленного реагирования. Если они в норме — смотришь дальше. Если нет — разбираешься прямо сейчас.

• Error rate по ключевым флоу — резкий рост означает поломку
• Crash rate / Page errors — технические проблемы, но они прямо влияют на UX
• Drop-off rate на ключевых шагах воронки — если кто-то резко вырос, что-то не так

Эти метрики лучше показывать как time series с аномалий-детектором или хотя бы с порогами — зелёный/жёлтый/красный.

### Уровень 2: Трекинг здоровья (смотреть еженедельно)

Метрики, которые меняются медленно, но определяют качество продукта в долгосрочной перспективе.

• Retention (D1, D7, D30)
• Activation rate (onboarding completion, time to first key action)
• Feature adoption rate по ключевым фичам
• NPS или CSAT (если собирается регулярно)
• Session length и session frequency

Здесь важна динамика, не только абсолютное значение. «D30 retention = 35%» само по себе не говорит ничего. «D30 retention вырос с 28% до 35% за квартал» — говорит много.

### Уровень 3: Глубокие метрики (смотреть при итерациях)

Метрики, которые нужны при конкретных исследованиях или оценке изменений.

• Task completion rate по конкретным задачам
• Time on task по конкретным флоу
• Heatmaps и scroll depth по конкретным экранам
• A/B test results по текущим экспериментам
• SUS-оценка из юзабилити-тестов

Эти метрики не нужны ежедневно — но когда нужны, должны быть доступны быстро.

## Метрики в деталях: что именно смотреть

### Task completion rate

Что это: процент пользователей, успешно завершивших конкретную задачу.

Как считать: количество пользователей, достигших конечного состояния флоу / количество пользователей, начавших флоу × 100%.

Что считать нормой: зависит от сложности задачи. Для простых задач (добавить в корзину, создать документ) — 85%+. Для сложных (заполнить длинную форму, настроить интеграцию) — 60–75% уже хорошо.

Как читать: смотри не только на итоговый показатель, но и на drop-off по шагам. Где именно уходят 20–30% пользователей — это и есть точка для улучшения.

Красные флаги:

• Резкое падение после релиза изменений
• Стабильно низкий показатель на одном конкретном шаге
• Разница в completion rate между устройствами (мобайл vs десктоп)

### Funnel conversion rate

Что это: процент пользователей, переходящих между шагами воронки.

Важно считать воронку пошагово, а не только от начала до конца. «70% пользователей прошли онбординг» — полезная информация. «На шаге 3 из 7 уходят 45% пользователей» — информация, с которой можно работать.

Формат отображения: ступенчатая воронка с абсолютными числами и процентами на каждом шаге. Показывай и конверсию «к предыдущему шагу», и «к первому шагу» — это разные данные.

Как анализировать:

• Где самый большой drop — там и самая большая возможность
• Сравни мобайл и десктоп — часто проблема только на одной платформе
• Сравни новых и вернувшихся пользователей — разные паттерны часто означают разные проблемы

### Error rate и типы ошибок

Что это: как часто пользователи сталкиваются с ошибками (форм, действий, системными).

Ошибки бывают разные:

• Validation errors — пользователь заполнил поле неправильно
• System errors — что-то пошло не так на стороне системы
• User errors — пользователь сделал не то действие (нажал не ту кнопку, удалил не то)

Почему важен error rate: каждая ошибка — это фрикция. Часть пользователей после ошибки уходит. Особенно критично в платёжных флоу и при регистрации.

Что мониторить:

• Error rate на форме регистрации (особенно на полях с особыми требованиями — пароль, телефон)
• Error rate в checkout
• Частота «отмены» или «назад» сразу после важного действия (косвенный сигнал ошибки)

### Time on task

Что это: сколько времени пользователь тратит на выполнение конкретной задачи.

Маленькое значение не всегда хорошо. Слишком маленькое может означать, что пользователь не завершил задачу, а бросил её.

Как интерпретировать:

• Определи целевое время для задачи (например, «создать проект должно занимать < 3 минут»)
• Измеряй отклонения в обе стороны
• Очень высокое время — пользователь застрял или запутался
• Очень низкое время на задаче, которая должна требовать обдумывания — возможно, пользователь не вникает

Где брать данные: если нет специальных инструментов — можно считать через timestamp событий (начало флоу → конец флоу) в аналитике.

### Feature adoption rate

Что это: какой процент активных пользователей использует конкретную функцию хотя бы раз за период.

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

Как анализировать:

• Feature с adoption < 10% — либо нишевая (и это ок), либо есть проблема
• Смотри на adoption в первые 7 дней после регистрации — key features должны быть открыты быстро
• Сравни adoption между сегментами пользователей (новые vs. опытные, тариф A vs. тариф B)

### Heatmaps и scroll depth

Что это: визуализация где кликают, куда движется мышь, как далеко скроллят.

Heatmaps полезны для:

• Понять, видят ли пользователи CTA (если кликают рядом, но не на кнопку — проблема с таргетингом нажатий)
• Найти неожиданные паттерны (кликают на некликабельный элемент — возможно, он выглядит как кнопка)
• Проверить, дочитывают ли лендинг до ключевого предложения

Scroll depth: важен для лендингов и длинных страниц. Если 80% пользователей уходят до ключевого CTA — либо нужно переставить CTA выше, либо улучшить первые экраны.

Инструменты: Hotjar, Microsoft Clarity (бесплатный), FullStory. Для мобайла — отдельные SDK.

## Как собрать дашборд: практика

### Инструменты

Нет единственного правильного инструмента. Выбирай по тому, что уже есть в команде:

• Amplitude / Mixpanel — полноценная продуктовая аналитика, cohort analysis, funnel analysis
• Google Analytics 4 — базовая аналитика поведения, хорош для веба
• Hotjar / Microsoft Clarity — heatmaps, session recordings
• Looker / Metabase / Redash — BI-инструменты для построения кастомных дашбордов из данных
• Figma + FigJam — для ручного анализа и визуализации данных в виде схем

Идеальный стек: продуктовая аналитика (Amplitude/Mixpanel) + heatmaps (Clarity) + BI для агрегации (Metabase).

### Как построить первый дашборд за один день

Шаг 1. Определи 5–7 метрик, которые хочешь трекать. Не больше — иначе дашборд превращается в стену цифр.

Шаг 2. Для каждой метрики пойми, где берутся данные. Аналитика? Сервер? Опросы? Убедись, что данные вообще собираются.

Шаг 3. Построй первую версию в любом инструменте. Это может быть таблица в Notion, дашборд в Amplitude или просто Google Sheet с обновляемыми данными.

Шаг 4. Поставь напоминание смотреть на дашборд — раз в неделю, в один и тот же день. Дашборд без регулярного просмотра — бесполезен.

Шаг 5. Через месяц ревизия: какие метрики оказались полезными, какие — никогда не использовались? Убери лишнее, добавь нужное.

## Как читать метрики: базовые принципы

### Смотри на динамику, не на абсолютные значения

«Task completion rate = 72%» — что это значит? Ничего без контекста. «Task completion rate вырос с 58% до 72% за месяц» — это уже информация.

Для каждой метрики нужен базлайн и направление движения.

### Сравнивай сегменты

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

• Новые vs. опытные
• Мобайл vs. десктоп
• Разные тарифы
• Разные каналы привлечения

Агрегированные данные скрывают проблемы. Разбивка по сегментам их выявляет.

### Ищи корреляции с изменениями

Метрика изменилась — что происходило в это время? Был релиз? Маркетинговая кампания? Сезонность? Изменение в onboarding flow?

Ведение changelog изменений рядом с дашбордом — хорошая практика. Через 3 месяца сложно вспомнить что именно делали в конкретную неделю.

### Не путай корреляцию и каузальность

Две метрики движутся вместе — это не значит, что одна вызывает другую. Нужны A/B-тесты, чтобы установить причинно-следственные связи.

## Что делать с данными: от наблюдения к действию

Дашборд — это не конечная точка, это начало. Данные должны приводить к конкретным действиям.

Процесс работы с данными:

1. Замечаешь отклонение — метрика упала или выросла аномально
2. Формулируешь гипотезу — почему так могло произойти
3. Проверяешь данными — смотришь на связанные метрики, делаешь разбивку по сегментам
4. Формулируешь задачу — если проблема найдена, описываешь конкретную задачу для дизайна
5. Делаешь изменение и меришь — A/B-тест или до/после с контрольной группой

Данные без действия — это просто числа. Действие без данных — это просто интуиция. Хорошая работа с метриками — это и то и другое вместе.

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

┌─────────────────────────────────────────────────────────┐
│ СИГНАЛЫ ТРЕВОГИ (обновляется ежедневно)                 │
│                                                         │
│ Error rate onboarding:  2.3% ▼ (норма < 5%)  ✅        │
│ Checkout error rate:    8.1% ▲ (норма < 3%)  🔴        │
│ 404 errors today:       143  ▲ (норма < 50)  🟡        │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ ЗДОРОВЬЕ ПРОДУКТА (обновляется еженедельно)             │
│                                                         │
│ D1 Retention:   48% (+3% к прошлой неделе)             │
│ D7 Retention:   31% (+1%)                              │
│ D30 Retention:  22% (-2%) ← нужно разобраться          │
│                                                         │
│ Activation rate:  64% (+5%)                            │
│ Time to activation: 4.2 мин (-0.8 мин)                 │
│                                                         │
│ NPS: 42 (опрос раз в квартал)                          │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ КЛЮЧЕВЫЕ ФЛОУ (обновляется еженедельно)                 │
│                                                         │
│ Onboarding funnel:                                      │
│ Регистрация → Шаг 1: 91%                               │
│ Шаг 1 → Шаг 2:       78%                               │
│ Шаг 2 → Шаг 3:       52% ← проблема                   │
│ Шаг 3 → Активация:   89%                               │
│                                                         │
│ Checkout funnel:                                        │
│ Корзина → Оплата:     74%                               │
│ Оплата → Подтверждение: 61% ← проблема                 │
└─────────────────────────────────────────────────────────┘

Это не идеальный вид дашборда — он будет разным для разных продуктов. Но структура «тревога → здоровье → детали» работает универсально.

## Чего не должно быть в дашборде

Ванильные метрики. Количество страниц просмотренных за сессию, bounce rate без контекста, количество «лайков» — метрики, которые хорошо выглядят, но ни на что не влияют.

Слишком много метрик. Если на дашборде 40 графиков — ты смотришь на него по диагонали и ничего не видишь. 7±2 — рабочий объём.

Данные без контекста. Цифра без базлайна, тренда и нормы — почти бесполезна.

Метрики, которые никуда не ведут. Если данные ни разу не привели к конкретному действию за квартал — зачем они на дашборде?

## Как автоматизировать сбор данных для дашборда

Дашборд, который обновляется вручную — умирает. Данные в него вводятся нерегулярно, потом забываются, потом перестают использоваться.

Автоматизация — не роскошь, это условие выживания дашборда.

### Уровни автоматизации

Уровень 1: Готовые дашборды в аналитических инструментах. Amplitude, Mixpanel, Google Analytics — все имеют встроенные дашборды. Настраиваешь один раз, данные обновляются автоматически. Минус: ограниченная гибкость в визуализации.

Уровень 2: BI-инструмент с автоматическим обновлением. Metabase, Looker, Tableau, Power BI — подключаются к базе данных и обновляют данные по расписанию. Можно строить любые визуализации. Требует настройки, но гибче.

Уровень 3: Custom дашборд. Для команд с инженерными ресурсами — собственный дашборд на React/Vue с прямым обращением к API аналитики. Максимальная гибкость, максимальные затраты.

Уровень 0 (антипаттерн): Google Sheets с ручным заполнением. Работает только первые 2 недели. Потом данные устаревают и дашборд превращается в архив.

### Что подключить к дашборду

• Продуктовая аналитика: события из Amplitude/Mixpanel — retention, funnel, feature adoption
• Веб-аналитика: GA4 — трафик, источники, поведение на сайте
• Поддержка: Zendesk, Intercom — количество и категории обращений
• Мониторинг: Sentry, Datadog — ошибки и производительность
• Опросы: результаты NPS, SUS из Typeform или собственной системы

## Как читать данные в условиях неопределённости

Данные редко говорят однозначно. Чаще они создают вопросы, а не дают ответы. Умение работать с неопределённостью — ключевой навык.

### Принцип «множественные гипотезы»

Когда видишь отклонение в метрике — не спеши к первому объяснению. Сформулируй 3–5 возможных причин прежде чем двигаться к выводу.

Пример: D7 retention упал с 38% до 31%.

Возможные причины:

1. Изменения в онбординге (был релиз на прошлой неделе?)
2. Изменение качества трафика (сменился рекламный канал?)
3. Сезонность (каникулы, праздники?)
4. Технический сбой в период удержания (ошибки в приложении?)
5. Изменение конкурентной среды (вышел новый конкурент?)

Только после проверки каждой гипотезы данными — можно делать вывод. Иначе лечишь не ту болезнь.

### Correlation ≠ causation: всегда

Самый частый ошибочный вывод из данных: «метрика X изменилась, потому что мы изменили Y». Одновременность — не причинность.

Правило: если хочешь утверждать причинно-следственную связь — нужен контролируемый эксперимент (A/B-тест). Если A/B-теста нет — корреляция остаётся гипотезой.

### Как работать с неполными данными

Часто данных не хватает для полной картины. Это не повод отказаться от анализа — повод явно маркировать неопределённость.

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

«Данные показывают что проблема в шаге 3, нужно срочно переделать» — без достаточных данных это самозаблуждение.

## Дашборд для разных ролей в команде

Один дашборд для всей команды — редко хорошая идея. У продакта, дизайнера, разработчика, CEO — разные вопросы и разный уровень детализации.

CEO-уровень: бизнес-метрики (MRR, churn, LTV, CAC). Обновляется ежемесячно. Максимально высокоуровневый. Не нужны детали воронок и feature adoption.

Продакт-уровень: продуктовые KPI (retention, activation, feature adoption, NPS). Обновляется еженедельно. Средний уровень детализации.

Дизайнер-уровень: UX-метрики (task completion, error rate, funnel по конкретным флоу, результаты тестов). Обновляется по мере необходимости.

Разработчик-уровень: техническое (error rate, performance metrics, uptime). Обновляется в реальном времени.

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

## Частые ошибки в работе с дашбордом

### Ошибка: «Датацентричность» без действий

Собрали данные, построили красивый дашборд, смотрим каждую неделю. Но данные не приводят к изменениям. Это data paralysis.

Решение: к каждой метрике привязан «owner» (ответственный) и SLA реакции. Если error rate превысил порог — ответственный обязан отреагировать в течение 48 часов.

### Ошибка: Дашборд только для отчётности

Дашборд используется, чтобы «показать что мы работаем» на встречах с менеджментом. Не для принятия решений.

Признак: никто не смотрит на дашборд между встречами. Решение: задавай вопрос «Какое решение мы примем по этим данным?» для каждой метрики. Если ответа нет — метрика лишняя.

### Ошибка: Слишком большой дашборд

40 метрик, 20 графиков. Никто не смотрит на весь дашборд — слишком долго.

Правило: если не умещается на одном экране без скролла — слишком много. Начни с 5–7 ключевых метрик, добавляй только когда есть конкретная задача.

### Ошибка: Нет исторических данных

Дашборд показывает только текущие значения, без истории. Нет тренда — нет контекста.

Решение: минимум 12 месяцев истории для всех ключевых метрик. Это позволяет видеть сезонность и долгосрочные тренды.

## ИИ и дашборд: как анализировать метрики и находить проблемы быстро

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

### Промпт: разобраться в данных за неделю

Вместо того чтобы самому интерпретировать набор цифр — дай их Claude с контекстом:

Вот данные нашего продукта за последние 4 недели:

Неделя 1: D7 retention 34%, activation rate 51%, error rate формы 6%
Неделя 2: D7 retention 36%, activation rate 53%, error rate формы 5.8%
Неделя 3: D7 retention 29%, activation rate 48%, error rate формы 7.2%
Неделя 4: D7 retention 27%, activation rate 45%, error rate формы 8.1%

На неделе 3 мы [описание изменений в продукте / маркетинге / если ничего — так и скажи].

Что скорее всего происходит? Какие гипотезы объясняют эту динамику? Что нужно проверить в первую очередь?

### Промпт: сформулировать гипотезы по аномалии

В нашем дашборде мы видим:
— Конверсия в регистрацию снизилась с 4.2% до 2.8% за две недели
— Трафик на лендинг не изменился
— Bounce rate на странице регистрации вырос с 32% до 51%
— Error rate на форме не изменился (остался 3%)

Что могло вызвать эту аномалию? Предложи 5 гипотез от наиболее до наименее вероятной. Для каждой — как проверить за 1–2 дня без разработки.

### Промпт: выбрать метрики для дашборда

Я продуктовый дизайнер в [тип компании / продукта].
Моя зона ответственности: [онбординг / ключевые флоу / конверсия / и т.д.].
Инструменты аналитики, которые у нас есть: [Amplitude / GA4 / Mixpanel / ничего / другое].

Помоги выбрать 7 метрик для моего рабочего дашборда.

Критерии:
— Метрики должны быть измеримы нашими инструментами
— Должны давать сигнал к действию (а не просто информацию)
— Должны охватывать как UX-качество, так и связь с бизнес-результатом

Для каждой метрики:
— Почему именно она
— Как часто смотреть (ежедневно / еженедельно / при изменениях)
— При каком отклонении стоит реагировать

### Промпт: написать summary по дашборду

Если нужно рассказать команде о состоянии метрик — Claude поможет структурировать.

Вот данные нашего продукта за [период]:

[вставь ключевые цифры]

Напиши короткий (5–7 предложений) weekly summary для команды:
— Что хорошо (с конкретными числами)
— Что вызывает вопросы (с конкретными числами)
— Что предлагаем проверить на следующей неделе

Тон: прямой, без воды, ориентированный на действия.

### Работа с сырыми данными: CSV в выводы

Если у тебя есть выгрузка данных — можно загрузить её прямо в Claude:

Вот CSV с данными событий нашей аналитики за месяц:
[загружаешь файл или вставляешь таблицу]

Столбцы: user_id, event_name, event_date, properties

Посчитай:
1. Funnel от [событие начала] до [событие завершения]
2. Median time между [событие А] и [событие Б]
3. Процент пользователей, дошедших до [ключевое событие] в первые 7 дней

Покажи результаты и интерпретацию.

Claude умеет считать когорты, строить воронки и находить паттерны прямо в разговоре — без SQL и без аналитика.