Когда пользователь попадает на целевую страницу, AppsFlyer должен зафиксировать это взаимодействие с помощью интегрированного обработчика.

• Web SDK (Pixel): Клиентский сниппет, реализованный непосредственно на сайте или через Google Tag Manager (GTM).
• Server-to-Server (S2S) API: Надежная серверная интеграция, которая помогает обходить ограничения браузера на измерение и блокировщики рекламы, а также позволяет обогащать данные до того, как они поступят в AppsFlyer. S2S-интеграцию можно выполнить напрямую с сервера клиента или через Google Tag Manager Server Side.

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

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

Дополнительные сведения см. в разделе «Регистрация визитов».

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

• PID: Сначала система проверяет наличие собственных параметров AppsFlyer.
• Параметры UTM: Если PID отсутствует, система ищет стандартные теги, например utm_source.
• Идентификаторы кликов: Затем система ищет специфичные для рекламных сетей идентификаторы, такие как идентификатор ID клика Google (gclid) или идентификатор ID клика TikTok (ttclid).
• Реферер: В качестве последнего резервного варианта система определяет URL-адрес, на котором пользователь находился непосредственно перед переходом.

Дополнительные сведения см. в разделе «Определение медиаисточника».

Поскольку большинство пользователей входят в систему в течение 30 минут после визита, AppsFlyer намеренно откладывает принятие решений по атрибуции на тот же промежуток времени. Эта задержка предотвращает ошибочную классификацию как «органический», позволяя системе получить CUID и правильно связать вернувшихся пользователей с истекшими cookie с их исходным источником.

После определения источника и завершения 30-минутной задержки система переходит к «сшивке» фрагментированных сессий пользователя в единый путь.

• Сшивка CUID: Если получен идентификатор ID пользователя клиента (например, хешированный адрес электронной почты), механизм связывает сессию с кросс-девайс историей пользователя.
• Резервный вариант с cookie: Если CUID недоступен, система использует cookies браузера, хотя они менее стабильны и привязаны к конкретному устройству.

После определения личности пользователя движок ищет конкретное действие, которое определяет его как привлеченного пользователя. В индустрии стандартом считается first_visit, но это часто слабый сигнал: пользователь может случайно кликнуть по рекламе или сразу уйти. Если задать пользовательское событие привлечения, например регистрацию или покупку, вы обеспечите, что долгосрочная ценность (LTV) будет атрибутирована маркетинговому источнику, который привел к значимому действию, а не просто к случайному клику.

Когда происходит событие привлечения пользователя, движок атрибуции ищет в прошлом период, равный окну атрибуции (привлечение пользователей), чтобы найти неорганический визит, которому можно назначить атрибуцию. Этот параметр определяет максимально допустимое время между визитом пользователя и завершением UA-события (по умолчанию: 30 дней). Если в пределах этого окна ретроспективы не найдена неорганическая точка взаимодействия, UA-событие считается органическим и не атрибутируется. Длительность окна атрибуции для пользовательского события можно настроить при добавлении веб-приложения в AppsFlyer, см. Окно атрибуции (привлечение пользователей).

В зависимости от бизнес-модели в качестве триггера привлечения пользователя можно определить разные события, например

• Событие завершения регистрации (например, в банковском приложении). Событие привлечения срабатывает только после успешного завершения процесса регистрации.
• Событие первого заказа (например, в приложении доставки еды). Просмотр или добавление товаров не учитываются; событие срабатывает только после успешной транзакции.
• Событие активации подписки (например, в стриминговом или SaaS-приложении). Событие привлечения регистрируется, когда подписка подтверждена, а не при начале пробного периода или установке приложения.

Подробнее о настройке события привлечения пользователей см. в разделе Настройки привлечения пользователей.

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

AppsFlyer собирает и атрибутирует эти события до привлечения маркетинговому источнику и помечает их в отчетности как события до привлечения. Ключевое различие между атрибуцией до привлечения и после привлечения — это окно атрибуции. В период до привлечения окно атрибуции короче и соответствует окну ретроспективы UA-события, поскольку эти события происходят до UA-события, которое определяет пользователя как привлеченного. После срабатывания пользовательского UA (привлечение пользователей)-события и привлечения пользователя окно атрибуции расширяется для измерения LTV, чтобы в долгосрочной перспективе засчитывать результат маркетинговому источнику, который привлек пользователя.

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

Хотя повторное вовлечение ориентировано на существующих пользователей, возврат также может классифицироваться как повторное привлечение, если пользователь был неактивен в течение длительного периода. Чтобы иметь право на повторное привлечение, пользователь должен сначала выйти за пределы окна неактивности (по умолчанию: 90 дней), которое определяет период неактивности, необходимый, чтобы считать пользователя «ушедшим». После окончания этого окна, если пользователь возвращается, система фиксирует новое событие привлечения пользователя, а не стандартное повторное посещение.

Подробнее см. в разделах Настройки повторного вовлечения и Настройки повторного привлечения

Независимо от того, пришел ли пользователь через первоначальную кампанию привлечения или в результате последующего ретаргетинга, конечная цель — измерить его общую ценность с течением времени. После того как пользователь успешно атрибутирован к источнику, система измеряет его дальнейшую активность, чтобы рассчитать Lifetime Value (LTV).

Это измерение регулируется окном атрибуции, которое по умолчанию установлено в значение «Навсегда». Это гарантирует, что каждое последующее действие, например повторные покупки или продления подписки, будет отнесено к исходному маркетинговому источнику, который привел пользователя на сайт. Собирая эти долгосрочные данные, вы можете не ограничиваться простым подсчетом конверсий и определить фактический возврат рекламных расходов (ROAS) для своих кампаний.

Подробнее о настройке окна атрибуции см. в разделе Окно атрибуции.