Типы дашбордов и какие задачи они решают

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

Одна из проблем заключается в представлении сотрудников, что дашборд — это любая страница с данными и графиками. Редко люди задумываются, что на самом деле существуют разные типы дашбордов, которые служат разным целям и лучше решают конкретные задачи, а не все сразу. Это как в футбольной команде — все игроки вроде бы просто футболисты, но у каждого есть своя роль и позиция на поле, где он решает свою задачу лучшим образом.

Так же и с дашбордами. Нужно научиться определять цель дашборда и его тип. Если не сделать это с самого начала, то система теряет фокус: отчёты дублируют друг друга, пользователи путаются, а ценность BI снижается.

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

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

Обычно дашбордами перестают пользоваться по двум причинам:

  • дашбордов слишком много;
  • есть один «царь-дашборд», в котором собрана вся информация.

царь-дашборд

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

Такие отчёты быстро теряют актуальность: команды пользуются только самыми свежими дашбордами, а про старые со временем забывают. В системе из десятков отчётов трудно ориентироваться и находить нужную информацию, и ей перестают пользоваться. Аналитики, которые разрабатывали дашборды, теряют мотивацию и устают поддерживать десятки дашбордов.

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

В любом из этих сценариев проблема не в самих дашбордах, а в подходах к ним.

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

Типы дашбордов

В большинстве статей о BI-системах дашборды делят на четыре типа:

  • Стратегические дашборды дают быстрый обзор состояния компании и помогают принимать управленческие решения на уровне топ-менеджмента. Они отражают ключевые показатели и триггеры для действий и почти не содержат фильтры.

  • Операционные дашборды позволяют следить за изменениями данных в бизнесе. В них больше деталей и метрик по разным разрезам и в динамике. Основная аудитория — менеджеры среднего и нижнего уровня.

  • Тактические дашборды связывают стратегическое планирование и операционную деятельность. Они помогают принимать решения, влияющие на краткосрочные цели и стратегии.

  • Аналитические дашборды помогают искать и исследовать закономерности. Их используют аналитики внутри конкретных бизнес-подразделений, чтобы фиксировать отклонения, выявлять причины и формулировать выводы. Обычно в них множество фильтров и неочевидные пользовательские сценарии.

На мой взгляд, эта классификация некорректна. Она не даёт ответа на вопросы, как спроектировать дашборд и как он сочетается с другими типами. А ещё она не отражает устройство бизнес-процессов и оргструктуры.

Основные проблемы такой классификации:

  • Распределение по ролям. Предполагается, что для каждой роли существует свой тип дашборда: для СЕО — стратегический, для менеджера — операционный, для аналитика — аналитический. Но в реальности у каждой роли есть все типы задач, и сделать прямую связку «роль — дашборд» невозможно.

  • Привязка к детализации. Формально типы различаются уровнем обобщения. Стратегический дашборд показывает верхнеуровневые показатели, тактический — более подробные, операционный — ещё глубже. Но границы размыты, и трудно сказать, где заканчиваются данные одного дашборда и начинаются метрики другого.

  • Невозможность выстроить систему. Классификация не отвечает на важные вопросы: как спроектировать удобную систему дашбордов, сколько дашбордов должно быть, как они связаны между собой, когда появляется новый дашборд и зачем.

Эти типы не учитывают все нюансы и задачи, с которыми сталкиваются BI-аналитики. Поэтому я разработал собственный подход к выделению типов дашбордов.

Классификация дашбордов

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

Три принципа классификации:

  • Опора на задачи бизнеса. Типы дашбордов определяются не ролями пользователей, а конкретными потребностями компании, её организационной структурой, бизнес-процессами и продуктами.

  • Разнообразие форматов. Такие типы дашбордов подойдут офлайн-бизнесу, продуктовым командам в IT-компании и любому другому бизнесу.

  • Подсказки для проектирования. Каждый тип задаёт направление, как строить дашборд и какие элементы в нём будут уместны.

В этой типологии семь типов дашбордов:

  • overview-отчёт;
  • self-service-отчёт;
  • страница объекта управления;
  • алерты и рассылки;
  • аналитические инструменты;
  • отчёт по эксперименту;
  • дашборд по проектам (другое).

Overview-отчёт

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

