Синергия данных сайта и мобильного приложения: как внедрить сross-device аналитику

Cross-device аналитика – это не просто модный тренд, а необходимость для современного бизнеса. Она позволяет увидеть, как пользователи взаимодействуют с брендом на разных устройствах и платформах, оптимизировать маркетинговые кампании и повышать ROI.

Но, несмотря на огромный потенциал, построение эффективной cross-device отчетности сопряжено со значительными трудностями. Разрозненные данные, технические сложности и ограничения конфиденциальности – лишь часть айсберга. 

Совместно с коммерческим директором DataGo! Дмитрием Ежовым и руководителем группы аналитики данных АЭРО Сергеем Шивалиным рассмотрим, какие сложности формирования cross-device отчетности остаются самыми актуальными, и какие подходы предлагают эксперты для их преодоления.

О чем поговорим?

1. В чем задача и сложности построения маркетинговой аналитики web+app?

2. Что учесть при реализации задачи маркетинговой web+app аналитики?

3. Что нужно сделать для реализации cross-device отчетности?

В чем сложности построения app+web аналитики?

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

Ожидание/реальность

Ожидание 1. Достаточно правильно выбрать «ту самую» платформу.

Реальность

Искажение результатов. Зачастую большинство компаний не покрывает решение своих задач единственной платформой. Маркетологи получают оценку из, как минимум, двух систем, дублируя одних и тех же пользователей. Это искажает и переоценивает результат рекламной кампании.

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

Мягкое принуждение. Бизнесы с уже реализованной и развитой аналитической инфраструктурой вынуждены интегрировать решения от рекламных экосистем для таргетирования рекламных кампаний.

Ожидание 2. В коробочных решениях уже есть все необходимые отчеты.

Реальность

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

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

Привычка к хорошему. Российские решения пока что отстают по функциональности от инструментов репортинга в UI от наиболее известных международных платформ.

Ожидание 3. Если подключить аналитику, можно эффективно распределять рекламный бюджет.

Реальность

Сложности с оценкой cross-device. Оценка эффективности рекламных кампаний ограничена без учета продвижения пользователя по воронке на разных устройствах и перетекания аудитории между мобильным приложением и сайтом.

Потери бюджета на фродовый трафик. Приходится тратить значительное время на управление СРА-каналом и/или терять бюджет на мошенническом трафике, так как не все инструменты позволяют эффективно бороться с фродом.

Ограничения в оценке влияния медийной рекламы на продвижение приложения. Рынком не решена понятным образом задача оценки эффективности медийных кампаний на продвижение мобильного приложения, что сдерживает рекламодателей даже при наличии бюджета.

Предположим, что ваш аналитический проект уже собирает «сырые» web- и app-данные, и перед вами стоит задача объединения web+app трафика в едином отчете.

1. Нужно решить, как объединить session-based и event-based данные

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

2. Важно определить правила формирования синтетического сеанса в мобильном приложении

Ответьте себе на вопросы: что такое сессия в мобильном приложении? Если пользователь за 20 минут 10 раз открыл и закрыл приложение – это 10 сессий или одна?

3. Необходимо настроить расчет атрибуций в единой методологии

Знаете ли вы, по каким именно правилам атрибутирует ваш мобильный трекер источники установки или события? Совпадает ли эта логика с атрибуций на веб?

4. Определитесь с действительно сравнимыми событиями

Насколько сравнимы между собой посещения сайта и мобильного приложения? Имеет ли смысл единая оценка стоимости и закупки трафика? В какой момент возникает сравнимая с точки зрения AAARRR воронка сущности?

5. Важно настроить надежное ежедневное обновление из большего количества таблиц

Как правило, в веб-данных используются 2 сущности, в то время как в мобильных данных их гораздо больше (установки, предустановки и др.) Частота обновления таблиц отличается. Все необходимо настроить и оркестрировать так, чтобы отчет рассчитывался в нужное время на актуальных данных.

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

Даже если данные успешно объединены, возникает вопрос: как правильно атрибутировать конверсию? Какое устройство и какое взаимодействие сыграло решающую роль? Разные модели атрибуции дают разные результаты, и выбор подходящей модели может быть сложным. Cross-device атрибуция требует более сложных моделей, учитывающих весь путь пользователя, а не только последнее взаимодействие.

Что важно учесть?

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

2. Выберите основную парадигму: session-based, user-based, event-based, и настройте расчет витрины business-ready данных с ее учетом.

3. Настройте единую атрибуцию для сеансов/событий и рассчитайте единую атрибуцию на основе raw data.

Cross-device. Что учесть при внедрении сквозного идентификатора?

Отсутствие универсального идентификатора пользователя – одна из самых больших сложностей при формировании cross-device отчета. Пользователи могут взаимодействовать с брендом на разных устройствах, используя разные браузеры и не всегда входя в свои аккаунты. Без единого идентификатора (например, логина пользователя на сайте или в приложении) сложно связать эти взаимодействия в единую цепочку. Ограничения конфиденциальности (например, GDPR и CCPA) еще больше усложняют сбор и объединение данных.

