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

> Практическое руководство по проектированию дашбордов для стартапов: executive, product и engineering. Конкретные метрики, SQL-запросы, промпты для генерации в Metabase и Grafana.
> Author: Roman Belov · Published: 2026-04-16 · Source: https://futurecraft.pro/ru/blog/dashboard-design-startups/

По нашим наблюдениям, стартап на 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.

```sql
-- 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 и трекать конверсию в него.

```sql
-- 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 — сигнал о проблемах с конкретными эндпоинтами или пользователями.

```promql
# 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](/ru/blog/llm-observability-langfuse/) покрывает трейсинг, cost tracking и prompt management.

---

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