Какие данные нужны для продвинутой post-view аналитики: опыт DataGo Consulting

Коротко. Для продвинутой post-view аналитики нужно собрать расходы из рекламных кабинетов, доходы из CRM и данные о пользовательских событиях после просмотра медийного креатива и до конверсии — последние получают с помощью пикселей AdTracker. Эти данные сводят в единую базу данных, чтобы посчитать окупаемость (ROI/ROMI) каждой кампании, площадки и креатива. На основе единого хранилища строят инфраструктуру со стримингом из всех источников, обработкой и BI-системой.

У нас накопилось столько знаний и материалов про post-view аналитику, что мы выпускаем уже третий кейс про data-driven подход к её анализу. В нём расскажем:

• что такое продвинутая post-view аналитика и для чего она нужна;
• какие инструменты помогут собрать все необходимые данные;
• как построить инфраструктуру для продвинутой post-view аналитики.

Один из предыдущих материалов — способы анализа post-view аналитики — поможет определить, какой уровень анализа подходит вашему бизнесу.

Что такое продвинутая post-view аналитика?

Продвинутая post-view аналитика — это способ анализа эффективности медийных размещений, который помогает ответить на вопросы:

• какой графический баннер показывает лучшие результаты;
• какая рекламная кампания имеет самый высокий показатель ROI;
• сколько заработала компания с каждой рекламной площадки.

За счёт продвинутой post-view аналитики вы сможете принимать обоснованные управленческие решения, опираясь на конкретные метрики. Но чтобы полноценно использовать этот подход, нужно определиться: какие именно данные мы хотим собирать и какие выводы они помогут сделать. Отталкиваемся от конечной цели любого бизнеса и рекламной кампании — дохода. Соответственно, важно понять, принесла ли медийная реклама доход.

На какие метрики ориентироваться?

Необходимо посчитать окупаемость (ROI/ROMI). Для этого нужны расходы (из рекламного кабинета) и доходы (из CRM). Если расходы можно явно отнести к конкретной кампании, таргетингу и креативу, то с доходами всё сложнее: медийная реклама в большинстве случаев приносит post-view конверсии, то есть нет прямой связи между просмотром креатива и действием пользователя на сайте.

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

Как это сделать?

• С помощью пикселей AdTracker (например, Adriver, Weborama).
• Промечаем каждое медийное объявление: в момент показа пользователю присваивается cookie-файл, который при заходе на сайт помогает определить всех, кто ранее видел объявление.
• Устанавливаем пиксель трекера на посещение страниц и на целевые действия.

Этот пиксель передаёт на свои серверы данные обо всех пользователях, которые зашли на сайт, присваивает им признак «видел медийную рекламу» или «не видел» и связывает показ с конкретной конверсией. Для более глубокого изучения аудитории можно передавать любые мета-данные о пользователе из системы аналитики — помимо тех, что собирает трекер.

Как построить инфраструктуру для продвинутой post-view аналитики

Шаг 1. Единая база данных

Доступ ко всем данным в едином месте — это must have. У аналитика должна быть возможность обращаться в едином хранилище к расходам, доходам, пользовательским событиям и данным от трекера. Для этого нужно обеспечить стриминг данных из всех источников в единую БД. Для хранения, обработки и анализа используют реляционные базы данных — открытые (PostgreSQL, MySQL, ClickHouse, Vertica, SQLite) и коробочные (Oracle, Microsoft SQL Server).

Шаг 0. Выбор сервера

Нет, это не опечатка. Выбрав базу данных, нужно сделать шаг назад и понять, на каком сервере её разворачивать. Есть два варианта:

• Физический сервер компании. Управление архитектурой проекта ляжет на компанию, но и контроль данных остаётся на её стороне.
• Облачная платформа, например Yandex Cloud. Облачные платформы зарекомендовали себя как безопасное, доступное и стабильное решение, требующее меньшего ресурса компании.

Шаг 2. Коннектор данных

Коннектор данных — инструмент для стриминга данных из рекламных кабинетов и системы аналитики в единую БД. Наполнить базу можно несколькими способами:

