Big Analytics
Мы используем куки (cookies) и собираем IP адреса для улучшения вашего опыта, персонализации контента, анализа трафика. Вы можете отказаться от кук и сбора IP адреса в любое время, изменив настройки вашего браузера. Подробнее в Политике конфиденциальности
Case study
Атрибуция web + app для омниканального бизнеса
    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 и сводились в таблицы отчетов.
    6. Не соблюдалась связность данных по пути пользователя. Данные пользователя не были объединены в один путь.
    Схема движения данных сквозной аналитики ДО
    Система аналитики, по сути, была построена, но количество задействованных инструментов было огромным. Например, данные из Adjust загружались в Amazon S3, а оттуда - в Google BigQuery, несмотря на наличие прямых коннекторов между сервисами.

    Первым этапом проекта был аудит. В результате аудита, помимо излишней сложности, был выявлен ключевой недостаток - анализ был основан на принципе сравнения таблиц, агрегированных на уровне рекламных источников. Поскольку агрегированные данные не содержат идентификатора, объединить путь пользователя между APP/Web/CRM было в принципе невозможно. Поэтому было принято решение использовать сырые данные, содержащие идентификаторы пользователей, объединить их с помощью общих ключей и только после этого агрегировать их на уровне рекламных источников для визуализации.
    Сценарии ДО
    Таким образом, система закрывала только стандартные случаи, такие как переход и заказ на сайте с выкупом, отслеживаемый в CRM, или, установка приложения и заказ в приложении, с поправкой на выкуп. Более сложные случаи отследить было невозможно. Например, если реклама вела на сайт интернет-магазина, а затем пользователь заходил на сайт клуба с другого устройства и оформлял заказ. Или если реклама вела пользователя на сайт, а затем пользователь нажимал "установить приложение" и делал заказ в приложении, то заказ атрибутировался на organic.
    Схема движения данных сквозной аналитики ПОСЛЕ
    Предложенная схема является стандартной для работы с сырыми данными. Все данные были загружены и затем рассчитаны в 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 заключается в наличии затрат. Для когорты каждого месяца накапливаются как первоначальные, так и повторяющиеся затраты на привлечение и все покупки. Это позволяет сделать выводы о том, каков срок окупаемости привлечения пользователей с учетом затрат на повторное привлечение.
    Ещё статьи по теме

    Связаться с организаторами

    Заполните форму и мы рассмотрим ваш вопрос
    biganalytics@yandex.ru

    © 2019-2024 Big Analytics.
    Все права защищены
    ОРГАНИЗАТОР
    • ООО БИГ АНАЛИТИКС
    • ОГРН 1227700397462
    • ИНН 7735195447
    • Деятельность по организации конференций и выставок
    ПРОДАЖА БИЛЕТОВ