Привет! Меня зовут Михаил Измайлов, я лид по аналитике данных в команде лояльности MAGNIT OMNI — бизнес‑группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.
Дашбордами в современных технологических компаниях уже никого не удивить, однако хорошо структурированную, актуальную и стабильную систему BI‑отчетов можно встретить далеко не всегда.
Какие шаги предпринять, чтобы дашбординг не стал набором хаотично разбросанных отчетов, а был хорошо настроенным инструментом для бизнеса? Попробуем ответить на этот вопрос в статье, а в конце поделимся структурированным чек‑листом с расставленными приоритетами, который можно унести с собой как готовый артефакт для самопроверки — что уже работает, а что нужно дотюнить.
Диагностика
Сперва попробуем понять, какие бывают частые симптомы приболевшего дашбординга. Глобально можно разделить боли на две группы: от пользователей и от аналитиков‑разработчиков.
Пользователи | Аналитики |
Постоянное отсутствие необходимых метрик и разрезов в отчетах: систематическое отсутствие нужных данных, приводящее к потере интереса к дашбордам | Плохо сформулированные запросы от бизнеса: симптом отсутствия процесса по сбору и анализу бизнес‑требований к дашбордам |
Неудобство использования и долгая загрузка отчетов: бизнесу комфортнее запросить очередную выгрузку у аналитиков напрямую, чем использовать дашборд | Отсутствие стандартов/правил для построения витин и дашбордов: чрезмерная свобода, часто приводящая к неудачным решениям по дата пайплайнам и визуализации |
Недоверие к данным в дашбордах: усталость от постоянных сверок и сомнения в правильности результатов | Непонимание приоритетов разработки: залетающие вводные от разных заказчиков и отсутствие единого процесса согласования |
Непонимание ответственных за разработку и сроки по дашбордам: непрозрачные и несогласованные процессы между аналитикой и бизнесом | Отсутствие конкретных планов по техническому и организационному развитию дашбордов: непонимание, как перейти от отдельных отчетов к единому продукту и нужно ли вообще в это инвестировать время |
Сложности с поиском нужных дашбордов: выискивание ссылок на дашборды через внутреннюю сеть контактов также является плохим признаком |
Все эти боли неслучайны. За каждой из них стоит системная проблема: где‑то нет процесса, где‑то — единой навигации, где‑то — проверок качества. Мы свели их в шесть фреймов, которые и лягут в основу чек‑листа.
настройка процессов взаимодействия с пользователями
базовая гигиена дашбордов
создание единой точки входа и навигации
скорость и стабильность доставки данных
качество данных и доверие к метрикам
процессы развития
Настройка процессов взаимодействия с пользователями
Перед созданием предметного workflow с заказчиками отчетов необходимо определиться с тем, кто является нашими пользователями. Будем использовать статистику просмотров, соберем перечень заказчиков через текущих исполнителей дашбордов и «пробежимся» по внутренним чатам.
Далее стоит сегментировать аудиторию, чтобы понять, с какими группами пользователей мы будем взаимодействовать, от этого будут зависеть следующие компоненты настройки.
По нашему опыту, хорошо работает, и часто применяется иерархичная сегментация.
Сегмент | Характеристика |
топ‑менеджмент | смотрят редко, но метко более склонны к быстрому просмотру ключевых OKR/KPI для контроля общего прогресса и здоровья |
управленцы стримов и продуктов | смотрят регулярно мониторят как топ‑метрики, так и более детальную аналитику (воронки, метрики по когортам и так далее) нацелены на извлечение инсайтов, которые можно превратить в конкретные шаги для улучшений |
линейные сотрудники | могут использовать с разной частотой и для разных целей частая особенность — использование дашбордов как интерфейсов получения данных для дальнейшей обработки и аналитики на своей стороне. Например, выгрузка данных с чартов в Excel |
Отдельным сегментом могут быть сами аналитики, которые используют дашборды для мониторинга метрик и проверки быстрых гипотез. В некоторых случаях, можно выделить сегмент внешних пользователей, например, партнеры, выполняющие услуги по согласованным KPI.
Далее можно выстроить стандартный процесс разработки/доработки дашборда. Мы используем достаточно простой подход из нескольких шагов.
В рамках настройки процессов с пользователями особое внимание стоит уделить этапам уточнения и согласования бизнес‑требований. Мы используем компоненты фреймворка Dashboard Canvas, в частности, хотел бы остановиться на двух частях: подготовка вопросов для интервью с заказчиками и анализ результатов интервью.
При составлении списка вопросов стоит учитывать сегментацию пользователей, которую мы упомянули выше. В зависимости от уровня могут быть различные уточняющие вопросы: например, для топ‑менеджеров можно ввести вопросы про связь метрик с общими корпоративными целями, а для линейных специалистов — про необходимость создание удобных форм для self‑service.
В нашем стандартном процессе обычно от 10 до 12 вопросов, цели которых можно сгруппировать так:
получить вводные по желаемому инструменту и целям его создания;
понять текущий принцип решения задачи без дашборда;
сориентироваться по целевой аудитории отчета и паттернам использования;
определить возможные бизнес‑решения на выходе из аналитики в дашборде;
определить сроки и приоритеты.
Для ускорения консолидации и анализа бизнес‑требований мы размещаем ответы на вопросы сразу в структуру канваса, а для метрик и срезов заготовили чек‑боксы «быстрого прокликивания», разместив туда наиболее часто запрашиваемые параметры.
Заполненный артефакт по бизнес‑требованиям прикладывается к таску в Jira. Наша команда взаимодействует одновременно с несколькими бизнес‑стримами, поэтому на случай возникновения конфликта приоритетов предусмотрены еженедельные совместные планирования с ключевыми заказчиками.
Справедливости ради, скажу, что полноценный подход с канвасом, на мой взгляд, оправдан при создании полностью новых дашбордов, где зачастую необходимо поднять конкретику из расплывчатых ожиданий. Для небольших доработок можно использовать более простые варианты, например, через описание внутри Jira‑таски.
Базовая гигиена дашбордов
На что обратить внимание в первую очередь в самих дашбордах?
Мы в команде сформировали перечень принципов «базовой гигиены», которые решают ряд часто встречающихся проблем у пользователей.
Указание ответственного за дашборд‑аналитика и его контакты: пользователю должно быть понятно, к кому идти в случае вопросов.
Индикатор с датой (если нужно датой/временем) актуальности данных: важно отображать именно «свежесть» самих данных, а не лог обновления дашборда.
Наличие основной информации по дашборду:
описание предназначения инструмента, какую задачу он решает, какой периметр покрывает;
описание метрик и логики их расчета (или ссылка на документацию/дата‑каталог);
описание основных разрезов/фильтров (или ссылка на документацию/дата‑каталог);
указание гранулярности и глубины данных;
указание частоты обновления.
Информация из третьего пункта может быть размещена в самом дашборде или быть прикреплена в качестве ссылки на документированный «паспорт» дашборда.
Суть правил базовой гигиены: обеспечить пользователя базовой информацией о дашборде, его периметре и актуальности.
Когда «паспортная» часть дашбордов настроена, переходим к визуальной эргономике. Мы не ставим целью написать исчерпывающий гайд по визуализации — их достаточно много в сети. Но зафиксируем пять правил, которые на практике дают 80% эффекта:
Понятные заголовки чартов и нэйминги осей (понимаем метрику, единицы измерения и разрезы)
Адекватный масштаб чартов и их расстановка на дашборде (читаемые, расположенные от общих KPI к разрезам и детализации)
Лаконичная и не пестрая цветовая палитра (более яркая подсветка для детекции аномалий, выделения позитивных/негативных трендов)
Отсутствие грязи в подписях значений (если «столбики» или «пирог» становятся перегруженными, замените на таблицу или несколько отдельных виджетов).
В первую очередь делайте выбор в сторону более простых и читаемых визуальных элементов (думайте о прозрачности для пользователя).
Пример тюнинга чарта в стиле «дешево и сердито»:
Отредактированный чарт с исправлениями:
меняем столбцы на линии для более явного выделения трендов во времени;
выставляем контрастные цвета, чтобы без сложностей отличать категории;
обогащаем название чарта и явно указываем единицы измерения по осям;
убираем подписи ввиду слишком большого количества точек, но оставляем горизонтальную сетку с адекватным шагом.
Для лечения боли с отсутствием стандартов мы зафиксировали правила базовой гигиены и расширенный перечень рекомендаций по настройке виджетов как чек‑лист в документации.
Создание единой точки входа и навигации
Как упростить поиск дашбордов, если их стало достаточно много?
Классическая ситуация: не успели оглянуться, а количество дашбордов уже перевалило за 15–20 и более штук. Все у всех спрашивают ссылки, пытаются найти что‑то в Сonfluence, вспомнить, как звали того классного парня, который показывал тот клевый дашборд на демо.
Хорошей практикой для систематизации перечня отчетов является создание единой стартовой страницы. У себя мы называем ее Welcome Page. Оформить ее можно различными способами, начиная от создания простой страницы со ссылками в документации, заканчивая детализированными лэндинг‑страницами с графикой и прочим. Мы выбрали для себя комбинированный вариант — оформление стартовой странички непосредственно в нашем BI с дополнительной документацией в Confluence.
В DataLens в табличных формах указаны названия дашбордов со встроенными гиперссылками, к каждому дашборду дается краткое описание, чтобы была сразу понятна тематика. Сами табличные формы разбиты на логические бизнесовые блоки:
верхнеуровневые отчеты с ключевыми метриками вертикали (например, MTU метрики лояльности);
отчеты по конкретным механикам/продуктам (например: любимые категории, подписка и так далее);
дополнительные/вспомогательные отчеты.
Вверху на стартовой странице также дается ряд полезных ссылок для пользователей:
документация в Сonfluence: там содержится больше предметной и технической специфики по каждому инструменту, линки на сборку в gitlab и так далее;
инструкция по получению доступа: можно пройти и поделиться с коллегой‑новобранцем;
линк на быстрое создание задачи в Jira по темплейту: от идеи к заявке, мы получим авто‑аллерт и рассмотрим задачу на ближайшем планировании;
линк на нашу орг.структуру: если требуется найти нужного человека или команду.
Таким образом, пользователям достаточно иметь ссылку на одну стартовую страницу с навигацией по отчетам и вспомогательным материалам вместо поиска в разных местах.
Скорость и стабильность доставки данных
Ни один даже самый красивый и четко настроенный дашборд не будет приносить пользы, если данные в него поступают несвоевременно, а скорость загрузки чартов оставляет желать лучшего.
Прежде чем определить пункты для диагностики и оптимизации, стоит кратко рассказать о нашем стэке и его особенностях.
DataLens работает на прямом подключение к базе данных, поэтому у нас повышенные требования к качеству витрин и скорости их загрузки.
В качестве хранилища используется GreenPlum, постепенно переходим на Trino.
Автоматизация сборки, проверок качества данных и алертингов реализуются через Airflow.
Пользователь, открывающий дашборд, увидит актуальные метрики, если успешно сработают два компонента: загрузка витрин данных в DWH и быстрая загрузка чартов в самих дашбордах.
Скорость загрузки витрин в DWH зависит от множества факторов, включая архитектуру и модель данных, поэтому детальный список для диагностики и оптимизации может отличаться. Ниже я собрал несколько универсальных пунктов, которые помогли нам в отладке загрузки и не сильно привязаны к конкретному стэку.
Определение SLA загрузки: конкретизируем ожидания по таймингу, например, витрины по бизнес‑критичным отчетам должны быть собраны к 10:00 за D-1.
Контроль скорости загрузки через мониторинг: логируем время выполнения DAG‑ов и записываем в хранилище, далее анализируем на дашборде мониторинга, понимаем, по каким потокам требуется оптимизация.
Алертинги по падениям: отправляем сообщения в корпоративный мессенджер через вебхук с помощью Airflow callbacks, в сообщение сразу тэгируется ответственный аналитик и дается прямой линк на логи для быстрого разбора падения.
Использование витрин среднего слоя: например, для расчета клиентской аналитики вместо сырых чеков используйте предрассчитанную таблицу с группировкой «клиент‑месяц» и набором нужных фичей, ключевых измерений. Так запросы в пайплайнах сборки итоговых таблиц для дашбордов станут легче в десятки раз.
Итак, на уровне хранилища мы обеспечили стабильную и быструю загрузку витрин. Переходим к оптимизации загрузки чартов в самом BI. Есть некоторые фишки, которые помогут сделать отстройку визуализаций более быстрой:
Перенос основной логики расчетов в материализованные таблицы: минимизируем сложные вычисления на стороне BI, явно объявляем типы данных в витрине, подключаем агрегированные таблицы, не используем сырье.
Контроль за гранулярностью: например, если метрики на странице должны быть сгруппированы до месяца, нет смысла подключать витрину с гранулярностью до дня.
Создание отдельных таблиц‑справочников для фильтров: для больших датасетов неэффективно создавать селекторы из основной витрины с данными, так как загрузка атрибутов может занимать большое время за счет выполнения distinct по полю.
Дефолтная загрузка страниц с заданными параметрами: например, если данных уже достаточно много, можно дефолтно загружать страницу с зафиксированным фильтром.
Логическое разделение витрин и страниц с разной глубиной аналитики.
Контроль скорости загрузки: в Datalens мы используем специальную функцию инспектора, показывающую скорость загрузки, а в качестве внутренних таргетов взяли лимит в 5 секунд для базовых чартов и 10 секунд для сложных визуализаций.
Качество данных и доверие к метрикам
Доверие пользователей к данным — это одна из ключевых деталей пазла настройки системы дашбординга. Для повышения уровня доверия нам требуется два компонента:
проверка качества входных данных;
обеспечение прозрачной информации по методологии для пользователей.
Проверки качества данных — очень обширная тема. Тут мы находимся в фазе активного развития. На текущий момент у нас есть проверки на стороне DWH, которые проверяют получили ли мы все данные из сервисов в хранилище. На стороне аналитики для наших пайплайнов мы запускаем два типа проверок, которые смотрят на адекватность данных:
проверка максимальной даты: сверка максимальной бизнес даты данных в источнике с ожидаемой, например, получение данных в текущие сутки D за период D-1
проверка полноты загруженных строк: детекция аномалий методом Z‑score, где на вход подается размер окна для скользящих статистик и трэшхолд отклонения (параметры можно настроить отдельно по каждой таблице‑источнику через.yaml конфиг)
Сейчас мы настраиваем чувствительность проверок, работаем с задачей отличия реальных аномалий от взрывов/просадок бизнес‑метрик, пробуем различные методики, поэтому результаты проверок на временном ряду не останавливают сборки витрин по расписанию, но выводятся в отдельный дашборд с мониторингом для контроля и проверки «красных» источников.
Обеспечение прозрачной информации по методологии для пользователей‑ это, пожалуй, один из важнейших пунктов, который часто оказывается забытым. Непосредственно для дашбордов мы работаем с фиксацией методологий сейчас следующим образом:
в ключевых больших дашбордах описание всех метрик и срезов дается непосредственно в отчете на странице «описание» или у виджетов;
в случае сложных расчетов или нетипичного отображения метрики всегда дается примечание или подсказка у виджета;
в некоторых случаях, например для описания сегментов пользователей, используется ссылка из дашборда на документацию в confluence.
Такой подход достаточно удобен для пользователей, так как они видят всю информацию сразу в дашбордах с минимальными переходами, однако такую структуру сложно поддерживать, так‑как приходится корректировать определения вручную, проверять их актуальность по дашбордам.
Ключевые метрики и логика их расчета внесены в дата‑каталог (используем OpenMetadata), настроена их связь с документацией в Confluence, но пока не настроена связь с дашбордами.
Целевым решением мы видим:
использование дата‑каталога как единой точки дистрибуции логики расчета метрик;
обеспечение прямой связи между метриками в дашборде и дата‑каталогом.
Кстати, по этой теме недавно выходила техническая статья от нашего коллеги из смежной вертикали: линк на статью
Процессы развития
Итак, мы научились собирать и обрабатывать запросы пользователей, настраивать базовую гигиену и визуализацию, сделали единую точку входа, позанимались стабилизацией загрузки витрин и повысили доверие к данным.
Можем ли мы остановиться на этом? Нет. Все перечисленное — это база, которая решает текущие боли, но не даёт ответа на вопрос: «А куда мы движемся дальше?» Чтобы дашбординг стал не просто набором отчётов, а полноценным аналитическим продуктом, нужны дополнительные процессы.
Мы разделили их на три группы:
развитие взаимодействия с пользователями — как мы общаемся и собираем обратную связь;
контроль внутренних метрик — как измеряем здоровье системы;
проактивное планирование — как смотрим в будущее, а не только чиним текущее.
1. Развитие взаимодействия с пользователями
Регулярные опросы
Раз в квартал мы отправляем пользователям форму с вопросами по блокам: достаточность и актуальность данных, удобство функционала, скорость загрузки, качество взаимодействия с BI‑командой.
Плюсы:
отслеживаем динамику удовлетворённости;
превращаем боли в пункты роад‑мапа;
используем позитивную обратную связь для мотивации команды.
Минусы:
пользователей приходится «подпинывать» — конверсия в опросы невысокая;
Демо
Делим демо на два типа:
по крупным доработкам — для конкретных заказчиков, глубоко в бизнес‑специфику;
обзорные — для широкой аудитории, показываем общую картину и новые возможности.
Плюсы:
показываем «товар лицом» в прямом эфире;
демонстрируем нетипичные фичи, улучшая пользовательский опыт;
в Q&A‑сессии решаем часть вопросов на месте.
Минусы:
обзорные демо требуют серьёзной подготовки и продуманной структуры
Дайджесты
Более интровертный вариант — презентация, где каждый слайд ёмко описывает последние изменения в конкретном дашборде или системе в целом.
Плюсы:
артефакт можно изучать в любое время и с любого устройства, пересылать коллегам;
при наличии шаблона готовится быстро;
не нужно искать слоты для встреч.
Минусы:
нет живого общения — обратной связи может не быть совсем, что иногда настораживает
2. Контроль внутренних метрик
Мониторинг пользовательской активности
Большинство BI‑систем из коробки отслеживают активность пользователей. Можно использовать классические метрики из продуктовой аналитики:
MAU / WAU / DAU — активность на разных горизонтах;
Retention — возвращаемость;
New Users — привлечение новых пользователей.
Как мы используем эти данные на практике:
Задача | Что делаем |
Определение критичности отчётов | Группируем дашборды по просмотрам и уникальным пользователям — получаем рейтинг, который помогает расставлять приоритеты поддержки |
Выявление устаревших дашбордов | Падающие просмотры сигнализируют, что проект закрыт или отчёт больше не нужен — пора выводить из эксплуатации или провести рефакторинг |
Прогноз нагрузки на инфраструктуру | Видим рост активных пользователей — проверяем, хватит ли ресурсов БД и BI |
Покрытие дерева метрик
Продвинутый приём — отслеживать, какая доля ключевых метрик компании (дерево метрик) уже покрыта автоматизированными дашбордами. Если в компании есть такое дерево показателей, эту метрику можно использовать как KPI для команды аналитики.
Цель — чтобы любой ключевой показатель был доступен «по клику» без участия аналитика.
3. Проактивное планирование
Без бэклога и роад‑мапа процесс разработки есть, но непонятно, куда система движется в целом. Аналитики реагируют на входящие запросы, а долгосрочные улучшения откладываются «на потом».
Что делаем:
ведём бэклог задач по дашбордам с приоритетами и оценками;
за каждое крупное направление закреплён ответственный аналитик;
роад‑мап на квартал и более синхронизируется с общими OKR/KPI’s вертикали.
Плюсы:
переход от реактивного режима («прилетело — сделали») к проактивному планированию;
прозрачный для всех план с ответственными и сроками;
возможность отслеживать прогресс и корректировать ожидания до того, как что‑то пойдёт не так.
Зачем всё это?
Описанные выше методы объединяет одна цель — перевести систему дашбординга из реактивного режима в проактивный. Вы не узнаете, что пользователи не находят нужные отчёты, пока они не начнут писать раздраженные сообщения. Вы не заметите, что дашборд умер, пока не увидите падение просмотров к нулю.
Опросы, демо, дайджесты, мониторинг метрик и покрытие дерева — это своего рода «сенсоры». Они дают обратную связь там, где её нет по умолчанию. Они превращают молчание пользователей в понятные сигналы, а хаос запросов — в дорожную карту.
Финальный чек‑лист
Консолидируем всю информацию выше в детальный чек‑лист с указанием приоритетов внедрения:
🔴 — высокий (критичные задачи на первое время)
🟡 — средний (повышаем качество и стабильность)
🟢 — низкий (развиваем как систему)
| Задача | Приоритет |
Настройка процессов взаимодействия с пользователями | Определить и сегментировать целевую аудиторию дашбордов | 🔴 |
Создать процесс сбора и анализа бизнес‑требований, учитывающий специфику сегментов пользователей | 🔴 | |
Организовать регулярное планирование совместно с бизнесом для прозрачного управления приоритетами и сроками | 🔴 | |
Базовая гигиена дашбордов | Отобразить в каждом отчете ответственного аналитика | 🔴 |
Отобразить на всех страницах с метриками индикатор актуальности данных | 🔴 | |
Указать в дашбордах или связанной документации базовую информацию по отчетам: · периметр отчета · описание метрик и логики из расчета · описание основных разрезов/фильтров · указание гранулярности и глубины данных · указание частоты обновления | 🔴 | |
Настроить читаемую, лаконичную и неперегруженную визуализацию под конкретные задачи, зафиксировать основные требования в чек‑листе для аналитиков | 🟡 | |
Создание единой точки входа и навигации | Создать стартовую страницу (welcome page) для быстрого поиска и перехода к дашбордам | 🔴 |
Дополнить стартовую страницу полезными ссылками на документацию, создать кнопку заведения задачи и так далее | 🟡 | |
Скорость и стабильность доставки данных | Определить SLA загрузки витрин по критичным отчетам | 🔴 |
Настроить мониторинг загрузки витрин и сделать алертинг по падениям | 🔴 | |
Оптимизировать датасеты, фильтры и параметры в дашбордах для быстрой загрузки виджетов, зафиксировать основные требования в чек‑листе для аналитиков | 🟡 | |
Оптимизировать модель витрин данных для минимизации сборок из сырья и возможности переиспользовать таблицы среднего слоя | 🟡 | |
Качество данных и доверие к метрикам | Обеспечить базовыми проверками качества данных основные источники | 🔴 |
Настроить дополнительные проверки с прицелом на бизнес‑значимость результатов | 🟡 | |
Создать прозрачную структуру документации по метрикам для пользователей | 🔴 | |
Перенести логику расчета метрик в дата‑каталог и использовать его как точку дистрибуции знаний в дашборды | 🟢 | |
Процессы развития | Сформировать и поддерживать актуальность дорожной карты дашбординга | 🔴 |
Организовать и регулярно проводить активности по развитию отношений с пользователями, используя все или некоторые из инструментов: · опросы аудитории; · проведение обзорных демо; · подготовка дайджестов. | 🟢 | |
Настроить мониторинг продуктовых метрик | 🟢 |
