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’ов в разных частях сайта отличается.

Реализация
data API

03

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

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

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

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

Сбор витрины для Power BI

04

Поверх данных data api мы собираем широкие таблицы, которые подходят для отрисовки отчетов в Power BI.

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

Визуализация данных в Power BI

05