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

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

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

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

Для получения более подробной информации см. Регистрация посещений .

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

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

Для получения более подробной информации см. раздел «Определение медиаисточника» .

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

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

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

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации см. разделы «Настройки повторного вовлечения» и «Настройки повторного привлечения».

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

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

Для получения дополнительной информации о настройке Окна атрибуции см. Окно атрибуции» .