Reveal the Data: заметки с тегом табло

Навигация между дашбордами в Tableau

Wed, 27 Apr 2022 10:53:27 +0200

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

Переходы с фильтрацией

Это один из самых важных и классных видов переходов — когда мы переходим в другой дашборд сразу с фильтров по какому-то срезу. Есть несколько вариантов как это можно релизовать.

Filter Action
Этот способ подойдёт, если у все ваши дашборды живут в одной книге. В этом случае мы создаем обычный Filter Action, но необходимо задать в виде Target Sheet другой дашборд:

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

URL Action с передачей параметров
Этот способ подходит, если необходим переход в другой дашборд, который храниться в другой книге. Кажется, что это более частый вариант для реальной структуры дашбордов.

В этом случае необходимо создать обычный URL Action, но передать в ссылку параметры после знака «?». В параметрах ссылки указывается название фильтра (поля в датасорсах должны называться одинаково на обоих дашбордах) и после равного его значения.

Так же в ссылках можно передавать не только фильтры, но и параметры. Документация по функционалу. У такого способа есть ограничения: есть максимальная динна url, которую может открыть браузер (может получиться если передаем много значений); может понадобиться конвертить пробелы с помощью URL Encoding; могут быть проблемы со спец. символами и русским языком в значениях; не очень удобно передавать даты и время.

Статичные ссылки на графиках

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

Go to Sheet Action
Для перехода на другой лист есть специальный экшен. Дашборды или листы, обязательно должны бать в одной книге. Настройки супер простые — выбираем на какие графики кликаем и на какой дашборд переходим:

URL Action
Второй вариант реализации — это создать статичный URL, который не будет зависеть от данных. В этом случае просто создаем URL Action и прописываем туда статичную ссылку.

Кнопки и ссылки

Такие виды навигации полезны когда нам нужно сделать ссылку на «документацию», какой-то центральный дашборд и т. п.

Картинка с ссылкой
Создать какую-то иконку с ссылкой можно двумя способами, с помощью вставки объекта «Image» или вставки объекта «Navigation»:

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

Кнопка Navigation подойдет когда ведём на лист или дашборд из той же книги. Для этого выбираем тип «Image Button» и указываем куда делаем переход. Листы обязательно не должны быть скрыты.

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

Для создания «ссылки» просто создаем лист, используем Text mark и пишём что-то внутри текста. Дальше используем или Go to sheet Actions или URL Actions, в зависимости от задачи.

Тоже самое можно сделать и используя какою-то иконку из шейпов:

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

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

Кнопки работают отлично, а вот «ссылка» получается дурацкой, так как всегда выровнена по центру и имеет внутренние, довольно большие, паддинги.

Вкладки

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

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

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

Для создания эффекта «вкладки» можно убрать у них границы и паддинги снизу и сделать под ними общую черту в виде Blank контейнера того же цвета, что и «активная» вкладка.

Вкладки внутри дашборда
Для реализации такого способа используется стандартный приём подмены графиков и создается лист с «псевдо» вкладками в виде шейп-файлов.

При этом понадобиться dummy источник в котором будут жить возможные значения параметров.

Для создания dummy источника я просто использую эксель, куда вбиваю нужное количество вкладок, а потом вставляю это в Табло через ctrl+C → ctrl+V (да, так можно, если вдруг не знали). А ниже примеры шейпов, которые использую я и инструкция как их добавить в Табло.

У Артёма Прыткова есть хорошее видео как собирать подобные кнопки и делать доп. экшены для снятия подсветки.

Зум для графика

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

Итого

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

Итоги первого сезона «Залетай в BI»

Wed, 01 Dec 2021 08:43:26 +0200

Статья подготовлена в рамках сериала «Залетай в BI»

Завершаем первый сезон сериала. =) В этот раз задачей Руслана было разработать овервью отчет для компании, который бы стал финальной вишенкой на торте системы отчетности, что мы делали. И вишенка прям удалась, получился очень стильный дашборд про основные показатели компании и топы по основным срезам.

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

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

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

Мне понравился такой формат «сериала» — он позволяет рассказать и про интересные технические моменты и вдохновить тех, кто только пришёл в область. Я размышляю о том, чтобы запустить второй сезон в новом году, если это будет интересно аудитории (так как это ест много ресурсов, а в планах ещё и хочется делать его с видео).

А ниже будут впечатления Руслана.

Залетайка для меня — это история про менторство, проектное обучение и удачу, которые соединились и превратились в “сменить профессию за 3 месяца”. Я сделал для себя несколько выводов, которые могут быть интересны всем, кто хочет попробовать себя в чем-то новом или прокачаться в своей области.

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

Мы познакомились с Ромой на курсе по датавизу от Лаборатории Данных и там я впервые попробовал поработать в Табло. Курс был хорошим стартом, но недостаточным, чтобы идти куда-то даже джуном. Я продолжил учиться на онлайн курсах, но везде упирался в то, что примеры задач были слишком абстрактными, не похожими на реальные задачи или на вопросы, с которыми я мог бы столкнуться на собеседовании.
Тогда я предложил Роме стать моим ментором. И с первого же занятия, я получил то, что хотел. Оно проходило в формате собеседования — ассесмента и там я узнал свой реальный уровень знаний (а точнее незнаний), но вместе с тем и указание, что нужно выучить в первую очередь, а что во вторую. Важный момент: если бы я пришел на такое собеседование с нулевым знанием табло и датавиза, то получил бы стандартный малополезный ответ — “иди учи азы”. Но чем выше твоя база, тем более специфична и обратная связь: “подтяни конкретно вот этот навык, а тут хорошо”

Вывод 2. Удачное менторство — это интерес и ответственность двух сторон.

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

Вывод 3. Проектное обучение — будущее образования.

Если вы когда нибудь изучали Табло, то вы знаете что такое Sample Superstore. Это встроенный в Табло учебный набор данных, который используется в подавляющем большинстве обучающих материалов. Это удобно для первых шагов и простых примеров, но жутко скучно, если делать проект для портфолио. Мы сразу решили что хотим делать дашборды максимально приближенные к реальности и чтобы весь процесс был похож на настоящий. Поэтому нашли на kaggle хороший датасет с реальными данными, я проводил с Ромой настоящие интервью, а он играл аккаунт менеджера Джейкоба Бунина). Сейчас, уже сделав на работе настоящие боевые дашборды могу сказать, что опыт полученный при обучении был релевантным.