Что важно учесть?

1. Обогащать User_Profile через User_ID для более глубокой идентификации пользователей.

2. Передавать ID в момент перехода с платформы на платформу для идентификации.

3. Использовать ID внешних поставщиков.

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

DWH – решение для кросс-канальной аналитики

Большинство компаний отдельно анализируют данные из каждого источника: со складов и производства, из CRM и «1С», из веба и приложений. В итоге бизнес видит неполную картину и принимает не самые эффективные решения.

Почему данные нужно объединять уже сейчас

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

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

Этапы развития культуры данных

Потом, с распространением смартфонов и удаленки, ключевой цифровой витриной для большинства бизнесов (в первую очередь для B2C) стал мобайл, особенно приложения. Под них затачивают интерфейсы, туда стараются привести пользователей – а сайты выступают скорее источником лидов для тех же приложений.

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

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

Как объединить данные с витрин

Для качественной омниканальной аналитики лучшее решение сегодня – единая база данных, Data Warehouse (DWH). Это хранилище, в котором аккумулируются исторические и текущие данные из как можно большего числа источников корпоративной информации. Данные в DWH очищаются и упорядочиваются, благодаря фильтрам и визуализации в них легко ориентироваться и не ИТ-специалистам.

Как устроено хранилище

С точки зрения данных в DWH, как правило, три слоя: сырые данные, предобработанные и готовые. К последнему слою чаще всего и обращаются бизнес-пользователи.

Упрощенная схема DWH

• Сырые данные. В этот слой информация должна попадать из источников полностью и в первозданном виде, без какой-либо предобработки. Это поможет избежать искажений и найти отправную точку, если ошибка все-таки случится.

• Предобработанные данные. Здесь база очищается от дублей, тестов, старой и прочей мусорной информации. Все приводится к единому формату.

• Готовые данные. Тут данные преобразуются в удобный вид, группируются по смыслам и визуализируются. На этом слое можно развернуть «песочницы» для экспериментов.

Пример визуализации

Есть несколько типов хранения, и, как следствие, форматов данных: «горячие» и «холодные». В первых находится самая свежая и важная информация – та, которая нужна для повседневной работы и должна быть доступна с минимальной задержкой. «Холодное» хранение – нечто вроде архива, куда заглядывают пару раз в год: там данные лежат в максимально сжатом виде, чтобы минимизировать затраты.

Пример работы с DWH

Один из клиентов АЭРО, крупный российский ритейлер с двумя сайтами, двумя мобильными приложениями и 10+ тысячами точек продаж захотел разобраться, как именно клиенты переходят с сайтов в приложения.

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

Мы обработали все эти данные, выстроили траектории движения. Оказалось, зачастую люди делают первую покупку на сайте и только потом скачивают приложение. Провели A/B-тесты и выяснили, что если после первой покупки показать баннер с призывом установить приложение, это повышает количество скачиваний. А если пользователь видит баннер до покупки, он на него практически не реагирует.

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

Главная сложность кросс-аналитики сайтов и приложений

Объединять данные в DWH непросто – сложно выделить на это деньги, сложно учесть все варианты потенциального масштабирования, как и расставить приоритеты в источниках, и контролировать доступы.

В веб и апп-аналитике в условиях импортозамещения главная проблема – импортировать офлайн-данные. Как узнать, что один и тот же пользователь посмотрел товар на сайте, а потом купил его вживую? Или наоборот, совершил быструю покупку на сайте, но перед этим долго консультировался с сотрудниками по телефону?

Ранее подобные данные позволял собирать Google Analytics, но с 1 июля его использование в России запрещено. Но есть лайфхак для других аналитических систем: синхронизировать целевые метрики в разметках сайта и приложения. Это поможет выровнять по смыслу собираемые данные – и будет легче отслеживать логику действий клиентов, сопоставлять данные из разных баз.

Пример синхронизированных метрик для e-commerce. Слева разметка сайта, справа – приложения

В качестве бонуса: изначально синхронизированные по метрикам данные куда легче понимать. То есть они гарантируют высокий уровень самообслуживания: маркетологи и другие пользователи могут свободнее работать с хранилищем и меньше отвлекать ИТ-отдел и аналитиков.

Полезные сервисы

Решений для хранилищ и кросс-канальной аналитики много. Из СУБД сейчас актуальны опенсорсные ClickHouse и PostgreSQL, построенная на базе PostgreSQL и заточенная под большие данные и предиктивную аналитику Greenplum, S3-совместимые хранилища. Для оркестрации хорошо подходит открытый и не подверженный бану Airflow.

Со сбором данных из веба и приложений помогут эти сервисы: Яндекс Метрика, DataGo! Web Streaming и Matomo для сайтов, AppMetrica – для приложений, PostHog – для того и другого.

Примеры сервисов для работы с DWH

Конечно, это не все решения, представленные на российском рынке – но это самые популярные и протестированные АЭРО. Выбор зависит от приоритетов компании, будь то экосистемность, масштабируемость или независимость сервисов.

Оптимальные связки сервисов

Оригинал статьи на SEOnews

Источник