Bad — Practices при создании отчета в Power BI. Таблицы. Часть первая

Всем привет! Продолжаем серию про Bad-practice от нашего преподавателя Дмитрия Соловьёва. при создании отчетов в Power BI. На этот раз поговорим про использование таблиц (дальше в статье под словом «таблица» понимаем любой табличный визуальный элемент).

Мы не говорим, что таблицы это абсолютное зло и их не должно быть в отчетах Power BI, но при добавлении таблиц и матриц стоит задумываться о том, каким образом пользователи будут работать с отчетом и какие выводы они должны сделать.

Перед разбором плохих практик хотим напомнить, что в Power BI существуют два визуальных элемента «из коробки», которые позволяют отобразить данные в виде таблицы — это таблица (1 на рисунке ниже) и матрица (2 на рисунке ниже).

Если проводить аналогию с Microsoft Excel, то таблица близка к обычному листу Excel, а матрица — к сводной таблице.

Более подробно об этих визуальных элементах можно почитать в официальной документации Microsoft:

• Таблица
• Матрица

Bad Practice №1. Заставлять пользователя использовать полосы прокрутки (применимо к любым визуальным элементам)

Основные причины, по которым не стоит так делать:

• Отчёт Power BI в первую очередь предназначен для визуального восприятия, поэтому пользователь должен видеть всю значимую информацию перед глазами. При наличии важной информации за пределами видимой области пользователь может на нее не обратить внимания.
• При печати или экспорте отчета в виде презентации/картинки будет сохранено то, что видно на экране, поэтому вся остальная информация потеряется.
• Такие таблицы просто некрасивы и неудобны для работы.

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

Как с этим жить?

• Выделяйте больше места для расположения визуального элемента так, чтобы не возникало потребности в прокручивании. Это верно для любых визуальных элементов в Power BI.
• Если не удается отобразить всю информацию без появления полос прокрутки — убедитесь, что по умолчанию отображается наиболее важная и значимая информация.
• Если нужно отображать большие объемы информации в табличном виде — используйте функцию «Анализировать в Excel», которая позволяет подключиться к модели данных Power BI из Excel и анализировать данные при помощи сводных таблиц и КУБ (CUBE) формул.

Bad Practice №2. Использование длинных имен в заголовках столбцов и строк.

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

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

Что делать?

• Избегать использования длинных имен, где это возможно. Например, в данном случае мере «Продажи (онлайн + оффлайн) по дате доставке» можно было легко дать имя «Продажи всего по дате доставки».
• Использовать перенос текста в заголовке. В матрице и таблице перенос по словам настраивается отдельно для заголовков строк (только для матрицы), столбцов и значений. Включен по умолчанию.

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

2. Переименовывать меры и измерения с длинными названиями на уровне визуального элемента.

1. Выводить длинный текст в заголовок таблицы. Если в визуальном элементе только один столбец фактов, либо несколько столбцов с родственной информацией, то достаточно легко подобрать корректное имя таблице, которое позволит пользователям отчёта понять о чем идет речь.

Bad-practice № 3. Использовать различные языки в названиях и данных разных языков.

Эта ошибка относится не только к таблицам. В принципе — в отчете you must not использовать разные Sprachen.

Что делать?

• Убедиться, что во всех визуальных элементах на странице отчета используются названия на одном языке.
• Убедиться, что все сокращения и аббревиатуры также на одном языке. Например для отчета на английском языке — Sales LY, на руссском — Продажи Пр. Год.
• Если Вы подготавливаете модель к использованию с функционалом вопросов и ответов — используйте синонимы и лингвистические схемы. Это отдельная большая тема, в которую пока не углубляемся.
• Отключить автоматические дату и время для всех отчётов. Это можно сделать в параметрах в секции «Глобальные» — «Загрузка данных» для всех отчетов и в секции «Текущий файл» — «Загрузка данных» для конкретного файла. Напоминаем, что в случае, если эта функция включена, то Power BI Desktop автоматически создает иерархии для всех полей с типом «Дата» и «Дата и время». С одной стороны это очень удобно, но с другой стороны это приводит к существенному замедлению скорости работы модели (это тема для отдельного разговора), а язык иерархий задается один раз — при создании модели данных и затем не может быть изменен.