Вывод 4. Удача важна, но без действий она не приходит

С помощью менторства я реально быстро залетел в BI, но я понимаю, что сложилось много факторов:
— Я сходил на обучение и познакомился с Ромой
— У меня была возможность активно учиться
— У Ромы было время и возможности стать ментором
— Появилась вакансия
И т. д.

На удачу нельзя повлиять, но нужно дать ей шанс проявиться. Если бы я не пошел на обучение, то и не подумал бы о менторстве. Если бы не спросил Рому о менторстве, то не узнал бы, что у него есть возможность. Не сказал бы что ищу работу, Рома не предложил бы попробоваться на вакансию. Так что да, вот оно, банальное “Везет тому кто везет”.

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

Оптимизация работы отчетов

Mon, 11 Oct 2021 09:15:44 +0200

Статья подготовлена в рамках сериала «Залетай в BI»

После небольшого перерыва Руслан продолжает осваивать премудрости Табло. В этот раз мы сконцентрировались на производительности и разбирались с тем как записывать Performance Recording. Скорость работы отчетов — очень важный показатель, для счастья пользователей. Если вы научитесь делать быстрые дашборды, они будут вам очень благодарны. =)

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

Исходный дашборд: https://public.tableau.com/app/profile/ruslan6180/viz/olist_new/Dashboard_City

Исходный перфоманс рекорд отчета:

Чтобы перфоманс рекорд был максимально идентичным все записи запускались через макрос-кликер, записывающий движение мышки. Также был отключен фильтр на длительность операции < 0.01 секунды, чтобы видеть все операции. Записи проводились локально

За точку старта берется событие с параметром tabdoc:navigate-to-sheet, а точкой окончания — последняя операция render, не относящаяся к окончанию работы перфоманс рекорда.

Гипотезы по улучшению отчета:

Уменьшить кол-во выводимых строк в Sellers List (сейчас выводится 5к+ marks), используя пагинацию и оставить только топ 100 городов на карте (вместо 4к)
Переделать график с боксплотами, оставив только диапазоны, без отдельных значений

Проверка гипотезы 1

Теперь в таблице sellers list выводится только 30 строк, а на карте только 100 значений. Результаты:

Проверка гипотезы 2

Переделаны боксплоты, чтобы не было выбросов. Результаты:

Итого

Финальный дашборд: https://public.tableau.com/app/profile/ruslan6180/viz/olist_new_performance/Dashboard_City
Результат в серднем для первичной загрузки -0,5 сек от исходного времени в 3,7 сек (или -13%). Дашборд и так был быстрый, но процентный прирост довольно значимый.

Порядок операций при работе с Relationships

Tue, 03 Aug 2021 22:25:35 +0200

Статья подготовлена в рамках сериала «Залетай в BI»

В прошлом спринте Руслан делал дашборд в котором столкнулся с интересным поведением Табло

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

Так как в одном заказе может быть несколько позиций, то для соединения этих таблиц логично использовать Relationships (далее рилейшены или макароны :-P).

Предположим, что мы хотим посчитать продажи по производителю«PA». Простой способ — добавить поле Producer в фильтры и выбрать нужного производителя:

Всё работает, как мы ожидаем и показывается верное число — 550 рублей. Но что, если мы хотели бы посчитать продажи не через фильтр, а через отдельное расчетное поле вида IIF([Producer]=«PA»,[Total Sales],NULL)?
Например, такое могло бы пригодиться, чтобы была возможность выбирать производителя через использование параметра и нам нужно было сравнивать параметр с значением поля Producer. В этом случае мы получаем ошибку задвоения по количеству товаров в заказе:

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

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

Какой-то порядок операций в квадрате =) Было бы круто найти технический алгоритм работы этих макарон. Кажется, что можно наделать незаметных ошибок, которые приведут к неверному результату. Будьте осторожны!

Особенности работы функции TOTAL()

Tue, 20 Jul 2021 19:45:41 +0200

Статья подготовлена в рамках сериала «Залетай в BI»

На прошлой недели Руслан делал задачки на табличные функции и сделал ошибку при работе с функцией TOTAL(). Объясняю в чем она заключалась и как это работает.

Функций TOTAL() — уникальная функция в Табло, которая работает по своим правилам. Если их не знать, то легко сделать ошибку. Рассмотрим на примерах.

TOTAL() игнорирует дименшены в виде

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

Сначала посчитаем средний чек между категориями. Для этого можем кинуть референс лайн со средним на вид:

Получили 445$ — это значение получается как (504+532+96+649)/4=445. А каждое слагаемое — это AVG(Sales) по всем строчкам данных внутри этой категории. То есть мы посчитали среднее от средних.

Теперь попробуем воспроизвести среднее от средних с помощью функции TOTAL():

Получим то, что значение считается по-другому, вместо 445, мы видим 350. Почему же так происходит? Функция TOTAL игнорирует все димешены в виде при расчёте и считает среднее на уровне строк базы данных. То есть мы по сути получили такой расчёт, как если бы в виде не было ни одного дименшена:

Игнорирование дименшенов — самое главное отличие функции TOTAL(), в отличии от других табличных вычислений она не зависит от разбивки на листе.

Если бы мы хотели посчитать средне от среднего нам бы было необходимо использовать функцию WINDOW_AVG(). Эта функция уже не игнорирует дименшены, а делает расчеты между агрегированными значениями, которые получились по каждому из дименшенов.

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

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

Grand Total использует TOTAL()

Предположим, что мы хотим вывести таблицу в которой будут посчитаны количество уникальные товаров по городам (считаем, что название товара == его ID):

Теперь добавим итог для этой таблицы. Получим 110 товаров.

Пользователи, привыкшие к Экселю, подумают, что в итоге мы увидим сумму значений по строкам, но на самом деле это не так. Все итоги в Табло тоже используют функцию TOTAL() и так как мы считаем неаддитивную метрику, то он посчитает количество уникальных товаров среди всех городов. Чтобы переключить способ расчета на сумму, необходимо выбрать опцию Total using (таким образом на самом деле меняем расчет на WINDOW_SUM()). При это получим другой результат (114, а не 110)

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

Итого

Оба примера которые я привел в заметке очень часто встречаются в реальной жизни при расчетах DAU, LTV, Retention и других неаддитивных метрик. Будьте аккуратны и случайно не посчитайте что-то не то, что ожидает ваш пользователь.

