Компания Westwing - это шопинг-клуб и интернет-магазин мебели и декора. У компании два основных направления коммуникации с клиентом. Первое направление – это интернет-магазин, который представлен сайтом и его мобильной версией. Второе направление – это клуб закрытых распродаж с web версией и мобильным приложением. Акции длятся от 2 до 4 дней и обновляются каждый день. Получить доступ к распродажам без регистрации нельзя. Пользователи – клиенты клуба ежедневно получают рассылки акций. По сути, данные модели коммуникации – это разные бизнес-модели. При этом клиентская база у Westwing – единая, таргеты по продажам также единые для двух бизнес-моделей.
Проблемы и ограничения
Таким образом, Westwing сталкивался со следующими проблемами и ограничениями:
- Три экосистемы: Сайт1, Сайт2, Приложения (iOS, Android). Каждое из них связано с CRM, но данные пользователя не объединены в один путь.
Для web аналитики использовался Google Analytics, для мобильного приложения – Adjust. Заказы создаются в CMS сайта, а потом аккумулируются в CRM. Отсутствие доверия к данным, так как они явно не складывались в общую картину для решения задач маркетинга и бизнеса.
Данные во всех трех системах UA/CMS/CRM отличались друг от друга. Маркетологи не могли определять эффективность рекламных каналов в цепочке приведения клиента к целевому действию – какой канал, какой вес и какое значение имеет. А бизнес, соответственно, какие каналы эффективны с точки зрения монетизации.
Данные по расходам предоставлялись агентствами в виде CSV, и затем загружались в Google Cloud Storage (GCS) .
Зачастую из-за ошибок ручного ввода, расчеты стоимости клиента оказывались некорректны.- Данные вытягивались из GA в агрегированном виде в разрезе UTM и сводились в таблицы отчетов.
- Не соблюдалась связность данных по пути пользователя. Данные пользователя не были объединены в один путь.\
Схема движения данных сквозной аналитики ДО
Система аналитики, по сути, была выстроена, но количество задействованных инструментов было огромным. Например, из Adjust данные выгружались в Amazon S3, а оттуда в Google BigQuery, несмотря на наличие прямых коннекторов между сервисами.
Первым этапом проекта стал аудит. В результате аудита, помимо излишней сложности, был выявлен ключевой недостаток – в основу анализа был положен принцип сопоставления таблиц, агрегированных на уровне рекламных источников. Поскольку агрегированные данные не содержат идентификатора, то объединить путь пользователя между APP/Web/CRM невозможно в принципе. Поэтому было принято решение использовать сырые данные, содержащие идентификаторы пользователя, объединить их по общим ключам и только после этого агрегировать на уровне рекламных источников для визуализации.
Сценарии ДО
Таким образом, система закрывала только такие стандартные кейсы, как приземление и заказ на сайте с отслеживаемым в CRM выкупом, или, установка приложения и заказ в приложении, тоже с поправкой на выкуп.Более сложные кейсы отследить было невозможно. Например, если реклама привела на сайт интернет-магазина, а затем пользователь уже с другого устройства попал на сайт клуба и сделал заказ. Или если реклама привела пользователя на сайт, затем пользователь нажал кнопку “установить приложение” и совершал заказ в приложении, то заказ атрибутировался на organic.