Есть сайт motul.com и множество сайтов-сателлитов, на которых есть несколько продуктов для пользователей:
— Подбор машинного масла.
— Сопутствующие товары по марке авто.
— Подбор реселлера.
— Продуктовые страницы с товарами конкретных марок и брендов.
Поскольку источников данных множество, маркетинговая команда тратила много времени на сведение данных из разных источников — о метриках всех сайтов, об активности бренда в соцсетях.
Наша задача — собрать дашборд с верхнеуровневыми KPI для топ-менеджмента и дать командам возможность анализировать поведение пользователей на сайте: построить конверсионные воронки по основным продуктам, дать инсайты по популярности продуктов по странам присутствия Motul.
Для начала нам нужно получить набор данных для анализа.
В качестве хранилища данных мы используем BigQuery. Источников данных у нас 8: 6 сайтов Motul, данные rest API сайта с мета-информацией о контенте продуктовых страниц и данные Hookit об активности в соцсетях.
Для загрузки данных мы используем стек технологий Singer + Meltano.
После анализа сырых данных мы увидели неприятную особенность: в Google Analytics не всегда реализован трекинг событий, в большинстве случаев доступны только данные о просмотрах страниц с URL’ами страниц. При этом нам нужна статистика по просмотрам в разрезе по товарам, товарным категориям и брендам авто/мото.
Стало понятно, что надо искать способ обогатить массив сырых данных недостающей информацией, прежде чем получится вывести данные на дашборд.
Для проектирования модели данных мы используем Минимальное Моделирование — подход, который позволяет одновременно разобраться в структуре данных и задокументировать ее.
— Анкеры (это основные существительные предметной области, например, пользователь, ?страница, бренд и т.п.).
— Атрибуты (это характеристики анкеров, например, название страницы, дата регистрации пользователя и т.п.).
— Линки (связи между двумя анкерами, например, «пользователь открыл страницу»).
Найденные анкеры, атрибуты и линки мы сразу же документируем в Excel-файле. То есть описание финальных данных появляется раньше реализации.
Наша модель данных выглядит вот так:
Например, выяснить, что пользователь смотрел товар определенной категории можно только разобрав параметры из URL cтраницы. При этом схема URL’ов в разных частях сайта отличается.
На уровне физической реализации все анкеры, атрибуты и линки независимы друг от друга. Мы их собираем в виде отдельных таблиц в базе.
Такой подход сильно упрощает тестирование данных: по сути, мы видим полный граф трансформаций каждого атрибута, поэтому если замечаем ошибку в данных, то можем проверить трансформации вплоть до сырых данных.
Также если каждый атрибут — это независимая таблица с данными в БД, то к задаче можно подключить сразу несколько аналитиков, которые могут работать над реализацией атрибутов параллельно.
Реализованные в виде независимых таблиц анкеры, атрибуты и линки мы называем Data API, потому что, по сути, это интерфейс к данным заказчика, с которым могут работать BI-отчеты, ML-модели и другие приложения.
Поверх данных Data API мы собираем широкие таблицы, которые подходят для отрисовки отчетов в PowerBI.
Если мы дорабатываем логику работы с сырыми данными, мы меняем только логику в Data API, а данные всех широких таблиц для репортинга пересчитываются автоматически.
Этап 5: Визуализация данных в PowerBI
— Автоматизировали отчетность по основным KPI.
— Построили конверсионные воронки по продуктам.
— Настроили единый дашборд из всех источников с возможностью анализировать поведение пользователей на сайте.
— Проконсультировали заказчика по дальнейшим действиям по развитию digital-продукта.