LODы, порядок операций и как работает Табло

Wed, 07 Jul 2021 08:19:20 +0200

Статья подготовлена в рамках сериала «Залетай в BI»

На прошлой недели Руслан прокачивал навыки работы со сложным техническим функционалом. Для того чтобы прокачать работу с расчётами я дал задачки, где нужно было построить одни и те же графики при помощи табличных вычислений и LODов. Тут были две основные проблемы: переусложненные вычисления и ошибки в понимании как работает порядок операций. Разберём две эти проблемы на небольших примерах на любимом Sample Superstore.

Как работают LODы и Табло в целом

Предположим, что хотим посчитать для каждого штата процент продаж от общего с помощью LODа (понятно, что для этого лучше подошли бы тейбл кальки, это чисто учебная задача). Руслан сделал это с помощью такой формулы:

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

Во первых давай разберёмся какой SQL запрос послало Табло, когда мы просто собрали лист с суммой продаж по штатам. Когда мы кладём любые пилюли на полку Табло формирует запрос к базе данныых, получает в ответ агрегированную таблицу данных и визуализирует её. Если мы положили пилюли как на скрине, то Табло отправило примерно такой запрос (не ругайте меня за нотацию, у меня лапки на счёт SQL, сейчас важнее смысл). Это, кстати, называется VIZQL — проприетарная технология Табло превращения пилюль в запросы к БД.

Теперь давайте разберёмся как работает LOD (в данном случае FIXED). Level of Detail расчет, это такой расчёт, который создаёт отдельный подзапрос к базе данных и потом джойнит его к той агрегированной таблице, которая получилась в результате запроса от VIZQL листа. То есть этот запрос выполняется паралельно основному и потом происходит его джоин. Из-за этого LODы так медленно и работают на больших объёмах данных.

Структура выражения LOD при этом выглядит так:

Получается, что наша формула для расчета процента от общего превратиться в такие подзапросы:

Мы сразу видим, что первый подзапрос, по-сути идентичен тому запросу, что формирует сам лист без применения LOD. В этом случае получается, что мы переусложняем и вместо LOD мы можем использовать в числителе просто SUM([Sales]). Но при этом Табло будет ругаться на то, что мы смешиваем агрегированные и неагрегированные показатели:

Чтобы избавиться от этой ошибки нам нужно обернуть формулу в знаменателе в агрегацию. Например в сумму. Всё отлично работает.

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

Порядок операций

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

Пока объяснял это Руслану, нарисовал такую схемку, вот прям живой скрин, поэтому немного страшненький:

Рассмотрим примеры для каждого из кейсов.

1. Превращение обычного расчета в FIXED
Здесь всё обычно супер очевидно, хотим подсчитать что-то, что будет «игнорировать» фильтры. Игнорировать в кавычках, так как на самом деле этот запрос выполняется параллельно. Бизнесовый пример — хотим при выборе конкретного сегмента товаров в фильтре видеть, какой процент продаж он составляет в регионе:

2. Превращение обычного фильтра в контекстный
Превращение фильтра в контекстный позволяет нам применить его «как бы на уровне датасорса». Это на самом деле создаёт временную таблицу к которой уже обращается VIZQL, что может как тормозить, так и иногда ускорять работу Табло. Если вы применяете контекстный фильтр ко всем листам в визуализации, подумайте на счёт его переноса в датасорс фильтры через параметры. Бизнесовый пример — хотим видеть топ-10 штатов по продажам за 2019 год. Используем для этого фильтр TopN, а чтобы он правильно работал при выборе года, фильтр по году заносим в контекст.

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

Для этого можно использовать фильтр по FIRST()>-12. Так как это табличный фильтр он и идёт в самом конце фильтрации по порядку операций. Значит он не удалит данные из запроса, а только скроит их из вида, что нам и нужно.

Книга с этими примерами на Паблике.

Понимаю, что привёл примеры без детальных объяснений, но зато кратко и основные кейсы. Есил вам нужно прокачать эту часть поищите в инете по запросу Tableau Order of Operations. Вот, например, неплохое видео.

Шпаргалка по Quick Table Calculations

Tue, 22 Jun 2021 22:41:49 +0200

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

Задание

Придумать по одному бизнес кейсу для каждого Quick Table Calcs, которые есть в Табло. Описать какую задачу решает этот кальк, описать особенности этого калька (если есть).

Решение

Книга на Табло Паблик с примерами

Общая особенность формул: Для всех table calcs можно уточнять размер партиции (Таблица, панель, ячейка) и направление расчета, если партиция по структуре не ряд, а таблица. Направления — down, across и т. д.

Running total (Включает в себя быстрые YTD total, YTD growth)

Краткое описание

Агрегация нарастающим итогом.
YTD total. Суммы нарастающим итогом, разбитые по годам
YTD growth. Приросты к прошлому году нарастающим итогом, разбитые по годам

Формула
RUNNING_SUM(SUM([Sales]))

Особенности

Для агрегации можно использовать sum, avg, min, max
Расчет может быть основан на другой расчетной метрике (Secondary calculation). Т. е. можно сделать например нарастающий итог процента от общего.
Для того чтобы работали функции YTD и YTD Growth в виде обязательно должны быть год и месяц
Нет расчета RUNNING_COUNTD что очень не удобно для подсчета когорт уникальных пользователей

Кейсы

Все сценарии когда нам нужно смотреть на наши цифры нарастающим итогом. Например сравнивать факт и план, если план дается нарастающим итогом, а не разбит по периодам
Можем строить график парето. Понимать соотношение кол-ва элементов и их вклада (X% товарных позиций приносят Y% выручки)
Риал тайм цифра. Например количество открытых тикетов, которое складывается из всех открытых и закрытых тикетов за все время или количество проданных билетов за все дни

Difference from

Краткое описание
Разница текущего значения и выбранного (чаще всего предыдущего) в абсолютном выражении. Насколько приросли к выбранному периоду в абсолюте.

Формула
ZN(SUM([Sales])) — LOOKUP(ZN(SUM([Sales])), -1)

Особенности
Работает опция «Relative to» — выбранным значением может быть Previous, Next, First или Last

Кейсы

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

Percent difference from и Year over Year growth rate

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

Формула
(ZN(SUM([Sales])) — LOOKUP(ZN(SUM([Sales])), -1)) / ABS(LOOKUP(ZN(SUM([Sales])), -1))

Особенности

