Туториалы Данные

Dashboard Design для стартапов: почему 3 дашборда лучше 30 (и как AI собирает их за минуты)

Что такое архитектура дашбордов стартапа?

Архитектура дашбордов стартапа — трёхуровневая система, организующая бизнес-метрики по аудитории и частоте принятия решений, а не по доступности данных. Три уровня: Executive (еженедельно для руководства — выручка, runway, CAC/LTV, churn), Product (ежедневно для продуктовой команды — activation, retention, воронка, DAU/MAU) и Engineering (в реальном времени для on-call инженеров — перцентили latency, error rate, DORA-метрики). Каждый дашборд отвечает на один вопрос для одной аудитории и ограничен 6–8 метриками с целевыми значениями, трендами и алертами.

TL;DR

  • -Средний стартап на Series A накапливает 15–40 дашбордов; регулярно просматриваются только 3–5 — остальные устаревают в течение 2 недель
  • -Executive dashboard: максимум 8 метрик, MRR должен показываться с разбивкой new/expansion/churn — единая цифра MRR маскирует высокий churn за общим ростом
  • -Product dashboard: retention обязательно в виде heatmap по когортам, а не линейного графика — линейный график теряет межкогортный контекст, который выявляет изменения качества onboarding
  • -Engineering dashboard: всегда показывайте latency как P50/P95/P99 — медиана скрывает 5% пользователей (часто самых высокооплачиваемых), испытывающих P95 > 2 секунды
  • -Pie charts запрещены — человек плохо сравнивает углы; horizontal bar chart передаёт ту же информацию с более высокой точностью

Средний стартап на Series A накапливает от 15 до 40 дашбордов, из которых регулярно просматриваются 3-5. Остальные устаревают в течение двух недель после создания. Проблема не в отсутствии данных, а в их организации.

Три дашборда покрывают 90% потребностей стартапа от pre-seed до Series B: Executive, Product и Engineering. Ниже — конкретные метрики для каждого, SQL-запросы и готовые промпты для генерации в Metabase и Grafana.

Почему дашборды в стартапах не работают

Типичный сценарий: CTO создаёт дашборд для инвесторского отчёта. Product manager собирает свой набор графиков. Data analyst строит третий для маркетинга. Через месяц никто не помнит, какой дашборд актуален. Через два — все строят новые.

Корневая причина — отсутствие архитектуры дашбордов. Каждый дашборд создаётся под конкретный запрос, а не как часть системы. Результат:

Дублирование метрик. Revenue отображается в трёх местах с тремя разными определениями. В одном — gross revenue, в другом — net, в третьём — MRR. Никто не знает, какая цифра правильная.

Информационный шум. 50 графиков на одном экране. Глаз не цепляется ни за что. Аномалии теряются среди нормальных колебаний.

Отсутствие actionability. График показывает падение retention. Что делать? Дашборд не отвечает. Нужен второй дашборд, чтобы разобраться. Потом третий. Цепочка анализа разрывается.

Решение: три уровня дашбордов, каждый для своей аудитории, с чётким набором метрик и определённой частотой просмотра.

┌──────────────────────────────────────────────────────┐
│              Dashboard Architecture                   │
├──────────────┬──────────────┬────────────────────────┤
│  Executive   │   Product    │     Engineering        │
│  (Weekly)    │   (Daily)    │     (Real-time)        │
├──────────────┼──────────────┼────────────────────────┤
│  Revenue     │  Activation  │  Uptime / SLA          │
│  Burn rate   │  Retention   │  Latency P50/P95/P99   │
│  Runway      │  Engagement  │  Error rate            │
│  CAC / LTV   │  Conversion  │  Deploy frequency      │
│  Growth rate │  NPS / CSAT  │  Incident count        │
└──────────────┴──────────────┴────────────────────────┘

Executive Dashboard: метрики для решений

Executive dashboard просматривает CEO, CFO и совет директоров раз в неделю. Цель — ответить на один вопрос: движется ли бизнес в правильном направлении?

Максимум 6-8 метрик. Каждая метрика имеет target, текущее значение и тренд. Никаких таблиц с сырыми данными.