Особенности overview-отчёта:

  • Часто повторяет структуру подразделения или компании. Если это подразделение, то обычно исследует ключевые показатели и срезы: например, по регионам, брендам или типам продуктов. Если это дашборд для компании целиком, то в нём отображается аналитика по подразделениям компании.
  • Важна хаб-функция: из overview можно кликнуть на какой-то блок и перейти в другие отчёты. Например, из отчёта видно, что просели продажи одного из брендов. Пользователь может нажать на бренд и перейти на страницу объекта управления по нему. Там видны детали: как менялась динамика по продуктам, в каких каналах упала выручка и какие регионы повлияли на результат.
  • Уровень детализации метрик показывает, где возникла проблема, но не отвечает на вопрос, почему именно она возникла. Чтобы разобраться в причинах, нужно перейти в другие дашборды.

В overview-отчёте должно быть не более 5–7 метрик, разложенных в разных разрезах. Если метрик будет больше, ориентироваться будет сложнее.

Дизайн-паттерны overview-отчёта:

  • Крупные смысловые блоки. Один блок показывает общие метрики, а остальные — распределение показателей по направлениям бизнеса или направлениям работы департамента.
  • Сочетание «KPI + спарклайн». KPI — это ключевой показатель, например выручка или количество заказов. Спарклайн — мини-график, который показывает динамику показателя за период. Такой график поможет заметить, есть ли отклонение от плана, как изменились метрики относительно прошлого периода.
  • Таблица с бар-чартами по основным разрезам (регион, приложение, тип доставки), где каждый столбец показывает основную метрику.
  • Таблица или бар-чарт с топом или антитопом по одному из более детализированных срезов (продукт, менеджер, товар), но без глубокой детализации до заказов, транзакций и сделок.
  • Оптимальный размер отчёта — одна страница. Дашборд должен полностью помещаться на экране, чтобы пользователь сразу видел все ключевые метрики.

Ниже примеры макетов, которые покажут общий принцип построения overview-отчётов.

Для целой компании оverview-отчёт может выглядеть так. Есть ключевые показатели по трём направлениям бизнеса с динамикой. Ниже — KPI по двум срезам: регионам и категориям товаров. Для детализации используются бар-чарты и таблица.

Макет overview-отчёта с разбивкой по основным направлениям: продажи, маркетинг, логистика
Макет overview-отчёта с разбивкой по основным направлениям: продажи, маркетинг, логистика

Таким может быть overview-отчёт для одного из подразделений. Сверху блок с ключевыми метриками и спарклайнами, которые показывают текущий уровень и динамику показателей. Есть показатели по срезам и топ клиентов с разбивкой по продажам, скидкам и прибыли.

Макет overview-отчёта для подразделения
Макет overview-отчёта для подразделения

Это другой overview-отчёт для подразделения. Здесь много основных метрик, поэтому их можно расположить вертикально. Так показатели читаются проще, чем в одной длинной строке. Справа — распределение показателей по регионам с бар-чартами и картой, ниже — топ клиентов в формате таблицы.

Макет overview-отчёта для подразделения с большим количеством основных метрик
Макет overview-отчёта для подразделения с большим количеством основных метрик

Макет overview-отчёта может выглядеть иначе, всё зависит от задачи клиента и контекста его бизнеса. Расскажем о реальных кейсах и отчётах, которые мы разработали.

Например, так мы сделали overview-отчёт для отдела работы с клиентами в консалтинговой компании. Сверху находятся основные метрики в две строки с графиками по неделям. Здесь есть ключевые показатели по продажам: клиенты, счета, LTV, NPS и динамика этих метрик. Ниже — детальная информация по каждому менеджеру. Так можно отследить актуальное состояние работы отдела, а если есть вопросы, то перейти к детализации по конкретному менеджеру.

Overview-отчёт для отдела работы с клиентами в консалтинговой компании
Overview-отчёт для отдела работы с клиентами в консалтинговой компании

Ещё один пример — overview-отчёт для офиса оказания услуг в НКО. Верхний блок с крупными KPI и мини-графиками показывает динамику количества клиентов и оказанных услуг. Таблицы ниже работают как точки входа для фильтрации и анализа по основным срезам: филиалу, специалисту и типу услуг.

Overview-отчёт для офиса оказания услуг в НКО
Overview-отчёт для офиса оказания услуг в НКО

