Мобильная и веб-атрибуция: как связать сайт и приложение

В статье Поствью и постклик: как объединить медийную и перформанс-рекламу мы рассказывали об объединении данных по взаимодействиям пользователя с медийными и performance-кампаниями в один путь. Более того, затрагивали вопрос online-to-offline маркетинга и ТВ-атрибуции.

Но что если конечное ценное действие пользователь совершает не на сайте, а в мобильном приложении? Тогда для правильного распределения вклада в итоговую конверсию потребуется обогатить уже имеющийся блок знаний app-данными и объединить web- и app-взаимодействия в единый путь.

Ограничения связки Web + App

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

ATT и SKAN: как изменились возможности мобильной аналитики

Одной из отправных точек стало появление у Apple технологии SKAdNetwork, или SKAN. Первая версия стала доступна ещё в iOS 11.3. Инструмент позволил проводить атрибуцию мобильных приложений на основе обезличенной информации, без передачи сведений о конкретном пользователе. При таком подходе аналитик получает меньше деталей, чем при работе с идентификаторами на уровне пользователя.

Без полного объёма данных невозможно восстановить всю пользовательскую активность и построить исчерпывающую отчётность по каждому отдельному пути. Для передачи информации о результатах кампаний Apple предложила механизм Conversion Value. Он помогает оценивать конверсии в агрегированном виде, но не даёт всех данных, которые нужны для объединения действий конкретного пользователя на сайте и в приложении.

В 2021 году Apple внедрила фреймворк App Tracking Transparency, или ATT, для устройств с iOS 14.5 и новее. С тех пор пользователи самостоятельно принимают решение, давать приложению доступ к отслеживанию их действий в приложениях и на сайтах других компаний или нет. Здесь речь в том числе идёт о доступе к мобильному рекламному идентификатору IDFA.

По данным AppsFlyer, на момент первоначальной публикации статьи средний мировой показатель согласия ATT – доля пользователей, выбравших «Разрешить» при отображении системного запроса, – составлял около 37%. К 2025 году AppsFlyer оценивал глобальный показатель уже примерно в 50%. Конкретное значение меняется в зависимости от периода, региона и категории приложения, но сама тенденция по ограничению доступа к пользовательским данным стала поводом для поиска альтернативных возможностей мобильной аналитики.

Сейчас SKAdNetwork сосуществует с более новым фреймворком AdAttributionKit. Оба подхода помогают оценивать рекламные кампании с учётом требований конфиденциальности, но не создают общего идентификатора для склейки сайта и приложения.

IDFA и GAID: почему их недостаточно для связки Web + App

В мобильной среде для рекламной аналитики традиционно используются идентификаторы устройств: IDFA в экосистеме Apple и GAID на Android. Однако они не являются универсальным ключом для объединения данных.

Доступ к IDFA зависит от разрешения ATT. GAID пользователь может ограничить или сбросить. При этом браузерная cookie не равна ни IDFA, ни GAID, а идентификаторы одного человека на разных устройствах также не совпадают автоматически.

Поэтому базово web и app остаются разными средами. Чтобы объединить их в один путь, нужен дополнительный общий признак: авторизация, идентификатор перехода в deeplink, Stable ID или другая допустимая технология склейки.

Когда склейка Web + App невозможна

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

К примеру, если рекламодатель запускал охватные размещения на programmatic-площадках вроде Яндекс Главной и получил конверсию в приложении, то оценить их полный вклад в итоговый результат получится не всегда. Почему?

Cookies в браузере и идентификаторы в приложении

Разберём процесс аналитики медийных размещений, допустим, в Яндекс Дзене. При посещении сайта пользователю присваивается cookie. Чтобы отследить касание пользователя с медийными размещениями, верификатор, допустим AdRiver, устанавливает свой пиксель на сайт рекламодателя, за счёт чего получает знание о показах.

Предположим, после просмотра рекламного объявления, нацеленного на переадресацию пользователя в магазин приложений, пользователь установил приложение только спустя несколько дней. В таком случае без дополнительного идентификатора будет невозможно объединить web- и app-данные о пользователе и понять, какое касание стало последним в цепочке перед конверсией. Programmatic-площадка работает с cookies, а приложение – с идентификаторами устройств IDFA и GAID. Поскольку это разные среды, базово они не объединяются.

Медийная реклама в других приложениях

Трудности также возникнут с медийной рекламой, размещённой в других приложениях. Хотя некоторые верификаторы, например AdRiver, смотрят в эту сторону и предлагают установку своих SDK-трекеров в приложения рекламодателей для получения данных о показах.

Трудность сотрудничества верификаторов с programmatic-площадками в вопросе получения разрешения на размещение SDK-трекеров заключается в нежелании последних делиться информацией об IDFA или GAID пользователей. Хотя при доступности общего идентификатора и согласованной интеграции такая связка web и app была бы возможна.