Обязательные метрики

MRR (Monthly Recurring Revenue). Основная метрика для SaaS. Отображать с разбивкой: new MRR, expansion MRR, churned MRR, net new MRR. Без разбивки цифра бесполезна — рост MRR может маскировать высокий churn.

-- Net New MRR breakdown (PostgreSQL)
WITH mrr_changes AS (
  SELECT
    date_trunc('month', event_date) AS month,
    SUM(CASE WHEN type = 'new' THEN amount ELSE 0 END) AS new_mrr,
    SUM(CASE WHEN type = 'expansion' THEN amount ELSE 0 END) AS expansion_mrr,
    SUM(CASE WHEN type = 'contraction' THEN amount ELSE 0 END) AS contraction_mrr,
    SUM(CASE WHEN type = 'churn' THEN amount ELSE 0 END) AS churned_mrr
  FROM subscription_events
  WHERE event_date >= date_trunc('month', NOW()) - INTERVAL '12 months'
  GROUP BY 1
)
SELECT
  month,
  new_mrr,
  expansion_mrr,
  contraction_mrr,
  churned_mrr,
  (new_mrr + expansion_mrr + contraction_mrr + churned_mrr) AS net_new_mrr
FROM mrr_changes
ORDER BY month;

Burn Rate и Runway. Сколько компания тратит в месяц и на сколько месяцев хватит денег. Runway ниже 6 месяцев — сигнал к немедленным действиям. Формула: runway = cash_balance / avg_monthly_burn_last_3_months.

CAC и LTV. Customer Acquisition Cost и Lifetime Value. Соотношение LTV/CAC ниже 3 — бизнес-модель не сходится. Отображать оба числа рядом с коэффициентом.

Growth Rate (MoM). Месячный рост в процентах. Для стартапа на ранней стадии здоровый показатель — 15-20% MoM. Отображать как линию за последние 12 месяцев с target-зоной.

Churn Rate. Процент пользователей/revenue, потерянных за месяц. Для B2B SaaS нормальный logo churn — менее 5% в месяц, revenue churn — менее 2%.

Cash Balance. Текущий остаток на счетах. Простое число с трендом за 6 месяцев.

Антипаттерны Executive Dashboard

Vanity metrics — общее количество зарегистрированных пользователей, суммарный revenue за всё время, количество загрузок. Эти числа только растут и ничего не говорят о здоровье бизнеса. Убирать без сожалений.

Слишком много деталей — разбивка revenue по 20 сегментам, воронки с 12 шагами. Executive dashboard отвечает на вопрос “куда мы движемся”, а не “почему именно так”. Детали — в product dashboard.

Product Dashboard: воронка, retention, engagement

Product dashboard открывает product manager каждое утро. Цель — понять, как пользователи взаимодействуют с продуктом, где теряются и что работает.

Обязательные метрики

Activation Rate. Процент новых пользователей, достигших “aha moment”. Определение зависит от продукта. Для Slack — отправка 2000 сообщений командой. Для Dropbox — сохранение первого файла. Определить свой activation event и трекать конверсию в него.

-- Activation rate by cohort (weekly)
WITH signups AS (
  SELECT
    user_id,
    date_trunc('week', created_at) AS cohort_week
  FROM users
  WHERE created_at >= NOW() - INTERVAL '12 weeks'
),
activated AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_name = 'activation_event'
    AND created_at <= users.created_at + INTERVAL '7 days'
)
SELECT
  s.cohort_week,
  COUNT(DISTINCT s.user_id) AS total_signups,
  COUNT(DISTINCT a.user_id) AS activated_users,
  ROUND(COUNT(DISTINCT a.user_id)::numeric / COUNT(DISTINCT s.user_id) * 100, 1) AS activation_rate
FROM signups s
LEFT JOIN activated a ON s.user_id = a.user_id
GROUP BY s.cohort_week
ORDER BY s.cohort_week;

Retention Curve. Когортный retention — процент пользователей, возвращающихся на N-й день/неделю после регистрации. Отображать как heatmap: когорты по вертикали, периоды по горизонтали. Здоровая retention curve выходит на плато. Если кривая падает до нуля — продукт не удерживает.

