Примеры дашбордов: продажи, продукт, маркетинг и руководитель

Коротко: какой пример взять за основу

Руководителю нужен риск и решение на одном экране; продажам — объём, состав и детали сделок; продукту — поведение пользователей от входа до целевого действия. Маркетингу нужны каналы с расходами и результатом, операционной команде — очередь исключений и свежесть, финансам — согласованные денежные определения и план-факт. Выберите аудиторию, период и действие до выбора шаблона. Один макет для всех шести задач обычно прячет важное.

Две реальные мини-версии ниже используют учебные данные. «Авиаперевозки» содержат бронирования и рейсы, Northstar — регистрации и события. Мы не подставляем отсутствующие расходы в стоимость привлечения, возвраты — в прибыль, а события — в удержание. Дашборд остаётся честным, если показывает, чего ещё не хватает для решения.

Как читать макеты: вопрос, зерно, период, действие

В каждом примере запишите одну строку спецификации: «кто открывает, как часто, что решает, что считает одним событием». Это кажется излишним до первого расхождения сумм. Если «продажа» в карточке означает оформленную бронь, а в таблице — вылет пассажира, оба элемента могут быть верны по отдельности и при этом противоречить друг другу. Над таблицей макета указан вопрос, которому подчинены зоны экрана.

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

Перед копированием любого примера проверьте, какие таблицы доступны в вашей организации. В схеме может стоять карточка «маржа», но без себестоимости и правил возвратов она не вычисляется. Удалите её из первого релиза или явно пометьте как будущую; ноль на пустом месте создаст у читателя впечатление, что бизнес действительно ничего не заработал.

1. Продажи: сколько бронирований и откуда изменение

Аудитория — коммерческий руководитель, просмотр по понедельникам после закрытия недели. Вопрос: выросла ли сумма оформленных бронирований 3–9 августа 2026 года к 27 июля — 2 августа и какая часть изменения пришлась на брони с одним или несколькими билетами? Одна строка факта — book_ref, сумма — total_amount из bookings. Это сумма бронирования до возможных возвратов, а не признанная выручка. Текущее значение 3 377 874 800 ₽ против 3 116 503 800 ₽ (+8,39%). Броней 42 561 против 39 216 (+8,53%).

Ещё четыре полезные метрики: средняя сумма брони = сумма / число броней (79 365,49 ₽ сейчас), дневная сумма, число броней с одним билетом и их вклад в прирост, число многобилетных броней и их вклад. Средняя сумма почти не изменилась (−0,13%). Разбивка обязана считать билеты по броням до JOIN, иначе многобилетная бронь умножит деньги. Разница по сумме составила 261 371 000 ₽: 125 368 500 ₽ в однобилетных и 136 002 500 ₽ в многобилетных. Это вклад сегментов, не доказательство причины.

Запрос для продаж и контроль гранулярности

Для карточки не нужен JOIN. Один запрос по bookings даёт число, сумму и среднюю. Чтобы получить разрез по количеству билетов, сначала сделайте ticket_counts AS (SELECT book_ref, COUNT(*) ... GROUP BY book_ref) и соедините его с bookings. Обязательно проверьте, что число строк после соединения осталось равным числу броней в периоде. Если билет не найден, решите отдельно, это ошибка данных или допустимое состояние; не превращайте пропуск в тип «1 билет».

Ниже запрос итоговых карточек. Его результат повторяется в таблице. Ошибка, которая портит решение: назвать SUM(total_amount) «выручкой» и увеличить рекламный бюджет, хотя в данных нет оплат и возвратов. Чтобы говорить о выручке, нужна согласованная финансовая модель; этот пример отвечает только о сумме оформленных броней.

SELECT COUNT(*) AS bookings, SUM(total_amount) AS amount_rub,
       ROUND(AVG(total_amount), 2) AS avg_booking_rub
FROM bookings
WHERE book_date >= TIMESTAMP '2026-08-03'
  AND book_date < TIMESTAMP '2026-08-10';

2. Дашборд руководителя: отклонение и владелец действия

Генеральный директор смотрит страницу раз в неделю перед планёркой. Его вопрос — где требуется решение сегодня и кто возьмёт его в работу. В верхнем ряду достаточно 5–8 согласованных метрик: сумма бронирований и отклонение к сопоставимой неделе, число бронирований, средняя сумма, доля отменённых рейсов, доля рейсов с задержкой более 30 минут, число открытых инцидентов, скорость закрытия инцидентов, статус загрузки. Последние две величины появятся только если компания ведёт журнал инцидентов: в учебной базе его нет.

