дашборды
в powerbi
web-аналитика

motul

собрали дашборд с верхнеуровневым KPI для топ-менеджмента и дали командам возможность анализа пользователей на сайте
задача
Карточка товара в качестве примера
Есть сайт motul.com и множество сайтов-сателлитов. На сайтах есть несколько продуктов для пользователей: подбор машинного масла и сопутствующих товаров по марке авто, подбор реселлера, продуктовые страницы с товарами конкретных марок и брендов.

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

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

В качестве хранилища данных мы используем BigQuery. Источников данных у нас 8: 6 сайтов Motul, данные rest API сайта с мета-информацией о контенте продуктовых страниц и данные Hookit об активности в соцсетях.

Для загрузки данных мы используем стек технологий Singer + Meltano.
Скачивание «сырых» данных
01
После анализа сырых данных мы увидели неприятную особенность: в Google Analytics не всегда реализован трекинг событий, в большинстве случаев доступны только данные о просмотрах страниц с URL’ами страниц. При этом нам нужна статистика по просмотрам в разрезе по товарам, товарным категориям и брендам авто/мото.
Моделирование данных
02
Стало понятно, что надо искать способ обогатить массив сырых данных недостающей информацией, прежде чем получится вывести даныне на дашборд.
Для проектирования модели данных мы используем Минимальное Моделирование (minimalmodeling.com) – подход, который позволяет одновременно разобраться в структуре данных и задокументировать ее.

В результате моделирования мы выделяем в данных:

  • Анкеры (это основные существительные предметной области, например, Пользователь, Страница, Бренд итп)
  • Атрибуты (это характеристики анкеров, например, название страницы, дата регистрации пользователя итп)
  • Линки (связи между двумя анкерами, например, “пользователь открыл Страницу”).
Найденные анкеры, атрибуты и линки мы сразу же документируем в excel-файле: то есть, описание финальных данных появляется раньше реализации.
Наша модель данных выглядит вот так
Несмотря на то, что модель простая с логической точки зрения, установить связи между некоторыми частями данных оказалось тяжело.
Например, выяснить, что пользователь смотрел товар определенной категории можно только разобрав параметры из URL cтраницы. При этом схема URL’ов в разных частях сайта отличается.
Для нормализации данных, мы написали правила разбора URL‘о-в страниц и связи каждого url’а с соответствующим продуктом, моделью, категорией из rest api сайта.

В терминах минимального моделирования каждая такая связка (линк) страница→продукт, страница→модель, страница→категория — это независимые таблицы. Благодаря независимости этих таблиц мы реализовали довольно сложную логику разбора url’ов с учётом множества нюансов в данных. В результате почти 90% просмотров страниц сайта было обогащено необходимой информацией.
TBD пояснение
Реализация
data API
03
На уровне физической реализации все анкеры, атрибуты и линки независимы друг от друга. Мы их собираем в виде отдельных таблиц в базе.

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

Реализованные в виде независимых таблиц анкеры, атрибуты и линки мы называем data api, потому что по сути это интерфейс к данным заказчика, с которым могут работать BI-отчеты, ML-модели и другие приложения.
Сбор витрины для PowerBI
04
Поверх данных data api мы собираем широкие таблицы, которые подходят для отрисовки отчетов в PowerBI.
Если мы дорабатываем логику работы с сырыми данными, мы меняем только логику в data api, а данные всех широких таблиц для репортинга пересчитываются автоматически.
Визуализация данных в PowerBI
05
Поверх данных data api мы собираем широкие таблицы, которые подходят для отрисовки отчетов в PowerBI.
Если мы дорабатываем логику работы с сырыми данными, мы меняем только логику в data api, а данные всех широких таблиц для репортинга пересчитываются автоматически.
Что получилось в итоге
В результате проекта:
  • скачали данные из всех источников заказчика, обогатили сырые данные информацией, необходимой для отчетов;
  • автоматизировали отчетность по основным kpi
контакты AGIMA AI
107031, г. Москва, ул. Петровка, д. 19, стр. 4
hello@agima.ai
Теперь вы знаете, где нас искать
Обычно мы работаем с 10 до 19
Политика конфиденциальности
© Все права защищены