Rose debug info
---------------

Reveal the Data

Блог Ромы Бунина о визуализации, Tableau и развитии BI-систем
канал в телеграмме | подборки примеров | подкасты и видео

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка гипотезы 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

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

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

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

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

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

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

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

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

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

 Нет комментариев    10279   4 мес   табло

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

Статья подготовлена в рамках сериала «Залетай в 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ы, порядок операций и как работает Табло

Статья подготовлена в рамках сериала «Залетай в 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

Статья подготовлена Русланом и немного подредактирована мной. Материал создан рамках менторства и прокачивания навыков Руслана как 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
  • Выборка задается окном «от и после» текущего значения
  • Текущее значение и случаи когда не нет полных данных для окна можно исключать.

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

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

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

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

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

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

Давайте рассмотрим как это сделать. Эта инструкция подойдёт только для данных в широком формате, при подключении статичных файлов перевернуть таблицу можно при помощи встроенной функции 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 раз. =)

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

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

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

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

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

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

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

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

Визуализация процессов

Yet another post «Why dataviz matter». Пост из этой же серии про моего пса и змею.

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

История

Проект на газодобывающем предприятии — необходимо понять, что мешает работе и почему часто есть проблемы и простои оборудования на месторождении. Проводим первичный анализ и понимаем, что часто не хватает нужных запчастей. Разбираемся почему так происходит — оказывается процесс закупки (только договор + оплата, без доставки) может достигать до 70 рабочих дней! Топы предприятия не верят, что ситуацию можно как-то исправить и считают, что процесс закупки построен нормально.

Рисуем карту потока с рабочей группой

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

Печатаем карту

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

Это было одно из самых прикольных совещаний за мою карьеру — надо было видеть как удивились и сразу поняли все присутствующие неоптимальность процесса. Сразу увидели кучу блоков согласований, выстраивающихся в колонки на карте и потряслись самим масштабом процесса. У меня было полное ощущение, что случился «Aha-moment» и «Now you see it».

Улучшаем процесс

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

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

Обзор стандарта IBCS

Давно хотел написать про этот стандарт, а тут выдался отличный повод — Антон Жиянов сделал отличную, читаемую версию этого стандарта. Антон, большое спасибо! Ещё у Антона куча крутых статей про проектирование интерфейса.

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

Что такое IBCS (International Business Communication Standards)

Этот стандарт разработан Рольфом Хикертом, бывшим консультантом McKinsey и CTO нишевой немецкой BI-системы MIS. Основная идея стандарта — практические советы и семантические стандарты по дизайну отчетов и графиков. Стандарт распространяется бесплатно и доступен на сайте www.ibcs.com, но сделан там в очень неудобном формате. Почему так — думаю, что для того, чтобы заработать на продаже нормальной pdf версии, которая есть на сайте =) В целом это нормально и такие организации зарабатывают как раз на материалах, сертификациях и тренингах. Но выглядит это конечно немного смешно.

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

1. Convey a message

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

2. Organize content

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

3. Choose proper visualization

Это раздел является классическим «чарт-чузером» для выбора подходящего типа диаграмм. Очень понравилось, что автор сводит задачи по-сути всего к двум типам — изменение во времени и сравнение категорий. В целом это реально 90% бизнесовых задач, которые можно решить и правда небольшим количеством графиков. Правда совсем не хватает точечного графика, фактоидов (KPI’s) и спарклайнов. И ещё сама стилистика графиков прям кричит на тебя тем, что рассчитана на печать и супер строгий минимализм. Я сам люблю минимализм, но тут он выглядит сильно outdated именно стилистически.

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

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

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

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

А ещё стандарт не толерантный и прям запрещает делать некоторые виды графиков. ;—)

4. Avoid clutter

Следующий раздел полностью посвящен удалению non-data-ink. Тут не знаю, что особо сказать. Хорошие примеры, но довольно очевидные — убирайте лишнее и редактируйте текст.

5. Increase information density

Следующий раздел обратный — про повышение количества data-ink на графиках.

Здесь понравились те вещи, про которые я сам часто говорю, но мало где слышу. Что стоит увеличивать кол-во срезов, метрик и дат, не бояться уменьшать размеры графиков и делать таблички с встроенными графиками.

Не понравилось, что предлагают делать двойные оси и не очень понятные виды графиков.