Работает опция «Relative to» — выбранным значением может быть Previous, Next, First или Last
Расчет YoY доступен только если в виде есть год и месяц.

Кейсы

Year over Year growth rate. Сравнение результатов текущего периода и аналогичного периода год назад
График доходности актива. Если хотим смотреть % изменения относительно первого значения.

Percent from

Краткое описание.
Сравнение текущего значения и выбранного в процентном выражении. Какой % составляет текущее значение от выбранного.

Формула
ZN(SUM([Sales])) / LOOKUP(ZN(SUM([Sales])), -1)

Особенности
Выбранным значением может быть Previous, Next, First, Last

Кейсы

Расчет выполнения факта от плана в длинной структуре данных
Сравнение нескольких категорий в процентном соотношении

Percent of total

Краткое описание
Доля от общего.

Кейсы

Можем использовать чтобы понимать вклад отдельной категории продуктов в общие продажи
Строить нормированные бар-чарты и ареа-чарты

Rank

Краткое описание.
Порядковый для среза посчитанный по убыванию или возрастанию агрегата какой-то метрики

Формула
RANK(SUM([Sales]))

Особенности
Можно выбирать формулу выбора номера при совпадающих значения (Competition, dense, unique, modified competition)

Кейсы

Рейтинг с изменением по времени (бамп чарт)
Сортировать и фильтровать данные когда нельзя фильтр по TopN

Percentile

Краткое описание
Процентиль — определяет в какой процент от общего попадает значение для упорядоченного по метрике массива.

Формула
RANK_PERCENTILE(SUM([Sales]))

Кейс
Отобрать все записи, входящие в топ N% значений

Moving calculation

Краткое описание
Скользящая аггрегация. Вместо одного значения берет для расчета несколько, выбирая их относительно текущего

Формула
WINDOW_AVG(SUM([Sales]), -2, 0)

Особенности

Для агрегации можно использовать sum, avg, min, max
Выборка задается окном «от и после» текущего значения
Текущее значение и случаи когда не нет полных данных для окна можно исключать.

Кейсы
Если данные показывают большую вариабельность или имеют сезонность, то часто общая динамика непонятна. В этом случае используется скользящее среднее.

Дополнительные материалы

— Видео от Энди Крибела
— Материалы Табло Марафона
— Официальная документация

Последовательный выбор двух параметров одним экшеном

Fri, 14 May 2021 08:19:41 +0200

Редко пишу такие технические статьи про Табло, но недавно придумал довольно интересное решение, захотелось им поделиться.

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

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

1) Делаем счётчик кликов в график. Для этого создаём INT параметр Counter и поле Counter + 1, которое будет прибавлять количество кликов

2) Создаем два одинаковых параметра для выбора метрика. Это текстовые параметры, которые берут значения из поля Pivot Fields Names при открытии книги.

3) Создаём поля, которые проверяют какой сейчас номер клика в визуализацию и возвращают либо то же самое значение, что уже было выбрано, либо выбирают новое.

Selected Metric 1 Check // Название поля
IIF([Counter]%2=0,[Pivot Field Names],[Select Metric 1]) //Делает проверку остатка от деления на 2, если равно нулю, то клик «четный» и надо поменять значение, если «нечетный» то возвращаем текущее значение параметра

Для выбора второй метрики будет зеркальная формула:

Selected Metric 2 Check 
IIF([Counter]%2!=0,[Pivot Field Names],[Select Metric 2])

С помощью остатка от деления можно считать и третий, и четвертый клик и т. п.

4) Делаем расчетные поля, которые подставляют нужную метрику в зависимости от параметра. Эти поля мы и будем выводить на график.

Selected Metric 1 
IIF([Select Metric 1]=[Pivot Field Names],[Pivot Field Values],NULL)

Selected Metric 2
IIF([Select Metric 2]=[Pivot Field Names],[Pivot Field Values],NULL)

5) Создаём график с которого будет происходит управление. Я сделал для этого фактоиды. Важно положить все расчетные поля в details, чтобы мы могли использовать их в Parameters Actions.

6) Создаём график в котором будут выбираться метрики

7) Делаем дашборд и настраиваем три параметр экшена. Первый про изменение счётчика при клике.

Два вторых про изменение выбранной метрики

8) Наводим марафет и добавляем всякий приятности типа подсказки, деселекта хайлата и т. п. Получаем рабочую версию. Можете покликать и посмотреть как будет меняться значение Counter и выбранных метрик для осей. На Паблике можно скачать книгу и покопаться как устроено.

___

Итоги
Рассмотренный кейс довольно специфичный и, наверное, не является лучшей практикой UX паттернов, но с помощью него хотел показать, что возможности Табло по сложным интерфейсам — очень большие. Используя параметр экшены и счётчики можно сделать почти всё что угодно. Например, выводить какую-то надпись, если кликнули больше 100 раз. =)

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

Шаблон дашборда для Эгеи

Tue, 04 May 2021 19:21:46 +0200

Как-то раз мне написал Саша Михайлов и мы договорились сделать с ним совместный мини-проектик — шаблон для Табло в который смогли бы тянуть автоматом данные из движка для блогов Эгея (он же используется и для этого блога). Тянуть в лайве не получается, так как Табло Паблик не работает с базами данных (из платной версии можно без проблем подключиться), поэтому Саша сделал очень крутой ноутбук, который вытягивает данные из базы данных и перекладывает их в гугл-таблицы. А туда уже можно подключать Табло. Вот краткое описание работы с этим ноутбуком.

Я же сделал шаблон в Табло, его можно скачать с Табло Паблик и подставить туда свои данные. Для этого:

1. Скачайте шаблон с Паблика

2. Зайдите на вкладку Data Source и подмените в источнике гугл-таблицу на свою

3. В идеальной ситуации — это всё! Можно возвращаться на вкладку с дашбордом и сохранить работу, например, к себе на Табло Паблик. Если что-то пойдет не так — пишите, постараюсь помочь чем смогу.

В конечном результате получиться такой дашборд:

Переверстка в Power BI

Tue, 30 Mar 2021 08:33:03 +0200

Ко мне в личку пришёл Владимир Шилов из Ростелекома и попросил взять в рубрику «переверстка» дашборд (точнее темплейт) в Power BI. Сначала я хотел отказаться, но потом решил «WTF, hold my beer!». Впервые переделал дашборд в этой BI-системе. Получился очень интересный лично для меня опыт. Решил собрать в этой заметке, что заметил на счет конкретно этого дашборда и Power BI в целом.

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

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

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

