Собрали дашборд с основными 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

В результате проекта:

• скачали данные из всех источников заказчика, обогатили сырые данные информацией, необходимой для отчетов;
• автоматизировали отчетность по основным KPI.