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

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

В этой статье расскажем, как подойти к задаче построения сквозной маркетинговой аналитики “с нуля” таким образом, чтобы:

• данные были хорошо документированы;

• в полученные отчеты было легко добавлять любые фильтры и разрезы: в том числе, по новым атрибутам пользователя, по сегментам АВ-тестирования, по языкам и т.п.

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

Рассказ будем вести на примере одного из реализованных клиентских проектов.

Задача

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

Если подробнее:

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

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

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

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

• Из-за особенностей маркетинговой стратегии нужно реализовать кастомную логику атрибуции и оценить каждый канал по двум моделям: кастомной и стандартной last click;

• Есть ряд особенностей бизнес-логики, которые нужно учитывать при выстраивании связи маркетинговых каналов с покупками: например, языки пользователей; 

• На сайте проводятся АВ-тесты, поэтому хотелось, чтобы в будущем конверсии по рекламным каналам можно было смотреть в том числе в разрезе по сегменту тестирования, в который попал пользователь. 

Как мы организовали процесс

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

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

В качестве хранилища данных мы используем BigQuery. Источников данных у нас девять.

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

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

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

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

• ⚓️Анкеры (это основные существительные предметной области, например, ⚓️Пользователь, ⚓️Визит, ⚓️Рекламная кампания и т.п.).

• Атрибуты (это характеристики анкеров, например, Имя пользователя, Дата визита, Название рекламной кампании).

• ????Линки (связи между двумя анкерами, например, “????⚓️Пользователь сделал ⚓️Заказ”).

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

Теперь собираем модель предметной области. Для сквозной аналитики она вполне понятна и выглядит так:

Моделирование кастомной атрибуции 

Основным понятием (анкером) в системе является ⚓️Визит (visit) пользователя.

У ⚓️Визита есть два атрибута, которые содержат информацию о кастомной маркетинговой атрибуции:

• номер визита (visit_number);

• ценность визита (visit_value).

Как только ⚓️Визит приводит к ⚓️Транзакции, мы делим выручку от транзакции между всеми предшествующими визитами, начиная с первого и заканчивая последним.

Рассчитанная ценность сохраняется в атрибуте “ценность визита” (visit_value).

Для оценки эффективности маркетинга, кроме ценности визита (visit_value), нас еще интересует стоимость визита (visit_cost).

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

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

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

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

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

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

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

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

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

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

• таймлайн со всеми событиями системы собираем из всех линков, которые мы нашли на этапе моделирования данных;

• широкая таблица на каждый анкер, куда собираем все атрибуты анкера.

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

Этап 5: Определение метрик

Данные и витрина собраны, остается посчитать по ним бизнес-метрики.

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

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

Этап 6: Финальный отчет

Все данные собраны, метрики определены, приступаем к сборке финального отчета.

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

Этап 7: Документация по проекту

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

На этом проекте мы дополнительно перенесли всю документацию в Notion (для красоты).

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

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

Выводы и следствия

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

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

• данные полностью документированы, актуальность документации поддерживается «по построению», для бизнес-пользователей данные доступны в режиме self-service аналитики; 

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

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