Выравнивание по центру

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

Подробнее про выключку по центру (это так называется выравнивание в типографике):
— Заметка Игоря Штанга
— Совет Михаила Нозика про смену выравнивания и ещё один, про выравнивание по ширине
— Памятка верстальщика

Правило контраста и иерархии

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

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

Самыми контрастными по размеру и цвету получились тримеп, фактоиды и пай-чарт. Для диаграмм с большой площадью заливки лучше использовать пастельные вариант палитры, чтобы они не давили на зрителя своей «массой»

Видео про контраст от Михала Нозика

Правило близости, правило внутреннего и внешнего

Расстояния от края блока до элементов внутри него получились очень маленькими. Из-за этого элементы смотрятся слипшимися. Чтобы исправить это — нужно дать больше пространства между блоками.

Подробнее:
— Разъяснение этого правила от Артёма Горбунова
— Как теория близости работает в интерфейсе?

Фильтры без аналитики

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

Применив принципы, которые описал выше, у меня получился вот такой результат:

Что я изменил:
— Выровнял всё по левому краю
— Сделал меньше контрасты между заголовком и фактоидами, унифицировал заголовки
— Сделал весь полу-черный текст черным
— Добавил больше пространства между блоками и убрал серую сетку (так как её сложно сделать при верстке в PBI)
— Фильтры выделил отдельной плашкой и кнопки заменил на мини бар-чарты
— Сделал пастельные цвета для тримапа
— Лого переместил на право, так как оно текстовое и плохо стыковалось с заголовком
— Сделал пропорции графиков более подходящими под их тип (да, графики были только примерами, но надо чтобы разработчики запоминали такие вещи из примеров)
— Убрал странные индикаторы в виде восклицательного знака в фактоидах

Power BI vs Tableau

Я занимался только версткой и оформлением, поэтому сравню именно эти аспекты.

Сам подход к верстке — отличается координально. С одной стороны, в Power BI, он гораздо более прост и привычен — полное ощущение, что работаешь с Power Point. А с другой, сразу ставит крест на нормальной адаптивности под разные экраны ноутбуков. Табло в этом плане круче.

Настройки оформления в Power BI сейчас довольно обширные (последний раз я трогал его года три назад), позволяют закрыть большинство кейсов. Мне только не хватило возможности настраивать внутренние паддинги для блоков. И вынесло мозг, что нельзя поменять цвет только части текста в строке.

Ещё выписал для себя список фич, которым прям позавидовал:
— Офигенные фильтры, которые при снятии всех галочек догадываются, что нужно показывать всё. Это очень удобно
— Крутая визуализация для факторного анализа (дерево метрик). Я такую в Табло два месяца делал, а тут бац и в два клика =(
— Копи-паст форматирования работает шикарно, а не как в Табло
— Группировки блоков на дашборде с помощью одной кнопки. Какой же кайф!
— Очень неплохие бар-чарт таблицы с правильным выравниванием цифр
— Можно вставить нормально ссылку в текст
— Умные подписи внутри тримапа при иерархии

Выводы

Power BI не удалось меня в себя влюбить, всё равно продукт прям так и предлагает тебе сделать плохо. Попробуйте сделать стиль таблицы «Броские строки», просто вырвиглаз 🤦‍♂️
Но в целом у меня от него сложились гораздо более приятные впечатления, чем три года назад. И оказывается, в нём можно делать очень даже неплохие по оформлению дашборды без миллиарда цветом и с аккуратным выравниванием. ;-)

Все населённые пункты РФ

Thu, 11 Mar 2021 23:13:20 +0200

Сделал визуализацию про все населённые пункты РФ, получилось красиво, напоминает карту рельефа.

68% людей проживают в городах. Больше всего в России деревень — 76 тысяч. На севере больше деревень и сёл, а на юге станицы и хутора, не знал о такой особенности. А ещё, я был уверен, что в России куча деревень с названием Бухалово. Оказалось, что это не так, их всего пять, зато целых 286 Александровок.

Давно хотел сделать что-то подобное, но не попадалось хороших данных. А тут ко мне пришли ребята из проекта «Инфраструктура научно-исследовательских данных» и попросили про них рассказать. Это портал, где они собирают и обогащают открытые данные, и дальше их бесплатно раздают. Я решил посмотреть, какие есть датасеты, наткнулся на этот и визуализировал его.

Качество датасетов на портале издалека выглядит лучше, чем на портале открытых данных РФ. Пока там немного наборов, но есть большие и интересные. Надеюсь проект правда направлен на благие дела, будут только полезные датасеты и он не сведётся к деятельности ради закрытия планов.

Список лайфхаков Табло

Mon, 01 Feb 2021 09:37:03 +0200

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

Выпуск №1
0:00 — Как сделать удобный фактоид с приростами период к периоду
9:26 — Как показать разрыв в данных с помощью Missing Values
11:58 — Как ускорить работу в Табло за счет фишек интерфейса

Выпуск №2
0:00 — Сортировка по значению за последний месяц с помощью Nested Table Calcs
4:04 — Оформление спарклайнов при помощи Reference Lines
7:12 — Highlighted таблица с подсветкой по одной метрике из Measure Values

Выпуск №3
0:00 — UTF символы для создания цветовой легенды
3:29 — Динамический фильтр дат с окном и ренджем
7:08 — Подпись событий о запусках или маркетинговых активностях во времени на таймсерии

Выпуск №4
0:00 — Как сделать удобную адаптивную легенду
3:00 — Как подписать точки на графике по условию
7:12 — Как избежать проблем при работе с Табло на Windows

Выпуск №5
0:00 — Составные таблицы из нескольких листов
4:19 — Функция Random()
8:16 — Переименование Worksheets и Dashboards на сервере

Выпуск №6
0:00 — Тоталы в барах
4:19 — Таблица с спарклайнами
8:16 — Предыдущий период на графике

Выпуск №7
0:00 — Пагинация в таблице
4:45 — Сравнение метрики по разрезам
11:23 — Подсветка строк в таблице

Выпуск №8
0:00 — Бины и группировка максимума
5:38 — Выравнивание в бар-чарт таблице
13:05 — Подсветка выходных

Выпуск №9
0:00 — Дубль графиков
6:01 — Топ N в каждой категории
9:22 — Размер точек на карте

