AGIMA — The largest digital integrator

Задача

Есть сайт motul.com и множество сайтов-сателлитов, на которых есть несколько продуктов для пользователей:

Подбор машинного масла.
Сопутствующие товары по марке авто.
Подбор реселлера.
Продуктовые страницы с товарами конкретных марок и брендов.

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

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

Решение задачи

Этап 1: Скачивание «сырых» данных

Для начала нам нужно получить набор данных для анализа.

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

Для загрузки данных мы используем стек технологий Singer + Meltano.

Этап 2: Моделирование данных

После анализа сырых данных мы увидели неприятную особенность: в Google Analytics не всегда реализован трекинг событий, в большинстве случаев доступны только данные о просмотрах страниц с URL’ами страниц. При этом нам нужна статистика по просмотрам в разрезе по товарам, товарным категориям и брендам авто/мото.

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

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

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

Анкеры (это основные существительные предметной области, например, пользователь, ️страница, бренд и т.п.).
Атрибуты (это характеристики анкеров, например, название страницы, дата регистрации пользователя и т.п.).
Линки (связи между двумя анкерами, например, «пользователь открыл страницу»).

Найденные анкеры, атрибуты и линки мы сразу же документируем в Excel-файле. То есть описание финальных данных появляется раньше реализации.

Наша модель данных выглядит вот так:

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

Этап 3: Реализация Data API

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

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

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

Реализованные в виде независимых таблиц анкеры, атрибуты и линки мы называем Data API, потому что, по сути, это интерфейс к данным заказчика, с которым могут работать BI-отчеты, ML-модели и другие приложения.

Этап 4: Сбор витрины для PowerBI

Поверх данных Data API мы собираем широкие таблицы, которые подходят для отрисовки отчетов в PowerBI.

Если мы дорабатываем логику работы с сырыми данными, мы меняем только логику в Data API, а данные всех широких таблиц для репортинга пересчитываются автоматически.

Этап 5: Визуализация данных в PowerBI

Результат

Автоматизировали отчетность по основным KPI.
Построили конверсионные воронки по продуктам.
Настроили единый дашборд из всех источников с возможностью анализировать поведение пользователей на сайте.
Проконсультировали заказчика по дальнейшим действиям по развитию digital-продукта.