Как мы в Авито сделали карту дашбордов и избавились от хаоса в отчётах

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

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

Почему решили сделать карту дашбордов

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

Для быстрого доступа к данным аналитики создают дашборды, которые находятся в разных проектах. Обычно сотрудники добавляют важные отчёты в избранное или ведут командные Excel-файлы, которые потом передают между собой. Некоторые закрепляют ссылки на дашборды в чатах.

Однако такую систему было неудобно поддерживать и масштабировать по следующим причинам:

Не было единой точки входа: общей папки «Отчеты» или логики для поиска нужного.

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

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

Отсутствие мета-информации. Без документации было сложно понять, для кого создан отчёт, и какие метрики на нём выведены.

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

Теперь расскажем о нашем подходе к этой задаче.

Какие отчёты взяли на карту

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

Посмотрели, что часто открывают. Изучили логи Redash и узнали статистику по просмотрам.

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

Сгруппировали деши на основании информации от коллег 
Сгруппировали деши на основании информации от коллег 

Что в итоге

Мы создали консолидированный список дашбордов на основе статистики по просмотрам и обратной связи пользователей — с ним мы будем работать дальше. Объекты, к которым не обращались последние два месяца, мы поместили в архив.

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

Как подготовили данные и собрали лендинг

Изучили и описали каждый дашборд. Мы вручную прошлись по всем объектам из списка, который собрали на прошлом этапе, чтобы:

  • Устранить дубли
  • Актуализировать источники
  • Описать деши
  • Разделить их на группы

Это оказалось самой трудозатратной частью работы — мы потратили около недели, уделяя задаче 50% рабочего времени. В итоге получили список из ста объектов с однородными метаданными.

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

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

Реализовали лендинг с помощью связки: Redash + МойОфис. Кратко о нашем инструментарии:

👉 Redash — это наша основная BI-платформа. С её помощью мы анализируем данные, создаём визуализации и дашборды. А внутренняя команда Redash постоянно развивает платформу и непрерывно совершенствует продукт.

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

Технически лендинг устроен так:

— Мы ведём список всех объектов и метаданные о них в МойОфис, откуда они импортируются в хранилище.

Храним список объектов и метаданных в МойОфис 
Храним список объектов и метаданных в МойОфис 

— Сверстали шаблон веб-страницы (html/css), который наполняем данными.

—C помощью Python заполняем полученный шаблон данными. В Redash есть функция создания визуализаций на Python, что даёт нам свободу в разработке нестандартных приборов.

Что в итоге

Благодаря гибкости и возможностям Redash мы нашли способ быстро реализовать карту в виде веб-страницы. Добавить новый объект можно за ≈час — достаточно заполнить метаданные в табличке через МойОфис.

Как карта выглядит для пользователя и что в ней можно делать

Для пользователей эта страница выглядит как набор карточек, в шапке страницы — фильтры:

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

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

Например, сотрудник отдела продаж может сразу выбрать в фильтрах вертикаль Авито Работа, юнит Avito Sales Department и подходящую папку.

Можно фильтровать и по другим метаданным

Чтобы искать было ещё проще, можно настроить больше фильтров — указать роль сотрудника и метрики, которые должны быть в отчёте.

Все фильтры можно настроить, чтобы быстрее найти то, что нужно 
Все фильтры можно настроить, чтобы быстрее найти то, что нужно 

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

Карточки устроены однородно, поэтому по ним удобно ориентироваться. В каждой есть такие поля:

  • Название отчёта
  • Счётчик уникальных пользователей за последние 14 дней
  • Картинка деша
  • Его описание
  • Группы сотрудников, для которых он предназначен
Как устроена карточка отчёта
Как устроена карточка отчёта

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

Раздел «Прочее» — там и непопулярное 
Раздел «Прочее» — там и непопулярное 

Что в итоге

Мы систематизировали наши дашборды с помощью продукта, которым потенциально смогут пользоваться все сотрудники Авито. Сейчас о карте уже знают все в Работе, средний MAU — 200 человек.

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

По пути мы получили ещё несколько положительных эффектов:

⭐ Актуализировали отчётность. Мы не только собрали всё в одном месте, но ещё нашли и архивировали неиспользуемые данные.

⭐ Создали единую точку входа в отчётность. Теперь все сотрудники знают, где искать дашборд или воркбук, и могут быстро получить доступ к нужным данным.

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

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

Качество работы с данными возросло — стало проще ориентироваться в большом количестве отчётов. Новые инструменты сразу стали доступны пользователям, что улучшило доставляемость аналитики и сократило время на поиск.

55
реклама
разместить
2 комментария

Классная реализация, спасибо за подробную статью! Наличие портала для отчетов — это действительно необходимость в data-driven-компании, еще и с возможностью фильтрации и просмотра популярности дашбордов.

Подскажите, пожалуйста, сколько человек в вашей BI-команде и как долго они работали над этим проектом? Например, сколько человек описали около 100 объектов с метаданными за 20 часов (50% рабочего времени от недели) и как долго разработчик писал скрипт и настраивал интеграцию?

Алиса, добрый день!

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

3