Выпуск №10
0:00 — Run Rate
12:30 — Двойная цветовая легенда
15:04 — Apply to Totals

Плейлист со всеми выпусками:

Итогов года пост 2020

Thu, 21 Jan 2021 20:54:37 +0200

Собрал все итоги года в одном посте.

Начну с Телеграма. Данные собрал из API tgstat.ru, выгрузки из самого Телеграма и некоторую разметку сделал руками. Получился такой дашборд:

Основные хайлайты
— Канал вырос с 0 до 2.2К подписчиков.
— Всё время поддерживается Engagement Rate (ERR) ≈ 100% (Ср. охват поста/Кол-во подписчиков). Эта метрика для меня важнее кол-ва подписчиков, так как показывает, насколько интересен контент читателям и насколько им делятся.
— Больше всего в канале постов в тегом #ссылка — 81 шт., наибольший охват и ERR получили посты с тегами #статья — 2К охват, 241% ERR
— Чаще всего я публикую посты по пятницам, но охват у таких постов не самый большой. По времени чаще всего с 14 до 15, здесь показатели тоже небольшие, видимо обеденное время. Нужно будет с этим поэкспериментировать =)
— Был написал 241 пост. Самым просматриваемым постом стал пост про черные точки, его репостнули в канале Адовый UX. Самым виральным стал пост про статью «Таблица или график? Как убедить заказчика».
— 80% просмотров на пост приходятся за первые 3-4 часа после публикации.

Впечатления
Я, если честно, приятно удивлён количеством подписчиков и вовлеченностью. Я веду блог пять лет, и мне всегда казалось, что тематика супер узкая и интересная малому количеству людей. Когда заводил канал, думал, что максимальный потолок для канала ~1К подписчиков (посчитал как половина от суммы участников чата по визуализации и чата по Табло). Рад, что контент интересен и полезен, для меня это классная возможность поделиться тем, что я считаю важным, и развить личный бренд.

Спасибо всем, кто делится постами, особенно @rockyourdata, @dashboardets, @chartomojka, @data_publication, @leftjoin, @internetanalytics, @analyst_club, @nastengraph, @dataviznews, @novichkovnet или просто в личных сообщениях. Кстати, список каналов, за которыми я сам слежу лежит здесь.

YouTube

Данные взял из Data API YouTube Data API, скачав их с помощью скрипта на js напрямую в гугл-таблицы — очень удобно! https://public.tableau.com/views/YoutubeAnalysis_16090922510490/YouTubeAnalysis Собрал дашборд, по аналогии с тем, что разбирали на вебинаре по адаптивной верстке.

Основные хайлайты
— За год я выпустил 26 видео, на канал подписалось 429 человек, всего 16К просмотров.
— Большего всего сморят видео с типом #выступление и #подкаст. В среднем одно видео собирает ~400 просмотров (медиана 370).
— Самое просматриваемое видео «Алгоритм разработки дашборда» на Date Learn. Меньше всего у перевёрстки «Product Superstore».
— Самый короткий подкаст был пилотным, с Андреем Дорожным, но зато у него больше всего просмотров среди подкастов. Дольше всего проговорили с Никитой Рокотяном.

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

Блог и сайт

Данные для этого анализа мне помог собрать Саша Михайлов, автора канала data-будни про инжиниринг данных, рекомендую. Данные тянутся из базы блога с помощью питона записанного в гугл-коллабе и после этого складируются в гугл-таблицы. Скоро сделаем с Сашей инструкцию, как собрать такой же дашборд если у вас блог на Эгее. Плюс ещё кое-что посмотрел в Я.Метрике. И конечно же собрал дашборд. =)

Основные хайлайты
— За год написал в блог 32 заметки, из них 14 «настоящих» статей, остальное дубли подборок из телеграмма и видео с Ютуба. Это больше, чем в прошлом и позапрошлом году, но меньше чем в 2017-ом.
— Самой просматриваемой стала заметка «Интерфейсы в BI системах».
— Завёл отдельный тред для подборки работ по визуализации, собрал 93 классных примера.
— Самой популярной заметкой по запросам из поисковиков является уже который год статья про логарифмическую шкалу. В этом году она особенно популярна ))) Смотрите как забавно отличается рост просмотров от остальных заметок.

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

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

Подборка самых важных и полезных авторских материалов за год по моему мнению

— Статья «Навыки для визуализации данных»
— Статья «Интерфейсы в BI-системах»
— Вебинар «Алгоритм проектирования дашборда»
— Статья «Шаблоны верстки дашбордов» (скоро буду обновлять, докрутил идеи)
— Вебинар про Адаптивную верстку в Табло
— Статья «Таблица или график? Как убедить заказчика» и вебинар на базе этой статьи
— Статья «График план-факт во времени»
— Выступление про стайлгад и темплпейт Я.Такси
— Трибьют «Тафти в Табло»
— Дашборд про рынок вакансий аналитиков

Tableau Public

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

Личная статистика

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

В этом году очень много времени провел, работая за компом. Планирую в следующем году ограничить время на работу. Это всё плохо сказывается на продуктивности и здоровье. Надо больше отдыхать и относиться к этому, как к части работы. В основном трачу время на Табло (34%) и мессенджеры (28% и 82К отправленных сообщений, 187 часов в zoom).

В конце сентября заболел ковидом и на это же время наложилось несколько важных проектов, из-за этого потерял все старания по контролю веса с начала года. Благо сам вирус перенёс супер просто, но ещё 2 месяца после этого был как ватный. Интересно, что в данных это проявилось как повышенный сердечный ритм в октябре и ноябре. Неприятная болезнь, какие-то пост эффекты дурацкие. Из-за этого же явно меньше ходил, особенно в конце года совсем не соблюдал планку в 8500 шагов в день.

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

Данные: MI Band 3, Mi Scale, Timecamp.com

Табло

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

Данные: Timecamp.com

Траты

Чаще всего в этом году тратил на супермаркеты, транспорт и кафешки. Больше всего потратил на переводы и нал, они превратились в три самые крупные покупки: машину, подводку газа в дом и обустройство участка.

Данные: Выгрузка из банка

Перемещения

В этом году никаких зарубежных поездок не было, как и у большинства. Зато я снова перешёл с iPhone на Android, и там есть замечательная функция выгрузки местоположений и вообще любой статистики по Гугл аккаунту. Получилась классная карта. В карантин много раз порадовался, что последние 3 года живу за городом. Прикольно видно как я переехал с юго-востока на северо-запад, а потом на север.