Self-service-отчёты

Self-service-отчёты позволяют пользователям самостоятельно работать с данными. В отличие от overview-отчёта, здесь у сотрудника есть конкретный запрос, и он сам формирует ответ, выбирая нужные параметры.

На мой взгляд, self-service- и overview-отчёты — дашборды, которые нужно делать в первую очередь. Это основа операционной работы. Аналитиков часто отвлекают от основной работы мелкими ad-hoc-запросами, и им приходится делать запросы в SQL. Дашборды этих двух типов освобождают аналитиков от этой рутины и дают бизнес-заказчику 90% нужных данных. Если нужно выбрать, с чего начать, начните с них.

Особенности self-service-отчётов:

  • В интерфейсе много фильтров и гибких настроек. Можно выбрать период, регион, сегмент, категорию товаров и сразу получить нужные данные.
  • Отчёты содержат большой набор метрик и срезов. Пользователь сам конфигурирует отчёт, набирая группировки и фильтры. В отличие от других типов, где настройки закладывает аналитик, здесь эта работа передаётся пользователю.
  • Часто в отчётах есть возможность скачать результат или настроить регулярную рассылку, чтобы не повторять одни и те же действия вручную.

Иногда self-service-отчёт — это источник данных, к которому пользователь подключается напрямую. Если он умеет работать с BI-инструментом, то может сам собрать таблицу или визуализацию.

Self-service-отчёты не должны заменять операционную отчётность. Они нужны для разовых запросов и выгрузок, но не для регулярного мониторинга. Если сотрудник каждый день выгружает один и тот же отчёт и строит графики вручную — это сигнал, что систему используют неправильно.

Дизайн-паттерны self-service-отчётов:

  • Колонка фильтров, сгруппированных в блоки. Если фильтры полностью совпадают по значениям с колонками таблицы, то их можно поставить сверху, как в Excel.
  • Таблица с результатами работы фильтров или один-два графика.
  • Оптимальный размер отчёта — одна страница.

Отчёт похож на поисковик билетов — вы задаёте критерии и получаете результат. Формат такого поиска можно настроить по-разному. Например, фильтры расположить слева, а данные справа.

Макет self-service-отчёта с фильтрами слева
Макет self-service-отчёта с фильтрами слева

Другой вариант — расположить фильтры над таблицей, тогда данные будут занимать больше места.

Макет self-service-отчёта с фильтрами сверху
Макет self-service-отчёта с фильтрами сверху

Формат данных на выходе тоже настраивается. Например, это может быть воронка и динамика конверсий по шагам.

Макет self-service-отчёта с данными в формате воронки и графика
Макет self-service-отчёта с данными в формате воронки и графика

Ниже — пример self-service-отчёта по работе менеджеров продаж. Основное пространство занимает таблица со всеми лидами. Здесь отображаются ключевые поля: ID лида, категория, менеджер, группа каналов, дата создания, статус, тип оплаты и сумма букинга. В левой панели находятся фильтры по основным атрибутам: группа каналов, источник, тип оплаты, категория, статус, дата создания. Такой отчёт позволяет гибко формировать выборку и экспортировать данные.

Self-service-отчёт по работе менеджеров продаж
Self-service-отчёт по работе менеджеров продаж

Страница объектов управления

Страницы объектов управления — это приборная панель для управления конкретной частью бизнеса: продуктом, брендом, подразделением или процессом. Дашборд нужен там, где у роли есть чёткая зона ответственности. Обычно у таких сотрудников в названии должности есть «менеджер по…» или «руководитель направления по…». Менеджер продукта отвечает за конкретный продукт, менеджер региона — за регион, менеджер по продажам — за группу клиентов или процесс продаж. Страницы объектов управления объединяют все данные, которые необходимы этим ролям для управления зоной ответственности.

Особенности страниц объектов управления:

  • Это «служба одного окна» для роли, которая отвечает за объект управления. Например, у менеджера продукта или региона есть свой дашборд, где он может найти все нужные данные, не переключаясь на другие источники.
  • Дашборд может быть длинным и детализированным. Владельцу объекта управления нужны разные показатели для принятия решений, и все они собираются в одном месте.

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

  • Структура дашборда выстраивается от общего обзора к последовательному углублению в детали: от динамики метрик до таблиц с детальными срезами данных, например заказами, транзакциями и товарами.
  • Страницы объектов управления связаны с overview-отчётами. Часто срезы в overview являются объектами управления менеджера. В этом случае хорошо работает связка дашбордов: пользователь кликает на показатель в overview-отчёте и попадает на страницу конкретного бренда, региона или процесса с подробной детализацией.

