AGIMA — The largest digital integrator

Задача

Стандартная задача маркетинга: построить сквозной отчёт от клика пользователя по рекламному объявлению до покупки и оценить эффективность маркетинговых кампаний.

Есть несколько рекламных кабинетов, из которых нужно собрать затраты на рекламные кампании: Facebook, Yandex.Direct, Google Adwords, Vkontakte. Также есть затраты на маркетинг, которые не проходят через рекламные кабинеты, а ведутся в ручном справочнике.

Пользователи, которых привлекли с помощью рекламных кампаний, совершают покупку на сайте.

На сайте установлен Google Analytics, который фиксирует id пользователей, их utm-метки и покупки.

Хотя задача кажется стандартной, есть несколько нюансов в бизнес-логике, из-за которой стандартные решения не подошли:

Из-за особенностей маркетинговой стратегии нужно реализовать кастомную логику атрибуции.
Отчет нужен в разрезе по рынку пользователя (ru/en), при этом критерии того, к какому рынку относится пользователь, довольно сложные.

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

Нам нравится, когда подготовленные для конечных отчетов данные доступны пользователям в режиме self-service аналитики (то есть, аналитики самообслуживания). В этом случае маркетологи, менеджеры, финансисты и другие бизнес-пользователи могут «накликать» себе нужный отчет в BI-инструменте, без необходимости писать SQL или другой код.

Такой подход значительно увеличивает доступность данных и, соответственно, качество выводов, которые бизнес-пользователи могут извлечь из данных самостоятельно.

Чтобы подготовленные данные действительно можно было использовать, нужно (и очень важно!), чтобы эти данные были хорошо документированы.

Скачивание «сырых» данных

В качестве хранилища данных мы используем BigQuery. Источников данных у нас девять. Для загрузки данных используем open source стек Singer + Meltano. Для преобразования данных используем DBT.

Моделирование данных

Для проектирования self-service витрин мы используем минимальное моделирование (minimalmodeling.com) – подход к моделированию данных, который позволяет одновременно разобраться в структуре данных и задокументировать ее.

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

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

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

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

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

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

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

Граф трансформаций для линка «Объявление AdWords привело к визиту». Видно, какие атрибуты используются при вычислениях, и что именно рассчитывается на основании этого линка впоследствии.

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

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

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

Как работает модель данных, всё в сборе:

Сбор витрины для self-service аналитики

Для отчетности мы используем бесплатный инструмент с открытым исходным кодом Metabase.

Для подготовки витрины для self-service аналитики в Metabase, мы прежде всего собираем все данные, доступные в data api в несколько связанных широких таблиц:

Таймлайн со всеми событиями системы, который мы собираем из всех линков, которые мы нашли на этапе моделирования данных.
Широкая таблица на каждый анкер, в которую мы собираем все атрибуты анкера.

Связи между этими таблицами мы задаём прямо в Metabase.

Определение метрик

Теперь, когда все данные и витрина собраны, осталось посчитать по ним бизнес-метрики.

Собираем финальный отчёт

Теперь, когда все данные собраны и метрики определены, осталось собрать финальный отчёт.

Мы это делаем без написания sql, просто накликивая данные в Metabase.

Документация и ответы на вопросы заказчиков

Под конец проекта приводим в порядок документацию. Это просто, поскольку все данные мы описали в самом начале проекта на этапе моделирования данных. Проверяем опечатки и возникшие расхождения при реализации.

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

Выводы и следствия из реализации

В результате проекта реализовали отчетность по сквозной маркетинговой аналитике.

Данные доступны бизнес-пользователям в режиме self-service аналитики (аналитики самообслуживания).

Из-за реализации с помощью концепций минимального моделирования, получили ряд интересных следствий:

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