В каких случаях персональный путь собрать нельзя

Связать события на уровне конкретного пользователя не получится, если между web и app не возникает общего признака. Например:

• человек анонимно посетил сайт, а через несколько дней самостоятельно нашёл приложение
• пользователь увидел медийную рекламу на закрытой площадке, которая не передаёт доступный рекламодателю идентификатор или postback
• пользователь сменил устройство или браузер, удалил cookies и нигде не авторизовался
• пользователь не разрешил отслеживание на iOS, а схема склейки зависела от IDFA
• правила конфиденциальности, согласие пользователя или условия партнёра не позволяют применять данные для объединения

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

Какие есть решения

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

Авторизация через один личный кабинет

Авторизация через один личный кабинет на сайте и в приложении позволит объединить web и app. Это наиболее надёжный вариант детерминированной склейки: после входа обе системы могут передавать во внутреннее хранилище один и тот же User ID.

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

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

Прометка deeplink

Deeplink – это маршрут, который ведёт пользователя к конкретной точке внутри приложения. В deeplink-ссылку, которая ведёт с сайта в приложение, можно добавить параметры перехода: источник, кампанию, объявление или внутренний идентификатор, связанный с веб-сессией пользователя.

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

Тогда с помощью deeplink-ссылки в мобильный трекер, например AppMetrica, передаётся не сама браузерная cookie, а специально подготовленный параметр или одноразовый идентификатор перехода. На стороне аналитического хранилища его можно сопоставить с веб-сессией. Это позволяет объединить конкретный переход из web в app в единый путь. Возможность передачи параметров в deeplink предусмотрена и в AppMetrica.

Важно учитывать ограничение: deeplink связывает только тот переход, который действительно произошёл по размеченной ссылке. Он не объединяет автоматически всю предыдущую историю пользователя. Если приложение ещё не установлено, потребуется deferred deeplink – отложенная ссылка, которая передаст параметры после установки и первого запуска. Возможности такого сценария зависят от операционной системы и мобильного трекера, поэтому его нужно отдельно тестировать для iOS и Android.

Объединение через стабильный идентификатор

Stable ID – развивающаяся технология, которую активно обсуждают и внедряют на рынке. Если рассматривать инструмент в контексте нашей темы, он позволяет использовать стабильный обезличенный идентификатор для объединения данных из разных сред.

Данные мобильного оператора позволяют сопоставить действия пользователя в мобильном и десктопном браузерах, а при соответствующей интеграции – связать их с доступными app-данными. Работа такого решения зависит от технической схемы оператора, покрытия, доступных идентификаторов и согласованных правил обработки данных.

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

Подробнее о технологии читайте в статье Stable ID вместо cookie: как собирать данные, не нарушая data privacy. Практический пример внедрения разобран в кейсе БКС Мир инвестиций.

Сравнение способов объединения Web + App

Резюме

Исследования мобильного поведения показывают, что основная часть времени на смартфонах приходится на приложения, а не на мобильный веб. В сфере электронной коммерции контраст ещё более разительный: согласно отраслевому benchmark-отчёту по e-commerce-приложениям, пользователи мобильных приложений тратят на покупки в среднем 201,8 минуты в месяц по сравнению с 10,9 минуты у пользователей мобильных сайтов.

[Картинка: сравнение активности пользователей в приложении и на мобильном сайте]

Отсюда – повышенная ценность аналитики взаимодействий в app в связке с web-активностью пользователей. Чтобы правильно атрибутировать вклад каждого касания пользователя с кампанией в итоговый результат, необходимо объединять действия со всех доступных каналов.

Web + App атрибуция начинается не с выбора модели, а с общего ключа между сайтом и приложением. Самый точный вариант – единый User ID после авторизации. Deeplink связывает конкретный переход между средами, а Stable ID помогает расширить покрытие там, где путь остаётся анонимным.

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

Материалы по теме

Что такое атрибуция простыми словами

Если только начали разбираться в теме, откройте материал Что такое атрибуция простыми словами.

Как выбрать модель атрибуции

Остались вопросы? Читайте статью Атрибуция в маркетинге: зачем нужна и как выбрать модель – хороший стартовый материал, с которого мы рекомендуем начать изучение темы.

Кому нужна атрибуция на основе данных

Когда данные сайта и приложения уже связаны, следующим шагом становится выбор способа расчёта вклада каналов. О том, когда оправдан сложный подход, читайте в статье Мобильная data driven атрибуция: когда она нужна бизнесу.

Если нужно разобраться в теме подробно

У нас есть Подборка материалов по атрибуции: большая обзорная статья. Там собраны модели, окно атрибуции, частые ошибки и пошаговое внедрение – в правильном порядке, от простого к сложному. Очень советуем!