• Поскольку календарь всё-таки нужен — используйте календарь, созданный в Power Query. Функцию для создания календаря можно скачать, например, здесь.
• (Не обязательно) В определенных случаях имеет смысл изменять названия строк и столбцов итогов. По умолчанию для них используется язык модели данных, но при публикации отчета в сервис powerbi.com — будет использоваться язык браузера, что может привести к нарушению стройности отчета.
• По возможности используйте форматы дат без использования названий дней и месяцев. Например 1/05/2010 вместо 1-Мая-2010г.

Bad-practice № 4. Использовать таблицы без условного форматирования

Таблица — далеко не самый наглядный инструмент показа данных — цифр и текста много, все сливается и непонятно что вообще происходит. Например, в таблице, показанной на рисунке — идут продажи хуже или лучше по сравнению с прошлым годом/планом?

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

Что делать?

• Использовать условное форматирование в таблицах. Это достаточно просто сделать в настройках поля.

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

Если предполагаете, что отчет будет использоваться для печати — используйте значки.

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

В целом тема условного форматирования достаточно глубокая и сегодня рассмотрим только самые основные моменты.

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

А также отличное видео о настройке условного форматирования по другому столбцу (англ.).

Bad-Practice №5 Неверный подбор измерений для столбцов и строк.

Осмысленность подбора измерений для таблицы. Каждый раз, когда Вы создаете визуальный элемент или отчет, стоит задавать себе вопросы — «Какой вывод должен сделать пользовать этого отчета?», «Удобно ли мне работать с этим отчетом?». Как только Вы их начнете себе задавать — Вы обнаружите, что многие из визуальных элементов содержат избыточный или недостаточный набор данных или просто неудобны для работы.

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

Выбор измерений для столбцов и строк — достаточно часто начинающие разработчики добавляют измерение с большим или часто меняющимся количеством или значениями в секцию столбцов. Это не совсем правильно, поскольку приводит либо к появлению «широкой таблицы», которая неудобна для анализа, либо ширина столбцов будет постоянно изменяться (поскольку обычно не отключают автоподбор ширины столбца в настройках). Так, например, календарные периоды стоит использовать в качестве измерения строк, а не столбцов.

Bad-Practice №6 Игнорирование форматов данных

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

В этой таблице сразу несколько грубых ошибок связанных, с форматированием:

• Для типа данных «Дата» выбран формат «Дата/время». Зачем? Он только «съедает» драгоценное пространство отчета и не добавляет никакой полезной информации.
• У столбцов SalesAmount, TotalProductCost и TaxAmt не задан формат данных «Валюта», поэтому пользователь отчета вынужден догадываться о чем идет речь. Что мы видим — рубли, доллары, может быть штуки, а может быть что-то еще…

Форматы данных это также достаточно большая тема, поэтому выделим несколько основных моментов:

• Всегда задавайте корректный формат данных для финансовых показателей. Пользователь не должен догадываться о какой валюте идёт речь.
• Задавайте тот уровень точности, который требуется. Если размер среднего чека равен сотням тысяч долларов или рублей, то никому не интересная точность данных до четвертого знака после запятой. Тип единиц (нет, тысячи, миллионы и т.д.), а также число десятичных знаков можно задать как в настройках формата столбца/меры, так и в настройках форматирования поля в свойствах конкретного визуального элемента
• Тоже самое касается дат — в большинстве случаев нет никакого смысла отображать время.
• Используйте разделители разрядов. Это делает числа намного более понятными.

Продолжение следует!

Автор статьи, Дмитрий Соловьев — эксперт, тренер и Most Valuable Professional в Microsoft, и автор нашего курса «Аналитик BI с 0 до PRO».

Приглашаем к нам на курс, чтобы стать профессионалом в BI аналитике и досконально знать Power BI.

Напоминаем, что для читателей портала vc.ru скидка 12% по промокоду «VC12BI».