6. Ensure visual integrity

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

Но очень сильно смутило предложение делать что-то подобное:

7. Apply semantic notation

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

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

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

Идея № 1. Использовать для базовых метрик (данных) и расчетных метрик разные толщины линий и бар-чартов. Затея выглядит интересной, но пока не могу понять стоит ли того. И это точно сложно реализовывать и поддерживать. Но сама идея такого деления, по-моему, очень необычная.

Идея № 2. Использовать для обозначения факта, плана. прошлого периода и прогноза всегда одинаковые визуальные оформления. Факт — темная сплошная заливка, План — «пустотелая» заливка, Прошлый период — серая сплошная заливка, Прогноз — штриховка. Кажется, что это тоже очень прикольная идея. Такие «сценарии» существуют во всех бизнесах и это правда очень удобно. Но смущает реализация со  штриховкой и «пустыми» маркерами для линий плана.

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

Идея № 3. Использовать для разных скейлов, разные ширины баров. По-моему довольно элегантно. Хотя реализация снова будет довольно сложной.

Идея № 4. Использовать для абсолютных отклонений бар-чарты, для процентных пин-чарты (аля лолипопы). Всегда показывать оба сравнения для всех пар план-факт, факт-прогноз и т. п. Мне здесь больше всего нравится именно разделение абс. отклонений и процентных. Кажется, что довольно элегантное решение. Только сами пин-чарты мне не нравятся, делал бы вместо них, например, стандартные лолипоп-чарты.

Идея № 5. Для стандартных бизнесовых периодов типа YTD, MAT и т. п. завести отображение символами, чтобы быстро их показывать на графиках и таблицах. Мне этая идея очень нравится, как идея. Но всё-таки в реальном использовании я бы всегда писал начало и конец периода Jan’18 … Jan’19 и т. п. Мы у себя в стандарте делаем именно так.

Выводы и общие впечатления

Стандарт мне нравится. Это отличная сводка правил и интересных находок. Очень простая и понятная подача из свода правил и карточек формата «Don’ts and Dos». Он точно не подходит в формате «как есть» для дашбордов, есть спорные моменты и рекомендации и устаревший визуальный стиль. Используется через чур мало цветом, хотя очень круто, что основной — черный (мы у себя сделали так же). В целом много интересных идей, рекомендую к прочтению.

По-мимо самого стандарта на сайте есть ещё и гайдлайны. Можно прям брать и делать внутренние рекомендации по аналогии.

Есть неполные, но довольно близкие, реализации стандарта в Табло.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Power BI vs Tableau

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

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

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

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

Выводы

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

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

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

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

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

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

Видеоподкаст c Анастасией Кузнецовой

Записал подкаст с Анастасией Кузнецовой, автором канала Настенька и графики (если ещё не подписаны, то очень рекомендую).

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

Аудиоверсия
Текстовая версия — под видео (спасибо Наташе Shirosayuri!)

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

Я скорее называю себя свободным аналитиком, не привязываюсь к какому-то определению. Или, например, говорю, что я автор телеграмм-канала. Дата-визуализатором я себя не называю, всё же скорее ближе к аналитике.

По образованию я социолог. Когда я поступала, то ничего не знала про это. На профтестах мне сказали, что я люблю вставлять данные в таблички и я поняла, что это правда моё. Я пошла в Вышку на социологию, эта программа сейчас называется «Социология и социальная информатика». Там больше уклон на computational social of science, на все, что связано и с анализом данных, и в том числе с визуализацией. Там мы учили программирование на R, на третьем курсе немного Tableau, хотя очень поверхностно. В дальнейшем я увидела, насколько больше там глубины на самом деле. Ну и когда занималась научными исследованиями, часто данные просто визуализировала и был такой больше описательный анализ.

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

7:12 Про работу аналитика клиентских данных
Основными моими обязанностями сейчас является построение дашбордов, к сожалению, пока что в data studio. И обычная, в общем, аналитика, подсчёты каких-либо моделей, показателей, проведение тестов. То есть анализирую все данные, которые есть, а их много: и crm, и логи, и опросные данные.Также я преподаю в Вышке и Европейском университете визуализацию данных и веду свой канал.