В отличие от overview-отчёта, страница объекта управления должна показывать, почему произошло изменение метрик.

  • Когда пользователь заходит на дашборд, отчёт автоматически фильтруется по релевантному для сотрудника срезу. Часто встроен RLS-доступ.
  • Отчёт содержит ссылки на сторонние системы, где пользователь может изменить параметры процесса, например на рекламный кабинет с настройкой бюджета кампании. Дашборд также может содержать элементы, выполняющие действия: кнопки, обратная запись данных в базу данных и не только.

Дизайн-паттерны страниц объектов управления:

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

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

Макет страницы объекта управления для регионального менеджера сети
Макет страницы объекта управления для регионального менеджера сети

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

Страница объекта управления для менеджера продаж по лидам
Страница объекта управления для менеджера продаж по лидам

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

Страница объекта управления для менеджера товарной группы на маркетплейсе
Страница объекта управления для менеджера товарной группы на маркетплейсе

Алерты и рассылки

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

Алерты и рассылки редко относят к дашбордам, потому что в них почти нет графиков и визуальных элементов. Но именно они позволяют бизнесу реагировать на проблемы быстро, а иногда ещё до того, как последствия станут заметны в цифрах.

Почему-то многие воспринимают алерты как что-то второстепенное: графиков нет, значит, это не так важно. На мой взгляд, алерты и рассылки — критичная часть системы отчётности, и про них не стоит забывать. С ними вы сразу узнаете, что конверсия упала на 30% или срок обработки заявок превысил норму, и не придётся искать данные вручную.

Особенности алертов и рассылок:

  • Алерты могут быть дашбордом, а могут приходить как сообщение в мессенджере, письмо, СМС или звонок.
  • Для алертов нужны каталоги и реестры, как и для остальных дашбордов. Важно вести реестр в том же месте, где хранятся остальные отчёты.
  • Хорошо сделанный алерт указывает, где именно произошла проблема. Сообщение «продажи упали» бесполезно, если не уточняется, в каком сегменте это произошло. Идеально, когда алерт сразу подсказывает направление для анализа.

Дизайн-паттерны алертов в формате дашборда:

  • Таблица или набор плиток с метриками, где подсвечиваются отклонения, требующие внимания.
  • Подсветки «хорошо-плохо». Простая визуализация, которая понятна пользователю. Обычно применяют зелёный цвет для метрик в пределах нормы и красный, если есть отклонения.
  • Минималистичный и простой дизайн, который легко считывается с телефона или монитора в кабинете.

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

Макет алертов с цветовой подсветкой
Макет алертов с цветовой подсветкой

Например, так выглядит алерт для менеджеров по продажам. Это таблица с ключевыми атрибутами лида, включая ID, статус, менеджера, категорию, дату создания и количество дней без контакта. Основная метрика — количество дней без контакта. Показатель подсвечивается градиентной заливкой: чем дольше клиент остаётся без ответа, тем насыщеннее оттенок красного. Такой приём позволяет мгновенно выделить «просроченные» лиды и приоритизировать работу.

Алерты для менеджеров по продажам
Алерты для менеджеров по продажам

Аналитические инструменты

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

В overview-отчёте или на странице объектов управления показатели заранее определены, а в аналитических инструментах пользователь сам формирует запрос. В отличие от self-service-отчётов в них больше графиков, интерактивности и сложности в освоении.

Аналитические инструменты в виде дашбордов стоит создавать, если в компании есть доменные эксперты, которые глубоко разбираются в теме и работают с данными, но не умеют использовать стандартные инструменты аналитиков данных (SQL, Python, Jupyter® Notebook). Это могут быть маркетологи, финансовые аналитики, врачи или специалисты в других узких областях. С помощью аналитических инструментов они смогут исследовать данные без программирования.

