Сквозная аналитика не даёт ожидаемых результатов? Часть 2

Коротко. При внедрении сквозной аналитики команды маркетинга и аналитики сталкиваются с четырьмя неочевидными сложностями: неполные данные с рекламных площадок, неполные и несвоевременные данные о заказах, несопоставимость данных из разных источников и отсутствие единой системы метрик между командами. Универсальных решений нет — все проекты индивидуальны, но эти вызовы можно предусмотреть заранее на этапе планирования сбора данных.

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

Расскажем, как мы в DataGo работаем с неочевидными сложностями, которые могут возникнуть в процессе внедрения сквозной аналитики:

• получение неполных данных с рекламных площадок;
• получение неполных и несвоевременных данных о заказах;
• несопоставимость данных;
• отсутствие единой системы метрик между командами.

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

Вызов 1. Неполные данные с рекламных площадок

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

Как собирать полные данные с рекламных площадок?

• Определите ответственных за сбор и контроль данных с рекламных площадок.
• Подключите независимый источник данных для сбора сырых данных.
• Используйте автоматические инструменты импорта данных. Если данные по какой-либо причине недоступны, такие инструменты показывают пробелы и подгружают данные ретроспективно.

Рассмотрим на реальном кейсе

Клиент: крупный ритейлер в РФ, сегмент — мебель и товары для дома.

Инцидент: автоматическое обновление версии облачного хранилища ClickHouse (22.8). Особенность новой версии — архитектурные изменения в обработке и хранении полей с типом flatten_nested.

Последствие: потеря большого количества хитов.

Что было предпринято на стороне DataGo:

• после выявления инцидента код сервиса хитового стриминга был переписан под новую архитектуру ClickHouse уже на следующий день;
• провели сверку по потерям хитов за 2 дня между обновлением ClickHouse и изменением кода сервиса.

Решение:

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

Инциденты такого критического уровня подтолкнули нас к созданию комплексной системы мониторинга. Команда DataGo разработала обновлённую архитектуру DataGo Web Streaming, более защищённую от внешних угроз. Это позволяет своевременно отслеживать все предпосылки к потере или получению неполных данных и предотвращать подобные инциденты.

Вызов 2. Неполные и несвоевременные данные с сайта

Получая полные данные из рекламных площадок и сервисов, мы знаем сумму расхода на продвижение. А сколько мы получаем заказов и сколько с них зарабатываем?

Для этого необходимо собирать данные с сайта и мэтчить их с данными из CRM-систем. При этом важно убедиться, что собранные с сайта данные полные и не имеют ограничений.

Возможные причины сбора неполных данных с сайта

• несвоевременная оплата сервиса для трекинга данных;
• использование только UI популярных аналитических сервисов (личный кабинет Яндекс Метрики / AppMetrica вместо LogsApi; личный кабинет Google Analytics 4 вместо экспорта в GBQ);
• некорректная разметка событий;
• перезапись, дублирование, некорректная разметка в dataLayer;
• порядок отработки аналитических скриптов.

Какое решение?

• Определите требования к разметке событий от бизнеса (какие нужны отчёты, срезы и воронки).
• Перенесите бизнес-требования в карту событий (систему метрик).
• Организуйте кросс-командную работу разработчиков и аналитиков по внедрению и тестированию событий.
• Используйте сервисы для трекинга с доступом к сырым и полным данным.
• Выберите хранилище с автоматическим импортом данных — это позволит своевременно отслеживать возникающие ошибки.

Вызов 3. Несопоставимость данных из источника и с сайта

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

Сложности с объединением данных

• Низкое качество и несогласованность. Непоследовательные, неполные или неточные данные приводят к проблемам при трансформации и к ошибочным выводам.
• Безопасность данных. Обработка конфиденциальной информации при перемещении больших объёмов данных несёт риск утечки и несоответствия требованиям СБ.
• Интеграция данных в реальном времени. Спрос на realtime-аналитику вырос, но добиться интеграции данных в реальном времени бывает непросто — особенно на проектах с большим объёмом данных.

Рассмотрим на реальном кейсе

Клиент: крупный ритейл-бренд в РФ, сегмент — брендовая одежда и товары для дома.

Задача: объединить данные из web и app в единый отчёт.

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

Источники данных:

• DataGo Web Streaming;
• API-выгрузка из сервиса мобильной аналитики (AppsFlyer, AppMetrica).

Что было предпринято на стороне DataGo:

• сбор web- и app-данных в едином хранилище (DWH);
• приведение данных из App к единому формату, схожему с Web, для использования в единой витрине данных;
• формирование пула целевых метрик для принятия стратегических решений;
• вывод аналитики в едином дашборде по общим и кросс-девайс показателям эффективности.

Вызов 4. Разрозненная интерпретация метрик

Из-за большого объёма требуемых данных и метрик отделы аналитики и маркетинга могут интерпретировать одну и ту же метрику по-разному. В результате отчёт перестаёт быть информативным, что приводит бизнес к неверным инсайтам.

Какое решение?

Сформируйте дерево метрик. Как правило, метрики, на которые обращают внимание руководители компании (фаундеры, директора), отличаются от метрик, на которые смотрят линейные сотрудники (маркетологи, product owners). Первым важно фиксировать верхнеуровневые бизнес-результаты, вторым — более точечные, локальные показатели.

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

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

Заключение

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

Чтобы подготовиться даже к самым неочевидным сложностям, мы рекомендуем постоянно повышать навыки внутренней команды, работать над эффективностью кросс-командного взаимодействия — или обратиться к DataGo.