Сводка не должна склеивать разные даты. Если рейсы обновились сегодня, а деньги — позавчера, рядом с каждым блоком покажите своё время данных. В учебном недельном срезе у рейсов с 3 по 9 августа 3 отмены из 3 798 записей. Это не «текущая ситуация в аэропорту», а только статический архивный снимок. Обновляемую эксплуатационную панель из этого набора не построить.

Верхний уровень отличается от свалки всех метрик тем, что каждое отклонение ведёт в страницу владельца. Если на обзоре загорелась доля отмен, по переходу должны открыться отменённые рейсы с датой, статусом и объяснением, а не ещё одна картинка той же средней. Рядом с карточкой полезно написать, кто отвечает за решение и когда его нужно пересмотреть. Иначе планёрка закончится обсуждением цвета, а не поручением. Для финансовых итогов такая навигация не заменяет сверку с бухгалтерским источником.

3. Продукт: где пользователь не доходит до первого действия

Продуктовый менеджер смотрит страницу после релиза и на недельном разборе. В Northstar 18 пользователей зарегистрировались, у 10 есть событие workspace_created: если брать зарегистрированных как знаменатель и событие как признак, наблюдаемая доля 10/18 = 55,6%. Отдельный ряд DAU 1–7 июня: 3, 5, 6, 6, 7, 7, 4. Это учебная малая выборка; на ней нельзя делать вывод о стабильном тренде или качестве релиза. Но она позволяет показать, как один набор событий становится карточкой, воронкой и временным рядом.

Набор 5–8 метрик здесь такой: регистрации, пользователи с первым рабочим пространством, доля активации с фиксированным окном, DAU, доля вернувшихся на следующий день при определённой когорте, число ключевых действий, ошибки после регистрации, время до первого действия. Последние четыре нельзя честно вычислить из двух приведённых агрегатов без дополнительной логики и полей; в макете оставьте определения и проверку доступности. При разговоре об активации обязательно спросите, ограничено ли время после регистрации. Событие когда угодно — не D1 и не D7.

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

Сначала посчитайте регистрации отдельным запросом COUNT(DISTINCT user_id) по таблице пользователей. Затем посчитайте COUNT(DISTINCT user_id) среди событий workspace_created, причём определите, должны ли пользователи входить в выбранную когорту регистрации. DAU по дню — COUNT(DISTINCT user_id) среди событий активности с группировкой по календарной дате. Разные дни нельзя просто суммировать: один человек может встретиться в нескольких днях.

Частая ошибка — принять 10/18 за D7 retention. В этом примере числитель означает создание рабочего пространства, не возврат на седьмой день, и не задано окно. Если руководитель использует такую подмену как доказательство успеха онбординга, решение о релизе будет необоснованным. Другая ошибка — разбить 18 пользователей на слишком мелкие сегменты и интерпретировать колебание на 1–2 человека как эффект.

SELECT COUNT(*) AS signups,
       COUNT(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM events e WHERE e.user_id = u.user_id
           AND e.event_name = 'workspace_created'
       )) AS created_workspace
FROM users u;

SELECT CAST(event_time AS DATE) AS day,
       COUNT(DISTINCT user_id) AS active
FROM events WHERE event_name = 'app_open'
GROUP BY 1 ORDER BY 1;

4. Маркетинг: каналы, стоимость и качество

Маркетолог принимает решение раз в неделю: перераспределить бюджет между каналами или проверить качество лидов. Ему нужны 5–8 показателей с единой атрибуцией: расход за период, показы, клики, лиды, квалифицированные лиды, новые клиенты, стоимость привлечения клиента и доход или ценность когорты. Для каждой метрики запишите зерно: рекламное событие, пользователь, сделка; бюджет нельзя соединять с событиями по одному только каналу и затем суммировать по размноженным строкам.

Макет: сверху расходы и новые клиенты с явным периодом; посередине тенденция и таблица каналов с затратами, клиентами, CAC; внизу — качество по когортам. Без расходов и правил атрибуции CAC не существует. Учебные «Авиаперевозки» не содержат рекламных расходов, поэтому мы показываем структуру, а не фальшивые рубли. Ошибка — сортировать каналы по кликам и называть это окупаемостью: клик может не стать клиентом, а задержка конверсии изменит видимый период.

Даже при наличии расходов каналам нужен один метод атрибуции и одно окно. Если пользователь увидел объявление в понедельник, зарегистрировался в среду и купил в следующем месяце, отчёт по кликам за понедельник и отчёт по покупкам за неделю не образуют готовый CAC. Укажите, кому приписывается клиент, как долго ждут конверсию и пересчитывают ли прошлые периоды. Без этого два честных графика будут отвечать на разные вопросы. В макете оставьте место для числа клиентов и объёма затрат рядом с отношением: один высокий CAC на двух клиентах требует другой реакции, чем такой же показатель на тысячах.