Многим кажется, что дашборды нужны для глубокой аналитики, поэтому делают как можно больше «аналитических» отчётов. На деле такой формат нужен редко. Иначе всё идёт по похожему сценарию. Аналитики собирают сложный дашборд с кучей фильтров и говорят: «Вот инструменты, дальше сами исследуйте». Пользователю сложно в этом разобраться, и он перестаёт заходить в отчёт. В итоге про дашборд просто забывают. Это ещё раз показывает, что BI-систему воспринимают как инструмент для анализа, а не операционного управления.

Особенности аналитических инструментов:

  • Строятся на сложных визуализациях и позволяют работать с данными в разных разрезах и с глубокой детализацией. Такой подход отличается от подхода overview-отчёта или страниц объектов управления, где визуализация предельно упрощена ради скорости восприятия.
  • Интерфейс таких инструментов насыщенный, состоит из фильтров, переключателей, вариантов детализации. Пользователь сам задаёт, что именно он хочет исследовать, поэтому нужен высокий уровень интерактивности.
  • Эти инструменты нужны нечасто, а их разработка требует специальных подходов. У таких отчётов почти никогда нет чёткой бизнес-задачи, поэтому дизайн и проектирование ближе к исследовательскому процессу: нужно закладывать больше гибкости и предусматривать, что пользователь пойдёт по разным сценариям.
  • Аналитические инструменты в компании могут быть и не только в формате дашбордов. Чаще всего это отдельные продукты: Jupyter Notebook, Yandex DataSphere, Google Colab или просто Excel. BI-инструменты тоже пытаются закрыть этот запрос, предлагая онлайн-редактирование дашбордов в браузере для сотрудников без технической подготовки. Но такие решения редко приживаются в реальной практике.

Для меня аналитический инструмент — это скорее что-то, что стоит рядом с BI-системой, но не находится внутри неё. В идеале у компании должна быть отчётность для мониторинга и отдельные инструменты для аналитиков, которые могут эти данные исследовать. А вот делать именно аналитический дашборд приходится редко, только для доменных экспертов.

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

Дизайн-паттерны аналитических инструментов:

  • Большое количество фильтро-графиков по срезам. Часто это небольшие бар-чарты, но могут быть и другие форматы.
  • Есть большой аналитический график. Это центр инструмента, в котором отражаются сразу несколько срезов и метрик.
  • Есть вспомогательные графики. Они позволяют понять, какой срез стоит посмотреть для ответа на вопрос.
  • Графики связаны между собой: при клике или наведении на один график подсвечиваются связанные точки на других. Так проще находить нужные срезы и выбросы для гипотез.

Это пример аналитического инструмента. Слева — главный аналитический график, где на осях указаны две ключевые метрики, а размер кружка показывает третью. Справа — вспомогательные графики: динамика по регионам, несколько бар-чартов по срезам.

Макет аналитических инструментов
Макет аналитических инструментов

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

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

Такой дашборд позволяет сравнить каналы и найти зоны роста по соотношению затрат, объёмов и потерь, с упором на быстрый анализ аномалий.

Аналитический инструмент для сравнения рекламных кампаний и каналов
Аналитический инструмент для сравнения рекламных кампаний и каналов

Отчёт по эксперименту

Отдельной задачей в компании стоит проверка гипотез и изменений. Дашборды по экспериментам подойдут, когда бизнесу или продуктовой команде нужно принять решение по результатам исследования. Чаще всего это A/B-тесты, запуск новых функций или проверка изменений в продукте.

Особенности отчётов по эксперименту:

  • Дашборд напоминает аналитическую записку. В нём должно быть текстовое описание эксперимента: что именно проверялось, какие методы использовались и к каким результатам и выводам пришли.
  • В отчёте нужно подчёркивать статистически значимые результаты. Пользователю важно не погружаться в расчёты, а сразу видеть, что именно сработало хорошо, а что нет. Результаты эксперимента можно сразу подсветить зелёным или красным цветом.
  • Дашборд должен делиться на две части: для бизнес-пользователей и для аналитиков. Бизнесовая часть должна быть максимально простой и сразу вести к выводу: «Этот вариант хуже, его не стоит использовать». Аналитическая часть нужна для экспертов, которые проверяют корректность выводов, они изучают сходимость, детальные графики, статистику, p-value и результаты других методов анализа.
  • Дашборд для экспериментов помогает принять решение, стоит ли продолжать эксперимент, внедрять результат или отклонять гипотезу. Хороший дашборд не показывает все данные подряд, а фокусирует внимание на ключевых результатах.