Conversion Funnel. Шаги от первого визита до оплаты. Максимум 5-6 шагов. На каждом шаге — абсолютное число и процент конверсии. Шаг с наибольшим drop-off — приоритет для продуктовой команды.

DAU/WAU/MAU и DAU/MAU ratio. DAU/MAU ratio (stickiness) показывает, насколько регулярно пользователи возвращаются. Для SaaS B2B нормальное значение — 20-25%. Для consumer-приложений зависит от категории (мессенджеры 50%+, e-commerce 10-15%).

Feature Adoption. Процент активных пользователей, использующих конкретную функцию. Помогает понять, какие функции реально нужны, а какие создают complexity без value.

Визуализация Product Dashboard

Retention — только heatmap или cohort-таблица. Линейный график retention по одной когорте теряет контекст.

Воронка — горизонтальная. Каждый шаг с абсолютным числом и процентом drop-off, а не конверсией от предыдущего шага. Drop-off фокусирует внимание на проблемных местах.

DAU/MAU — линейный график с target-зоной. Не bar chart: тренд важнее абсолютных значений.

Engineering Dashboard: uptime, latency, deploys

Engineering dashboard работает в реальном времени. Его смотрит on-call инженер, tech lead и CTO. Цель — моментально обнаружить деградацию и оценить скорость разработки.

Обязательные метрики

Uptime / SLA. Процент времени без инцидентов. Для SaaS стандартный SLA — 99.9% (допустимый downtime 8.7 часов в год). Отображать текущий статус (UP/DOWN), uptime за текущий месяц и за rolling 30 days.

Latency P50/P95/P99. Медиана не показывает проблемы — 5% пользователей с P95 > 2 секунды могут быть самыми платящими. Всегда отображать три перцентиля. P99 резко выше P95 — сигнал о проблемах с конкретными эндпоинтами или пользователями.