5. Операционный: какие отклонения требуют реакции

Диспетчер или руководитель смены открывает страницу несколько раз в день. Его главный вопрос — что нарушилось и кого нужно предупредить. Потенциальные 5–8 мер: число запланированных рейсов, отменённые, доля отмен, задержки отправления более 30 минут, медиана задержки, число рейсов без обновлённого статуса, загрузка по направлениям, время последнего поступившего события. Для живой работы статус должен приходить быстро и иметь известную задержку. Статический учебный набор подходит только как исторический пример устройства.

В нашем недельном архиве 3 798 рейсов, 3 отменены; по дням запланировано 536, 545, 548, 550, 493, 568, 558. Показатель задержек более 30 минут надо считать только среди рейсов, для которых есть фактическое время отправления; строки без факта — отдельное качество данных, а не нулевая задержка. Если сортировать только по среднему, диспетчер пропустит критический рейс. Поэтому верх — очередь исключений, ниже — распределение и история; не наоборот.

6. Финансовый: сверка движения денег с планом

Финансовый директор смотрит страницу при закрытии периода и на встрече по бюджету. Ему нужны 5–8 определённых мер: начисленная выручка, поступившие платежи, возвраты, чистый денежный поток, валовая маржа, план по каждой мере, отклонение от плана, дебиторская задолженность. Эти величины могут относиться к разным датам и разным системам. Макет не должен выдавать сумму оформленных броней за одну из них.

Верх — план и факт по согласованной базе; середина — мост изменения от плана к факту с подписями причин; ниже — счета или направления с существенным отклонением и отметка о закрытии месяца. Схема ниже без чисел: учебные bookings не содержат весь бухгалтерский контур. Ошибка, которая приводит к неверному решению, — вычесть возвраты из денег за дату бронирования, когда возвраты относятся к другому периоду, а затем назвать результат маржой. Здесь нужна модель признания и сверка с учётом.

Финансовый обзор стоит строить только после согласования календаря закрытия. Операционный отчёт может обновляться ежедневно, а финансовый факт за месяц — уточняться после актов, возвратов и корректировок. На одном экране эти статусы надо показывать явно: «предварительно» или «закрыто». Иначе менеджер сравнит предварительный факт с утверждённым планом и объяснит расхождение, которое исчезнет при закрытии. Если план изменили в середине месяца, сохраните версию и автора изменения; текущая версия без истории не позволяет понять прежнее решение.

Где один дашборд заканчивается и начинается второй

Иногда руководитель просит «всё на одной странице» для удобства ссылки. Проверьте, принимает ли один человек одно решение по всем блокам в один момент. Если нет, сделайте обзорный экран с переходом в продажи, продукт и операции. Общая верхняя цифра может остаться, но каждая подробная страница должна иметь своего владельца, дату данных и правила доступа. Финансовые детали не обязаны открываться всей маркетинговой команде.

Не переносите макет буквально между компаниями. У авиаперевозок бронь, билет и рейс — три разных зерна; у SaaS будут аккаунт, подписка и событие. Сетка может быть похожей, расчёт и решения различаются. Удобный тест: сможет ли пользователь назвать после 30 секунд, где действие и где сверить число? Если нет, проблема не в цветовой теме.

Ошибки в примерах, которые дорого обходятся

Первая — использовать чужой набор KPI без определения «клиента», «выручки» и периода: страницы расходятся с отчётностью. Вторая — сложить DAU за семь дней и назвать WAU: повторяющиеся люди учитываются многократно. Третья — показать маркетинговый CAC без стоимости и атрибуции: канал кажется прибыльным на пустом знаменателе. Четвёртая — спрятать операционную тревогу ниже среднего значения: ответственный увидит её поздно. Пятая — подсветить отклонение цвета без численного порога и базы сравнения: красный не объяснит действие.

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

Частые вопросы и следующий шаг

Можно ли скачать готовый дашборд и подставить свои числа? Макет — да, определения и расчёты — нет: они зависят от ваших таблиц. Сколько метрик нужно руководителю? Столько, сколько связано с его решением; 5–8 — рабочая рамка примеров, не норматив. Чем продуктовый дашборд отличается от дашборда продаж? Единицей поведения пользователя и целевым действием вместо денежной сделки. Можно ли считать CAC по кликам? Нет, без числа приобретённых клиентов и затрат это другая мера.

Выберите один из шести случаев и опишите зерно, период и контрольную сумму. Затем набросайте зоны и выполните контрольный запрос к данным. Если SQL пока мешает проверить агрегат, потренируйтесь на SQL с нуля: в практическом дашборде ошибку JOIN лучше поймать до публикации.