8:34 Зачем аналитику нужно знать основы дизайна
Я пропагандирую идею, что визуализация данных это больше про коммуникацию. У меня есть пост в блоге про датасатанистов, которые говорят на каких-то своих языках, и другим людям в компании не понятно, что происходит. Поэтому я выступаю за то, чтобы сделать всё максимально понятным и удобным. Базовые навыки предоставления информации должны присутствовать. От того, что ты покажешь результаты своего регрессионного анализа табличкой, никому понятнее не станет. Все результаты лучше визуализировать. Хотя я не могу сказать, что всегда соблюдаю свои же принципы, потому что многие вещи приходится делать в спешке. Правда, потом я к ним возвращаюсь, чтобы что-то сделать лучше.

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

13:14 Наука в северной Корее

Это первая работа в моей визуализаторской карьере про науку в Северной Корее. Так как я занималась до этого библиометрией, я решила посмотреть на неё. Данные я брала из web of science, это база научных журналов высокого уровня. Тут есть интересные вещи, например, про финансирующие агентства, где есть какие-то китайские организации, а ещё сети соавторства и карты терминов. Это сделано при помощи VOSViewer. Как оказалось, темы северокорейских учёных очень технические. А в сетях соавторства оказалось, что 39 из 265 авторов зовут «Ким». Ещё было про языки публикации, например, 3 на русском, до распада СССР. У исследователей из Северной Кореи есть некоторая свобода: им предоставляется интернет, а это уже достаточно много. Очень интересно, про что они пишут и как осуществляется их общение. Можно увидеть, как меняется развитие тематик, по цвету сети: сразу больше писали про физику, а позже стали популярнее молекулярные исследования и генетика.

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

20:25 Граф для связей в ВК

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

23:50 Музыка в ВК

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

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

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

Облако слов в плане аналитики даёт примерно ничего, но все любят на них смотреть, и я в том числе, оно скорее для красоты.

У ВК есть возможность запросить архив, чтобы узнать, какие у них есть данные про вас. Там сохраняются все сообщения, лайки, комментарии. Можно либо посмотреть на свои сообщения 10 года и ужаснуться, либо вот, собрать из них такие красивые визуализации.

35:05 Сравнение пенсий

Мне однажды скинули статью про сравнение пенсий по странам, в которой данные были представлены просто текстом. Поэтому я решила их визуализировать. Здесь барчарты и картинки про средний возраст жизни и размер пенсии. Это данные на 2018 год, уже могло что-то поменяться. Так же я посмотрела, сколько бигмаков можно купить на эту пенсию. Мне очень нравится индекс бигмаков для сравнения таких вещей. Получается, что в Дании самая большая пенсия, можно купить целых 689 штук, а в России всего лишь 100, то есть 3 с лишним в день.

33:00​ Дашборд рулетка
35:05​ — Социальное неравенство в США
43:44​ — Вкус рождества
54:50​ — Торнадо

1:05:22 За чем следит и что почитать
Из того, зачем я слежу, это Flowing Data и Visual Cinnamon. Ещё очень много пабликов в телеграмме, я за ними за всеми слежу, это и Чартомойка, и Reveal the Data, и Дашбордец. Ещё в твиттере очень много интересного публикуют.

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

1:07:20 Блиц
Москва или Питер? — Питер.
Google Studio или Tableau? — Когда как. Tableau для души, Google Studio для скорости.
Tableau или R или ggplot? — Если Tableau или ggplot, то Tableau, если Tableau или R, то R.
Тафти или Босток? — Тафти.
BI или дата арт? — Дата арт, потому что для души.

Ссылки, которые рекомендовала Настя:
https://flowingdata.com
https://www.visualcinnamon.com
https://medium.com/@kennelliott/39-studies-about-human-perception-in-30-minutes-4728f9e31a73

Книги:
— Дизайн привычных вещей: https://www.mann-ivanov-ferber.ru/books/dizajn-privyichnyix-veshhej/
— Storytelling With Data: A Data Visualization Guide for Business Professionals: https://www.amazon.com/Storytelling-Data-Visualization-Business-Professionals/dp/1119002257
— Better Data Visualizations: A Guide for Scholars, Researchers, and Wonks: https://policyviz.com/pv_books/better-data-visualizations-a-guide-for-scholars-researchers-and-wonks/

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

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

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

Выпуск №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 — Подсветка выходных

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

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

Telegram

Начну с Телеграма. Данные собрал из 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

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

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

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

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

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

Ранее Ctrl + ↓