# Grafana / Prometheus: latency percentiles
histogram_quantile(0.50, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Error Rate. Процент запросов с HTTP 5xx. Норма — ниже 0.1%. Порог алерта — 1%. Отображать как timeseries с аннотациями деплоев. Корреляция между деплоем и ростом ошибок видна моментально.

Deploy Frequency. Количество деплоев в день/неделю. Одна из четырёх DORA-метрик. Высокая частота деплоев коррелирует с высокой производительностью команды. Отображать как bar chart по дням.

MTTR (Mean Time To Recovery). Среднее время восстановления после инцидента. Вторая ключевая DORA-метрика. Для high-performing команд — менее 1 часа. Отображать как линию с трендом за 3 месяца.

Incident Count. Количество инцидентов по severity: critical, major, minor. Тренд за 3 месяца. Растущий тренд при растущей системе — нормально. Растущий тренд при стабильной системе — сигнал о техническом долге.

DORA Metrics в Engineering Dashboard

Четыре DORA-метрики (Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR) стоит вынести в отдельную секцию. Они показывают эффективность инженерного процесса, а не состояние системы.

┌────────────────────────────────────────────────────────────┐
│                    DORA Metrics                             │
├───────────────┬───────────────┬──────────────┬─────────────┤
│  Deploy Freq  │  Lead Time    │ Change Fail  │    MTTR     │
│  12/week      │  2.3 days     │    4.2%      │   47 min    │
│  ▲ vs target  │  ▼ vs target  │ ✓ vs target  │ ✓ vs target │
│  (10/week)    │  (1 day)      │   (<15%)     │   (<1 hr)   │
└───────────────┴───────────────┴──────────────┴─────────────┘

Промпты для Metabase и Grafana

Ручная сборка дашборда занимает часы. Ниже — промпты для GPT-5.4 и Claude, которые генерируют конфиги и SQL-запросы.

Executive Dashboard в Metabase

Ты — data analyst в B2B SaaS стартапе. Сгенерируй SQL-запросы для Metabase
(PostgreSQL) для Executive Dashboard.

Схема базы:
- users (id, created_at, plan, status)
- subscriptions (id, user_id, mrr, started_at, cancelled_at, plan)
- payments (id, user_id, amount, created_at, type)
- expenses (id, amount, category, date)

Метрики:
1. MRR с разбивкой (new, expansion, contraction, churn) за 12 месяцев
2. Burn rate (средний за 3 месяца) и runway
3. CAC (marketing spend / new customers) за 6 месяцев
4. LTV (average revenue per user * average lifetime)
5. MoM growth rate
6. Logo churn rate по месяцам

Для каждой метрики:
- SQL-запрос, совместимый с Metabase
- Рекомендуемый тип визуализации
- Suggested alert threshold

Product Dashboard в Metabase

Ты — product analyst. Сгенерируй SQL-запросы для Product Dashboard в Metabase.

Схема:
- users (id, created_at, last_active_at)
- events (id, user_id, event_name, properties, created_at)
- sessions (id, user_id, started_at, duration_seconds, pages_viewed)

Activation event: "completed_onboarding"

Метрики:
1. Activation rate по недельным когортам (конверсия в activation event
   в первые 7 дней)
2. Retention heatmap: когорты по неделям, retention на Day 1, 7, 14, 30
3. Conversion funnel: visit → signup → onboarding_start →
   completed_onboarding → first_payment
4. DAU/WAU/MAU и stickiness (DAU/MAU)
5. Feature adoption rate для top-5 событий

Формат: SQL + тип визуализации + описание того, что показывает метрика.

Engineering Dashboard в Grafana

Ты — SRE-инженер. Сгенерируй конфигурацию Grafana dashboard (JSON model)
для Engineering Dashboard.

Datasources:
- Prometheus (метрики приложения и инфраструктуры)
- Loki (логи)

Метрики:
1. Uptime: probe_success из blackbox exporter, SLA за rolling 30 days
2. Latency: http_request_duration_seconds_bucket — P50, P95, P99
3. Error rate: rate(http_requests_total{status=~"5.."}[5m]) /
   rate(http_requests_total[5m])
4. Deploy frequency: аннотации из CI/CD (deploy events)
5. MTTR: средняя длительность алертов в состоянии "firing"
6. Incident count по severity: count из alertmanager

Для каждой панели:
- PromQL-запрос
- Тип панели (stat, timeseries, gauge, table)
- Thresholds для цветовой индикации (green/yellow/red)
- Рекомендуемый alert rule

Как адаптировать промпты

Промпты выше — шаблоны. Для конкретного стартапа нужно подставить:

  1. Схему базы данных. Реальные названия таблиц и полей. AI генерирует SQL под конкретную схему точнее, чем переписывает абстрактные запросы.

  2. Определение activation event. У каждого продукта своё. Подставить конкретное событие из аналитики.

  3. Бизнес-контекст. B2B vs B2C, средний чек, цикл продаж — влияют на выбор метрик и thresholds.

  4. Datasource-специфику. PostgreSQL vs ClickHouse vs BigQuery — разный SQL-синтаксис для оконных функций и date manipulation.

Принципы визуализации

Одна метрика — один вопрос. Каждый график отвечает на конкретный вопрос. “Растёт ли MRR?” — линейный график. “Какой шаг воронки теряет больше всего?” — воронка с drop-off. “В норме ли latency прямо сейчас?” — gauge с цветовыми зонами.

Контекст всегда рядом. Число без контекста бесполезно. MRR $50K — хорошо или плохо? Добавить target ($60K), предыдущий период ($45K), тренд (рост 11% MoM). Теперь понятно: MRR растёт, но ниже цели.

Цвет = сигнал. Зелёный — в норме. Жёлтый — требует внимания. Красный — нужно действовать. Не использовать цвет для декорации. Не использовать больше трёх цветов на одном графике. Дальтоники составляют около 8% мужчин — дублировать цвет текстовой меткой.

Pie charts запрещены. Человек плохо сравнивает углы. Horizontal bar chart передаёт ту же информацию точнее. Единственное исключение — две категории (50/50 split), и даже тогда stacked bar chart лучше.

Mobile-first layout. CEO просматривает дашборд с телефона в такси. Ключевые метрики — в верхней части, крупным шрифтом. Детальные графики — ниже, с возможностью прокрутки. Metabase и Grafana поддерживают адаптивный layout.

Автоматизация: алерты и scheduled reports

Дашборд, который никто не открывает, бесполезен. Два механизма решают эту проблему.

Алерты на аномалии. Настроить пороговые алерты для критических метрик:

  • MRR drop > 10% MoM → Slack #revenue
  • Error rate > 1% на 5 минут → PagerDuty
  • Runway < 6 месяцев → email CEO + CFO
  • Activation rate drop > 20% WoW → Slack #product

В Metabase алерты создаются через UI: открыть вопрос → Alert → задать условие и канал. В Grafana — через alert rules с contact points.

Scheduled reports. Еженедельная отправка Executive Dashboard в Slack или email. В Metabase: Dashboard → Sharing → Schedule. В Grafana: Reporting (Enterprise) или экспорт через API + cron.

Комбинация push (алерты) и pull (дашборд) покрывает оба сценария: срочные проблемы доставляются мгновенно, регулярный обзор происходит по расписанию.

Итоговый чеклист

Перед запуском трёх дашбордов пройти по пунктам:

Executive Dashboard:

  • 6-8 метрик, каждая с target и трендом
  • Нет vanity metrics (total users, total downloads)
  • MRR с разбивкой, не просто одной цифрой
  • Runway и burn rate рядом
  • Еженедельная рассылка настроена

Product Dashboard:

  • Activation event определён и задокументирован
  • Retention как heatmap по когортам
  • Воронка с drop-off, а не только конверсией
  • DAU/MAU ratio с target-зоной
  • Алерт на падение activation rate

Engineering Dashboard:

  • Latency с тремя перцентилями (P50/P95/P99)
  • Error rate с аннотациями деплоев
  • DORA metrics в отдельной секции
  • Алерты на error rate и uptime в PagerDuty
  • MTTR трекается автоматически

Три дашборда. Конкретные метрики. Промпты для генерации. Этого достаточно для принятия решений от pre-seed до Series B. Начать с executive — он покажет, насколько здоров бизнес. Добавить product — он покажет, как растить продукт. Подключить engineering — он покажет, как не сломать то, что построено.

Если вы используете LLM в продакшене и вам нужна observability для AI-компонентов — руководство по Langfuse покрывает трейсинг, cost tracking и prompt management.

Нужна помощь с проектированием дашбордов и аналитикой стартапа? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.

FAQ

Executive dashboard должен показывать данные в реальном времени или с задержкой?

С задержкой — и это намеренно. Executive dashboard, обновляющийся в реальном времени, создаёт шум и тревогу из-за нормальных внутридневных колебаний. Данные с недельной кадансностью и сравнением WoW и MoM соответствуют решениям, принимаемым в недельном цикле. Данные в реальном времени принадлежат Engineering dashboard, где on-call инженеру нужно видеть всплеск latency в течение секунд после его возникновения.

Какой порог для алерта на activation rate правильный в Metabase?

Алертить при падении на 20% WoW относительно 4-недельного скользящего среднего — не против фиксированного числа. Абсолютный activation rate варьируется в зависимости от микса источников трафика: неделя с большим объёмом платного трафика покажет более низкий показатель, чем неделя с преобладанием реферального. Процентные алерты на скользящем базовом уровне автоматически нормализуют изменения состава трафика и срабатывают только тогда, когда в onboarding реально что-то сломалось.

Как DORA-метрики помогают стартапу, у которого ещё нет SLA и формальных процессов управления инцидентами?

Они устанавливают базовую линию до того, как она понадобится. Стартап, отслеживающий deploy frequency и MTTR с первого дня, накапливает исторические данные, позволяющие обнаружить, когда технический долг начинает замедлять скорость разработки — обычно это происходит около 20–30 инженеров, когда неформальная координация перестаёт работать. DORA-данные также становятся достоверным сигналом при due diligence Series B, где зрелость инженерного процесса всё активнее проверяется наравне с продуктовыми метриками.