От места к месту работы вижу две тенденции в построении продуктовых дашбордов: ◦ Либо есть один даш, который содержит все возможные графики, алерты на них и пояснения; ◦ Либо есть бесконечно много дашбордов, каждый содержит по одному графику и все пояснения к нему;

Чаще всего выбор между первой и второй моделью обуславливается на уровне "у нас так принято", и никто - особенно в корпорациях - не поддерживает изменения существующей структуры отображения данных ради здравого смысла.

Предположим, что мы пришли на продукт, где ещё нет дашбордов / они есть, но у нас есть полная свобода их настроить под себя. Так сколько их нужно сделать и чем руководствоваться?

Ниже я напишу несколько правил, которыми сам руководствовался, выстраивая визуализации данных в нескольких компаниях: 1. Необходим дашборд основных метрик. На нём должен быть график отображения north-star метрики + минимальное количество метрик, однозначно показывающих состояние продукта. Для технической части можно вывести агрегированный график соответствия SLA, для каналов привлечения - соотношение поток/план и так далее; 1.1 Важно: на каждый смысловой домен продукта стоит ограничиться одной метрикой, которая просто показывает "всё хорошо/всё плохо"; 2. Далее нужны дашборды, раскрывающие компоненты каждой из ключевых метрик; 2.1 Для примера: наша ключевая метрика - объём трафика. На подробном дашборде этой метрики есть разбивка по ресурсам, характер трафика и пр. - при чём в динамике, чтобы у нас работал аппарат принятия решений от изменений в продукте; 2.2 Важно: иногда дашборды не нужны. К примеру, для раскрытия технического состояния продукта лучше может подходить status page - при условии, что он отражает реальный уровень здоровья компонентов продукта и хранит исторические данные об инцидентах; 3. Если у каждой сабметрики есть отдельные компоненты - не стесняйтесь выделить ей ещё один самостоятельный дашборд, чтобы смотреть и понимать, из чего она формируется;

Чем удобен этот подход? 1. В первую очередь - легко масштабировать. На ранних этапах у вас будет минимум дашбордов, а когда продукт станет комплекснее - не придётся смотреть на тысячу досок, чтобы найти нужную метрику (или искать её на одной огромной панели) 2. Во вторую очередь - здравый смысл. Команда продукта мыслит уровнями иерархии: на верхнем слое - деньги, ниже - состояния продуктовых доменов, ещё ниже - элементы реализации каждого домена. Когда дашборды соответствуют смыслам - легко понять, где искать нужные данные;

📝 Пишите в комментариях, какие принципы для визуализации продуктовых данных используете вы

P. S. Не забывайте оставлять ❤️😃

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