Дизайн-паттерны отчётов по эксперименту:

  • Текстовые блоки. Слева или справа — описание эксперимента, вывод о результатах с пояснением и обоснованием.
  • Таблица со всеми основными метриками эксперимента, где подсвечены статистически значимые отклонения.
  • Таблица со вспомогательными метриками, где собраны показатели со статистически значимыми отклонениями.
  • Подсветка «хорошо-плохо». Визуализация может напоминать алерты: важно подсвечивать конкретные метрики, на которые влияет эксперимент.
  • Линейные графики. В них отображается ход эксперимента по дням или неделям.

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

Макет отчёта по эксперименту
Макет отчёта по эксперименту

Ниже — пример отчёта по тестированию нового блюда Mario 2.0. Дашборд создан для оценки коммерческих и качественных показателей блюда по сравнению с текущими позициями меню. В верхнем левом блоке — ключевые параметры теста: название блюда, даты проведения эксперимента, меню и тип продаж. Основная часть отчёта состоит из двух метрик — GMV (выручка) и CSAT (оценка удовлетворённости клиентов). Метрики выведены в двух форматах: сравнительных бар-чартов с базовым блюдом и динамических линий на временной шкале. Дополнительно есть блок с результатами, где текстом описан вывод: новая рецептура продаётся хуже, её рейтинг ниже остальных. Следовательно, блюдо не стоит внедрять. Снизу есть детальная таблица, поясняющая ход эксперимента.

Отчёт по эксперименту в ресторане
Отчёт по эксперименту в ресторане

Дашборд по проектам

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

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

Эти дашборды, на мой взгляд, самые бессистемные. Вроде бы это дашборд, но каждый график отвечает на отдельный вопрос, и непонятно, почему все эти показатели собраны вместе. Как будто в одном плейлисте встречаются Меладзе и AC/DC.

Особенности дашбордов по направлениям и проектам:

  • Каждый график отвечает на отдельный конкретный вопрос.
  • В одном дашборде по проекту могут встречаться элементы разных типов: блок overview-отчёта, часть со страницей объектов управления или аналитический модуль. Это нормально для временных решений, но такие дашборды не должны становиться основой корпоративной отчётности.

Внутри одного дашборда могут быть блоки из разных типов дашбордов. Важно, чтобы вы понимали, за что отвечает каждый из блоков. По возможности разделяйте дашборд на несколько, но если графиков немного, можете составить один.

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

Макет дашборда по направлению
Макет дашборда по направлению

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

Дашборд по направлениям для исследования прибыльности
Дашборд по направлениям для исследования прибыльности

Главное о типах дашбордов и их задачах

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

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

Система отчётности из разных типов дашбордов
Система отчётности из разных типов дашбордов

Чтобы выстроить эффективную систему дашбордов, следуйте правилам:

  • Основные типы дашбордов распределяются по задачам: overview-отчёт даёт общий обзор, страницы объектов управления помогают владельцам зон ответственности, алерты сигнализируют об отклонениях, аналитические инструменты и отчёты по экспериментам поддерживают исследования и изменения, self-service закрывает разовые запросы, а проектные дашборды решают временные задачи.
  • Для проверки гипотез и поиска инсайтов BI-дашбордов недостаточно. Нужны отдельные аналитические инструменты, которые дополняют систему, но не смешиваются с ней.
  • Система дашбордов строится как фрактал: в каждом отделе повторяется похожая структура, но она содержит разные типы дашбордов. Руководители видят картину в целом, менеджеры управляют своим направлением, аналитики исследуют данные, а бизнес получает инструмент для быстрых решений.
  • Используйте классификацию и примеры макетов, чтобы выстроить с бизнес-заказчиками единое понимание того, что можно ожидать от дашбордов. Если все понимают разницу между типами дашбордов, то гораздо проще формировать план работ и обсуждать создание дашбордов.

Следующий шаг — перейти от понимания типов дашбордов к системному проектированию. Для этого нужны фреймворки вроде Dashboard Map и Dashboard Canvas, которые помогают собрать и проработать архитектуру дашбордов. О них мы расскажем в следующих главах.