• API. Можно самостоятельно писать запросы на выгрузку данных. Однако это ресурсозатратно: нужны доступы (токены), написание скрипта и его отладка.
• Коннекторы данных. Готовые решения в несколько кликов настраивают потоки данных практически из любого источника в любой приёмник.

Мы обычно используем собственный коннектор данных DataGo Pipelines, который импортирует данные о рекламных расходах из Яндекс.Директ, ВКонтакте, myTarget, сырые данные по событиям AppsFlyer и из других систем — а вместе с нашими партнёрами это десятки дополнительных источников. Объединив данные сайта, мобильного приложения и рекламных кабинетов, маркетолог получает достоверную оценку рекламных усилий.

Шаг 3. Диспетчер тегов

Запуск рекламных кампаний онлайн неразрывно связан с установкой рекламных пикселей на сайте. Когда речь о медийной рекламе, на сайт обычно ставится пиксель трекера (например, Adriver или Weborama). Пиксели можно размещать в коде силами фронтенд-разработчиков, но при большом количестве кампаний удобнее использовать диспетчер тегов — единый интерфейс для установки множества пикселей без привлечения фронтенда. Сейчас в России доступен Google Tag Manager, но риск его отключения существует, поэтому на замену многие рассматривают Matomo Tag Manager, доступный в коробочной и on-premise версиях.

Шаг 4. Инструмент для оркестрации данных

Работа с большим объёмом данных приводит к появлению множества скриптов, которые надо запускать по расписанию: регулярно получать данные из источников, находить ошибки, обрабатывать и придавать бизнес-смысл — готовить для визуализации, строить прогнозы, считать метрики. Для порядка и своевременного запуска кода используют инструменты оркестрации (например, Apache Airflow) — open-source решение, ставшее стандартом индустрии. Airflow имеет большой набор инструментов и провайдеров для работы с разными источниками (S3, ClickHouse, BigQuery, Google Docs, FTP), позволяет создавать собственные операторы и подключать инструменты вроде dbt. Устанавливать его нужно на виртуальную машину, которую можно арендовать в Yandex Cloud.

Шаг 5. Dbt

Dbt — инструмент для разработки и тестирования моделей данных. Он позволяет создавать модели (таблицы и представления), материализовывать их без сложного синтаксиса, обновлять в правильном порядке, использовать встроенные тесты или писать свои, документировать модели и источники, отслеживать взаимосвязи и работать с SQL как с кодом. Это open-source инструмент (есть и облачная версия dbt Cloud), который облегчает работу дата-инженеров и аналитиков, снижает время на разработку за счёт переиспользования кода и упрощает поддержку благодаря контролю версий.

Шаг 6. Git

Git — система контроля версий, без которой нельзя представить современную разработку. Она нужна, чтобы поддерживать код в актуальном состоянии: трансформации в Airflow, модели dbt или что угодно ещё. Каждый специалист по работе с данными должен понимать, кто и когда вносил изменения — это снижает время на поддержку, ускоряет разработку и защищает от критических ошибок.

Шаг 7. BI-система

Любую аналитику нужно донести до конечных заказчиков в понятном виде, и для этого результаты визуализируют. В аналитике BI-системы используют в первую очередь для построения дашбордов. Выбор зависит от многих факторов: доступности оплаты из РФ, коробочного или on-premise варианта, удобства использования, интеграции с текущим стеком. Стоит обращать внимание на масштабируемость дашбордов: в post-view аналитике мы имеем дело с очень большим объёмом данных, и каждый новый флайт лучше выделять в отдельный дашборд. Если медийная реклама запускается часто, удобнее BI, где можно скопировать шаблон дашборда и переподключить источники — из коробочных это Power BI, из облачных Superset и Metabase.

Шаг 8. «Холодное» хранилище

Когда все данные собраны, обработаны и визуализированы, стоит задуматься об оптимизации бюджета на хранение. Данные в БД занимают «полезное пространство» и увеличивают её стоимость. Чтобы оптимизировать расходы, исторические данные, которые не используются активно, но требуют хранения, рекомендуется переносить в «холодное» хранилище — разновидность объектного хранилища с низкой стоимостью хранения, но более высокой стоимостью или меньшей скоростью выборки. Найти его можно, например, в Google Cloud Storage или Yandex Object Storage.

Итоговая схема

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

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