Данные: takeout.google.com

Сайт и айдентика

Ещё в этом году обновил сай и его английскую версию. За это огромное спасибо Кириллу Беляеву, он взялся нарисовать дизайн, а я заверстал сайт.

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

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

🎄Всех с наступившим, приятных заказчиков и классных дашбордов вам в этом году!

Адаптивная верстка в Табло

Thu, 21 Jan 2021 20:21:41 +0200

Выступил на проекте DataLearn с рассказом про адаптивную верстку.

Материалы со вчерашнего вебинара про адаптивную верстку в Табло:

Запись вебинара
Книга на Паблике (можно скачать и посмотреть, что внутри)
Статьи The Economist:
— про ошибки в мобильных графиках
— про адаптацию графиков для инстаграма
Дашборд про зарплаты (пример с CSS, можно посмотреть в инспекторе кода)
Навыки и литература по визуализации

Сам дашборд, на котором разбирали теорию, — это статистика канала Data Learn на YouTube. Данные собрал через API YouTube и скрипт в гугл-таблицах. Получился прикольный дашборд, который можно будет переиспользовать.

Масштаб текста в Windows и Tableau

Thu, 19 Nov 2020 20:29:12 +0200

Очень важная заметка для тех кто работает с Табло на Винде. Из-за этой ошибки вечно криво и косо верстаются дашборды.

Если у вас в настройках экрана стоит шрифт 125%,150% и т. п. то при работе с Табло Десктоп вы можете получить неправильную отрисовку размеров шрифтов и некоторых элементов. Настроив дашборд после публикации вы получаете ошибки — элементы смещены или не умещаются. Нормально работает только с шрифтами 100%.

Вот как это выглядит — вы сделали дашборд и на десктопе всё выглядит ОК:

А после заливки на сервер это превращается в кашу:

Если сталкиваетесь с такой проблемой, то вот как это исправить:
— Видео-инструкция
— Официальная инструкция от Табло
— Инструкция скриншотами:

Единственная проблема, что такое решение «блюрит» вам дашборд в десктопе. Такое будет только на машине, а на сервере отчет будет выглядеть четким. Если это не подходит, то нужно менять размер шрифта в системе на 100% или 200% процентов. =(

Алгоритм разработки дашборда — Dashboard Canvas

Sun, 26 Jul 2020 18:13:36 +0200

Дмитрий Аношин создал и ведёт проект datalearn.ru — бесплатные курсы о том, как стать инженером данных или аналитиком. Он рассказывает про инструменты и том как работать с данными. Мне очень нравится его инициатива — это классно делиться знаниями и реальными примерами. Я провёл вместе с ребятами вебинар на тему разработки дашбордов и рассказал в первый раз на большую аудиторию про свою разработку — Dashboard Canvas. Это yet another framework, но чем больше им пользуюсь, тем больше верю что это очень полезная инициатива.

Вот запись вебинара и материалы:

Ссылки и материалы из вебинара:
Презентация и шаблон в pptx лежат в Миро
Интерактивная статья про пай-чарты
TUG про стайлгайд

Интерфейсы в BI системах

Sat, 27 Jun 2020 17:20:52 +0200

Антон Жиянов написал замечательный набор статей про проектирование интерфейса. Я попробовал применить описанные им принципы к BI системам.

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

Дальше опишу каждый из этих компонентов для BI системы. Буду делать это на примере Tableau, когда речь пойдёт на счет конкретных элементов интерфейса и т. п.

Ментальная модель

Я думаю, что в голове пользователь видит примерно так идеальное взаимодействие с BI системой:

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

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

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

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

Но обычно это выглядит примерно так:

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

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

Внутри системы на меня выпадет большой список с папками, в которых лежат разные отчеты. Некоторые папки будут называться по отделам моей компании, другие по названиям проектов, третьи по имени владельца папки. В папке отдела продаж я найду несколько отчетов без описаний: «Продажи всего», «Продажи по РФ NEW», «По городам 2.0», «Продажи 22.02_Final», «Продажи Бубликов»… Открою первый попавшийся отчет и попробую в нём разобраться. Вроде то, что нужно, но не хватает разбивки до магазина. Зайду в другой отчет, там есть нужная разбивка, но почему-то тотал продаж не сходится с предыдущим отчетом. Спрошу у коллеги, почему так и узнаю, что во втором отчете не учтены продажи из категории «Бакалея», так как они попадают в данные не через API, а менеджер грузит их раз в месяц через Excel файл.

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

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

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

Спрятать всю сложность от пользователя и, зная его роль в компании и его задачи, выводить самый релевантный контент. То есть в идеале, BI система — это строка поиска, которая классно даёт ответы. Такой Яндекс + Вольфрам Альфа, но только заточенный под конкретную компанию.
Разбить слона по кусочкам — построить систему шагов и вопросов, которые смогут провести пользователя «за ручку», чтобы решить его кейс, но при этом не переусложнить всё огромным и непонятным интерфейсом. Примеры из обычных продуктов есть в статье Антона.

Ожидания от продукта

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

Навыки

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

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

В целом я бы проектировал BI системы не прям для массового пользователя, но и не для профессионального аналитика. Для меня это больше похоже на фразы «Продвинутый пользователь ПК» или «Умеет работать с Excel» из резюме. То есть пользователь действительно обладает базовыми навыками работы с профессиональным ПО, но не готов погружаться в тонкости (читать документацию и инструкции) перед тем, как пользоваться BI системой и воспринимает её как просто сложный сайт.

Контекст использования

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

Платформа

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

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

Поэтому при проектировании отчетов и BI системы в целом не забывайте, что она живет внутри браузера и пользователь ожидает от дашборда поведение обычного сайта. Поэтому переиспользуйте паттерны поведения веба: подчеркнутые ссылки, использование навигации через браузер (если позволяет BI система) и т. п. Почитать про паттерны, можно в этой статье.

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

При этом адаптивность может быть довольно простой. Например, просто меняется расположение основных блоков и их их размеры. Что-то такое:

Маленький монитор

Первые два блока стоят горизонтально

Большой монитор

При увеличении экрана они перемещаются в вертикальное положение

Цели пользователя

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

Узнать что-то про определенную сущность (заранее знаю, что хочу увидеть). Сюда же относятся эд-хоки по поиску конкретных метрик.
Получить какой-то инсайт, не зная, что именно ищу. Или сделать выводы, имея в голове определенный алгоритм поиска. То есть провести классический анализ данных.
Отслеживать операционные данные на «ежедневной» основе. Те самые классические дашборды и ситуационные центры.

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

Ожидания в целом

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

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

Задачи пользователя в интерфейсе

Для достижения целей пользователь формирует задачи (посмотреть города «А» из всех городов) и ищет действия для реализации задач в интерфейсе программы (выбрать в выпадающем списке город «A» и нажать apply). Тут как всегда всё будет сильно индивидуально, но в BI среде чаще всего нужны следующие задачи:

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

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

Эти действия должны быть одинаковыми от отчета к отчету (если включили кнопку apply, то включайте во всех-всех отчетах для фильтров с мультивыбором).
Лучше всего, если это общепринятые действия и паттерны, свойственные платформе. Для веба это подчеркнутые ссылки, выделение интерактивных элементов и т. п.
Если не получается использовать общепринятые паттерны (например как с Табло из-за кучи ограничений в самой системе), то всегда помогайте пользователю в этом месте и формируйте новую привычку. Но, опять же, одинаковую для всех отчетов. Например, если можно фильтровать данные с помощью клика в график, добавьте иконку или описание про это.

Вместо заключения

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

Лайфхаки Tableau #2

Wed, 24 Jun 2020 09:50:37 +0200

0:00 — UTF символы для создания цветовой легенды
3:29 — Динамический фильтр дат с окном и ренджем
7:08 — Подпись событий о запусках или маркетинговых активностях во времени на таймсерии

Видеоподкаст с Александром Варламовым

Tue, 09 Jun 2020 09:37:10 +0200

Записал подкаст с Александром Варламовым, автором блога Coul Blue Data и классного профиля в Табло Паблик.

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

0:43 — Карьерный путь и как пришёл в дата-арт
11:17 — Что нравится в работе
16:25 — Дженерализация vs Специализация в BI
22:08 — Self-service vs Dashboard factory
28:06 — Какие навыки нужны BI специалисту
31:19 — Пример работы Саши с разбором в Табло
50:29 — Зачем следит и где вдохновляется
53:30 — Зачем вести Паблик и заниматься дата-артом BI специалисту
55:47 — Блиц

Лайфхаки Tableau

Sun, 07 Jun 2020 14:29:43 +0200

Последние четыре года я много работаю с Табло. Оно стало основным инструментом визуализации, который я использую как для работы, так и для фана. До этого все визуализации я прогал на js, например, что-то такое вакансии с hh.ru, сравнение стран, бюджет США. Визуализации на js — это потрясающе гибкие и шустро работающие штуки, но время их создания иногда зашкаливает. Хотя библиотеки типа d3.js и фреймворков типа vue.js помогают делать их быстрее, но всё равно это каждый раз долго (может я просто не программист, но даже классные программисты, с которыми я работал, так быстро делать визы не могут). Поэтому теперь я работаю в Табло, из всех WYSIWYG инструментов он самый гибкий и позволяет делать классные работы довольно быстро, а иногда очень быстро.

Знание инструмента является одним из 8 навыков, необходимых, чтобы делать классную визуализацию. Хотя я и считаю его наименее важным из всех, так как сегодня один инструмент, а завтра другой, но всё равно стараюсь прокачивать и этот навык. В основном, конечно, за счет практики, но ещё я слежу за новостями, учусь и обучаю других.

Я никогда не хотел делать много контента про изучение инструмента, так как для этого существует отличные учебные материалы на официальном сайте Табло. Чтобы понять основы и познакомиться с интерфейсом этого хватит за глаза. Но при этом есть много мелких и интересных лайфхаков, приёмов и т. п., которые делают жизнь с Табло намного приятнее. Их я собираю по всяким статьям, видео, от коллег, а что-то придумываю сам. Хочу попробовать запустить формат коротких видео с лайфхаками на каких-то бизнесовых примерах. Видео будут ориентированы на тех, кто уже работает с Табло. Лайфхаки буду собирать и из интернета, и из своей практики. Сколько времени мне сэкономила, например, фича перетягивания даты через правую кнопку мыши или дублирование поля с ctrl/cmd, а узнаешь про это обычно случайно.

Вот пилотный выпуск, пишите идеи и пожелания.

0:00 — Сортировка по значению за последний месяц с помощью nested table calcs
4:04 — Оформление спарклайнов при помощи reference lines
7:12 — Highlighted таблица с подсветкой по одной метрике из measure values

Reveal the Data: заметки с тегом табло

Навигация между дашбордами в Tableau

Переходы с фильтрацией

Статичные ссылки на графиках

Кнопки и ссылки

Вкладки

Зум для графика

Итого

Итоги первого сезона «Залетай в BI»

Оптимизация работы отчетов

Проверка гипотезы 1

Проверка гипотезы 2

Итого

Порядок операций при работе с Relationships

Особенности работы функции TOTAL()

TOTAL() игнорирует дименшены в виде

Grand Total использует TOTAL()

Итого

LODы, порядок операций и как работает Табло

Как работают LODы и Табло в целом

Порядок операций

Шпаргалка по Quick Table Calculations

Задание

Решение

Running total (Включает в себя быстрые YTD total, YTD growth)

Difference from

Percent difference from и Year over Year growth rate

Percent from

Percent of total

Rank

Percentile

Moving calculation

Дополнительные материалы

Последовательный выбор двух параметров одним экшеном

Шаблон дашборда для Эгеи

Переверстка в Power BI

Выравнивание по центру

Правило контраста и иерархии

Правило близости, правило внутреннего и внешнего

Фильтры без аналитики

Power BI vs Tableau

Выводы

Все населённые пункты РФ

Список лайфхаков Табло

Итогов года пост 2020

Telegram

YouTube

Блог и сайт

Подборка самых важных и полезных авторских материалов за год по моему мнению

Tableau Public

Личная статистика

Адаптивная верстка в Табло

Масштаб текста в Windows и Tableau

Алгоритм разработки дашборда — Dashboard Canvas

Интерфейсы в BI системах

Ментальная модель

Ожидания от продукта

Навыки

Контекст использования

Платформа

Цели пользователя

Ожидания в целом

Задачи пользователя в интерфейсе

Вместо заключения

Лайфхаки Tableau #2

Видеоподкаст с Александром Варламовым

Лайфхаки Tableau