ВестВинг (Westwing) - это шопинг-клуб и интернет-магазин мебели и декора. Маркетинг работает с клиентами компании по двум основным направлениям коммуникации. Первое направление - это интернет-магазин, с десктоп + мобильная версии сайта. Второе направление - клуб закрытых продаж на сайте и в приложении (WEB + App). Акции обычно длятся от 2 до 4 дней и обновляются каждый день. Доступ к распродажам без регистрации пользователя невозможен. Клиенты клуба ежедневно получают рассылки с акциями. Данные модели коммуникации являются разными бизнес-моделями, работающими с одной и той же клиентской базой, и имеющими одинаковые цели по продажам.

Таким образом, ВестВинг (Westwing) столкнулся со следующими проблемами и ограничениями:

1. Три экосистемы: Сайт1, Сайт2, Приложения (iOS, Android). Каждая из них подключена к клиентской базе (CRM), но данные пользователей не объединены в один путь. Для веб-аналитики использовался Гугл Аналитика (Google Analytics), для мобильного приложения - Эджаст (Adjust). Заказы создавались в движке (CMS) сайта, а затем аккумулировались в CRM.
2. Отсутствие доверия к данным, поскольку они явно не складывались в общую картину для решения маркетинговых и бизнес-задач.
3. Данные во всех трех системах UA/CMS/CRM отличались друг от друга. Маркетологи не могли определить эффективность рекламных каналов в цепочке приведения клиента к целевому действию - какой канал, какой вес и какую ценность он имеет. А бизнес, соответственно, какие каналы эффективны с точки зрения монетизации.
4. Данные о затратах предоставлялись агентствами в формате CSV, а затем загружались в Гугл Клоуд Стораж (Google Cloud Storage - GCS). Часто из-за ошибок ручного ввода расчеты затрат клиента были неверными.
5. Данные вытягивались из Гугл Аналитики (GA) в агрегированном виде в разрезе меток UTM (Urchin Tracking Module) и сводились в таблицы отчетов.
6. Не соблюдалась связность данных по пути пользователя. Данные пользователя не были объединены в один путь.

Система аналитики, по сути, была построена, но количество задействованных инструментов было огромным. Например, данные из Эджаст (Adjust) загружались в Амазон (Amazon) S3, а оттуда - в Гугл БигКвери (Google BigQuery), несмотря на наличие прямых коннекторов между сервисами.

Первым этапом проекта был аудит. В результате аудита, помимо излишней сложности, был выявлен ключевой недостаток - анализ был основан на принципе сравнения таблиц, агрегированных на уровне рекламных источников. Поскольку агрегированные данные не содержат идентификатора, объединить путь пользователя между программа/сайт/клиентская база (APP/Web/CRM) было в принципе невозможно. Поэтому было принято решение использовать сырые данные, содержащие идентификаторы пользователей, объединить их с помощью общих ключей и только после этого агрегировать их на уровне рекламных источников для визуализации.

Таким образом, система закрывала только стандартные случаи, такие как переход и заказ на сайте с выкупом, отслеживаемый в базе CRM, или, установка приложения и заказ в приложении, с поправкой на выкуп. Более сложные случаи отследить было невозможно. Например, если реклама вела на сайт интернет-магазина, а затем пользователь заходил на сайт клуба с другого устройства и оформлял заказ. Или если реклама вела пользователя на сайт, а затем пользователь нажимал "установить приложение" и делал заказ в приложении, то заказ атрибутировался на organic (бесплатный SEO поиск).

Предложенная схема является стандартной для работы с сырыми данными. Все данные были загружены и затем рассчитаны в Гугл БигКвери (Google BigQuery).

Интересным в проекте было следующее: все данные загружались в контексте отдельных событий, то есть в качестве источника брались сырые данные сайта из Гугл Аналитика (Google Analytics) 4 и сразу получался готовый поток данных в реальном времени (хитстрим) в Гугл БигКвери (Google BigQuery). Затем Эджаст (Adjust) напрямую связывался с Гугл БигКвери (GBQ), а часть схемы, которая загружала данные из внутренней системы в Гугл БигКвери (GBQ) через облачную платформу автоматизированного перемещения данных Fivetran, оставалась нетронутой.

Расходы на рекламу из рекламных аккаунтов автоматически загружались в Гугл БигКвери (GBQ), затем продукт МТРЕНДО-ХОЛОВЭЙ (M&H Apps) агрегировал данные в сессии, сессии объединялись в единую цепочку с использованием общих ключей, расходы и доходы также приписывались к уровню пользователя. Необработанные данные занимают очень большой объем, поэтому они ежедневно агрегируются по всем возможным параметрам и метрикам в "плоскую" таблицу перед отображением на дашборде.

Благодаря тому, что все расходы и доходы атрибутируются на уровень сесси, дашборд отображает корректные данные в любых доступных срезах, а отчет о доходах и расходах всегда сходится (в отличие, например, от Гугл Аналитики (Google Analytics)), где невозможно смешать в одном отчете параметры, относящиеся к хиту, сессии и пользователю).

Проблема прерывания пути пользователя при переходе между сайтами была решена очень просто - установкой одного общего счетчика. До проекта на сайтах были установлены разные счетчики, соответственно, пользователь получал разные куки (cookies) и путь прерывался.

Кейс установки приложения по нажатию на кнопку на сайте также был решен путем передачи идентификационого кода клиента (Client ID) в Эджаст (Adjust), а затем в Гугл БигКвери (GBQ).

Кроме того, даже если пользователь не логинится на двух сайтах, его путь все равно связан в единую цепочку. Это связано с тем, что если пользователь хотя бы раз заходит на один сайт, его куки связываются с его логином, и данные обновляются на глубину до 180 дней. В результате анонимные файлы куки (cookie) перестают быть анонимными, и пользователь идентифицируется.

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

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

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

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

Также по просьбе команды Westwing была реализована необычная схема работы с когортами. Для проекта с более чем 10-летней историей 95% выручки поступает от повторных покупок, поэтому возможность отличить выручку пользователей текущего месяца от выручки постоянной клиентской базы позволяет оценить реальный эффект от маркетинга, тем более что процессы работы с новой и текущей базой в компании разделены. Когорты рассчитываются по месяцу привлечения, а также по первой регистрации и первой покупке. Также определены правила перехода пользователя из одной когорты в другую. Например, повторная активация пользователя после шести месяцев бездействия переводит его в новую когорту. Ключевое различие между когортами, рассчитываемыми продуктом M&H Apps, и когортами в GA или Adjust заключается в наличии затрат. Для когорты каждого месяца накапливаются как первоначальные, так и повторяющиеся затраты на привлечение и все покупки. Это позволяет сделать выводы о том, каков срок окупаемости привлечения пользователей с учетом затрат на повторное привлечение.