[Бета] Кроссплатформенная атрибуция на уровне пользователя. 

Что такое атрибуция на уровне пользователя?

Кроссплатформенная атрибуция на уровне пользователя — это модель, которая опирается на постоянный идентификатор пользователя клиента (CUID) для связывания событий конверсии на разных платформах. Опираясь на CUID, модель приписывает всю последующую активность исходному медиаисточнику, который привёл к первой конверсии пользователя.

Пример кроссплатформенного пути пользователя

К примеру, пользователь кликает по веб-рекламе Google, регистрируется и завершает покупку в браузере на компьютере. Позже тот же пользователь кликает на мобильную рекламу в Instagram, устанавливает мобильное приложение и делает еще одну покупку в приложении. Через неделю пользователь устанавливает СTV-приложение бренда, входит, используя тот же CUID, и там же оформляет платную подписку.

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

Атрибуция на основе пользователей против атрибуции на основе устройств

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

Следующий пример пути пользователя иллюстрирует разницу между атрибуцией, ориентированной на устройства, и атрибуцией, ориентированной на пользователя:

Пользователь кликает на рекламу Meta на веб-странице, перенаправляется на сайт рекламодателя, регистрируется и создает аккаунт. Позже тот же пользователь устанавливает iOS-приложение рекламодателя, входит в систему и делает покупку на сумму 50 долларов. Через несколько дней пользователь видит рекламу в YouTube, устанавливает ПК-приложение рекламодателя, снова входит в систему и делает покупку на сумму 100 долларов.

Атрибуция на основе устройств приписывает 0 долларов рекламе Meta, в то время как атрибуция на основе пользователей приписывает 150 долларов. Таблица ниже показывает, как этот путь будет приписан в каждой модели:

Что делает событие кандидатом для кроссплатформенной атрибуции?

Событие считается кандидатом для кроссплатформенной атрибуции, если оно соответствует всем следующим условиям:

• Наличие CUID: Событие должно включать действительный Идентификатор пользователя клиента (CUID) — постоянный идентификатор, предоставленный рекламодателем (например, ID для входа или хэшированный адрес эл.почты), который однозначно идентифицирует пользователя на разных устройствах и платформах.  
  • Если в событии нет CUID, но имеет тот же appsflyer_id, AppsFlyer может внести CUID в течение короткого окна обработки — до 4 часов до первого события, которое пришло с CUID. Для получения дополнительной информации см. Окно обработки обогащения CUID ниже.
  • События, которые приходят без CUID и не могут быть обогащены через процесс обогащения CUID, все равно включаются в кроссплатформенную атрибуцию. В таких случаях атрибуция определяется с использованием их метода атрибуции на уровне устройства (классического).
• Относится к линейке продуктов: Приложение, генерирующее событие, должно входить в линейку продуктов – группу связанных приложений (например, iOS, Android, CTV) под одним брендом, для которой атрибуция определяется и настраивается совместно. Для получения дополнительной информации см. Групповые приложения для кроссплатформенной атрибуции.
• В течение окна восстановления неактивности: Событие должно происходить в течение окна неактивности – настраиваемого периода (например, от 7 до 390 дней), в течение которого CUID все еще считается активным и имеет право на атрибуцию в рамках данной линейки продуктов. Если CUID не появляется в течение этого окна, его прежнее сопоставление атрибуции аннулируется. 
• Наличие полей атрибуции на уровне устройства: Событие должно уже содержать корректные параметры атрибуции на уровне устройства (например, источник медиа, ID кампании), полученные из классической модели атрибуции на основе устройства AppsFlyer.

Как определяется источник атрибуции?

Эта модель атрибутирует все события для данного пользователя (CUID) к оригинальному медиаисточнику, который привел к первой конверсии пользователя.

Атрибутированный оригинальный медиаисточник определяется по следующему принципу:

• Для каждого события в приложении с CUID в линейке продуктов AppsFlyer определяет самое раннее событие запуска для этого CUID (т.е. событие запуска с действительным медиаисточником).
• Медиаисточник, атрибутированный этому событию запуска классической атрибуцией, основанной на устройстве, считается источником атрибуции для события в приложении.
• Этот медиа-источник используется как источник кроссплатформенной атрибуции привлечения пользователей для всех последующих событий, связанных с этим CUID и линейкой продукта.
• Если событие в приложении не содержит CUID, AppsFlyer пытается заполнить его в течение 1–4 часов окна обработки обогащения. 
• Если событие без CUID приходит вне определенного окна обогащения, оно все равно будет включено в кроссплатформенную атрибуцию. Эти события атрибутируются с использованием их метода атрибуции на уровне устройства (классического).

Окно обработки обогащения CUID

Окно обработки обогащения CUID – это период (1–4 часа), в течение которого AppsFlyer обрабатывает вновь поступившие события в приложении для заполнения недостающих идентификаторов пользователей клиентов (CUID). Это позволяет выполнять кроссплатформенную атрибуцию, даже если некоторые события в приложении поступают без CUID.

Как работает обогащение CUID

• Каждые 1–4 часа AppsFlyer запускает обработку.
• Если событие поступает без CUID, но имеет тот же appsflyer_id, что и другое событие с CUID, AppsFlyer заполняет недостающий CUID.
• Это связывание применяется только к событиям, полученным в течение окна обработки.

Пример обогащения CUID

• 08:01: Событие первого открытия приложения записывается с appsflyer_id = XYZ.
• 09:00: Событие регистрации записывается с cuid = 123 и appsflyer_id = XYZ.
• 12:00: Окончание 4-часового окна обработки. AppsFlyer ретроактивно связывает cuid = 123 с событием первого открытия приложения.
• 12:30: Событие покупки записывается с appsflyer_id = XYZ, но без CUID. Поскольку событие поступает после закрытия окна, AppsFlyer не связывает cuid = 123 с ним.

Ограничения обогащения CUID

• События без CUID, поступающие за пределами 1–4 часового окна обработки, атрибутируются с использованием классической атрибуции AppsFlyer и добавляются к результатам кроссплатформенной атрибуции.
• Связывание CUID не применяется ретроактивно за пределами окна обработки.

Настройте кроссплатформенную атрибуцию

Чтобы настроить кроссплатформенную атрибуцию, необходимо задать несколько параметров в AppsFlyer и реализовать определённые функции SDK в коде вашего приложения. 

• В AppsFlyer назначьте свои приложения линейке продуктов,включите кроссплатформенную атрибуцию и задайте окно восстановления неактивности. Для получения дополнительной информации см. Настройка линейки продуктов.
• В вашем приложении настройте SDK AppsFlyer для отправки событий с CUID. Для инструкций для разработчиков см.Установить идентификатор пользователя клиента.

Просмотреть результаты атрибуции на разных платформах

• Чтобы просмотреть результаты атрибуции на разных платформах, см. Отчет о событиях конечных пользователей в Data Locker на разных платформах.
• В планах: Новый метод атрибуции доступен в Моих дэшбордах

.