Краткий обзор. Узнайте о различиях в моделях атрибуции Facebook Ads и AppsFlyer.
Расхождения в данных Facebook и AppsFlyer
AppsFlyer и Facebook — это два основных участника экосистемы мобильных приложений, работающие в сфере привлечения пользователей. И так же, как и другие участники этой экосистемы, они используют разные модели атрибуции. Это может привести к расхождениям между данными на панелях управления Facebook и AppsFlyer.
Хотя мы и работаем в тесном сотрудничестве с Facebook, чтобы свести к минимуму такие расхождения, рекламодатели должны знать о том, с чем они связаны (см. ниже).
Обнаружить расхождение между AppsFlyer и Facebook
Сравните события, перечисленные в Facebook Event Manager, с событиями в отчетах AppsFlyer. Если количество событий существенно различается, возможно расхождение.
Различия в моделях атрибуции
| Причина | AppsFlyer | |
|---|---|---|
|
Окно ретроспективного обзора по нажатиям |
7 дней. (Обратите внимание, что есть некоторые конкретные случаи, когда значение по умолчанию отличается). |
1-30 дней. Установите на 7 дней, как в Facebook. |
|
Окно ретроспективного обзора атрибуции по просмотрам |
1 день. (Обратите внимание, что есть некоторые конкретные случаи, когда значение по умолчанию отличается). |
По умолчанию установлено значение 1 день, но можно задать значение от 1 до 48 часов (не изменяйте значение по умолчанию). |
|
Многоканальная атрибуция |
Facebook автоматически атрибутирует установки себе, независимо от того, из каких медиа-источников они получены. |
AppsFlyer использует атрибуцию по последнему клику (подробнее об атрибуции в AppsFlyer). |
|
Атрибуция на нескольких устройствах |
Facebook атрибутирует своих пользователей, которые выполняют клики и установку на разных устройствах, включая устройства iOS, Android и настольные компьютеры. |
AppsFlyer атрибутирует отдельные устройства, на которых происходит вовлечение и установка. |
|
Различные часовые пояса |
Часовой пояс по умолчанию для объявлений Facebook — PST (UTC-8). Измените часовой пояс в Facebook Ads Manager, чтобы он соответствовал часовому поясу приложения, указанному в настройках AppsFlyer. |
Часовой пояс по умолчанию в AppsFlyer UTC+0. Вы можете изменить настройки часового пояса для приложения на странице настроек приложения, чтобы он соответствовал часовому поясу в Facebook Ads Manager. |
|
Реферер установки Google |
Если установка без идентификатора рекламодателя была атрибутирована Facebook Ads с помощью реферера установки Google Play, AppsFlyer не сообщает об этом Facebook Ads. Это приведет к расхождению, поскольку установка будет отображаться в AppsFlyer, но не в Facebook Ads. |
|
|
Атрибуция после повторного привлечения по диплинку |
О повторном привлечении по диплинку не сообщается в Facebook Ads. Это приведет к расхождению, поскольку оно будет отображаться в AppsFlyer, но не в Facebook Ads. |
|
Атрибуция по нажатиям и просмотрам
AppsFlyer поддерживает атрибуцию как по кликам, так и по просмотрам. Чтобы минимизировать расхождения между платформами Facebook Ads и AppsFlyer, настройте окна атрибуции по кликам и просмотрам так же, как в Facebook Ads.
В Facebook Ads окно атрибуции по кликам по умолчанию составляет 7 дней. Хотя есть некоторые конкретные случаи, когда значение по умолчанию отличается, рекомендуется установить окно атрибуции по кликам в AppsFlyer в 7 дней, чтобы охватить все параметры Facebook Ads по умолчанию.
Чтобы сравнить окна атрибуции по кликам и просмотрам в Facebook и AppsFlyer, зайдите в Facebook. Рекомендуется настраивать окна атрибуции в AppsFlyer в соответствии с настройками в Facebook, как показано на этом снимке экрана:
Пример
Предположим, что в AppsFlyer для кампании в Facebook по продвижению вашего приложения com.greatapp установлено окно атрибуции по кликам в 1 день, а в Facebook для этого окна по умолчанию задан период 7 дней. Пользователи, которые нажимают на рекламу приложения greatapp в Facebook, но впервые запускают приложение через 2-7 дней, в AppsFlyer атрибутируются как органические, а Facebook автоматически атрибутирует этих пользователей себе.
Расхождения между ограниченными медиа-источниками
До 28 октября 2021 года данные атрибуции по пользователям, привлеченным в результате конверсии с атрибуцией по просмотрам (VTA), были ограничены и не доступны рекламодателям.
С 29 октября 2021 года ограничения начинают действовать в отношении пользователей, привлеченных с атрибуцией как по просмотрам, так и по кликам. Это не распространялось на агрегированную отчетность.
Facebook Ads не отправляет данные уровня пользователя, поэтому AppsFlyer может не атрибутировать Facebook Ads показы и клики, способствующие конверсии.
Пример
- Пользователь видит рекламу СуперПриложения в Facebook или кликает по ней. Позже он видит рекламу СуперПриложения в другом рекламном источнике GreatAdNetwork, кликает по ней и устанавливает приложение.
- Facebook Ads приписывает конверсию себе, так как установка произошла в рамках их окна атрибуции.
- AppsFlyer атрибутирует конверсию источнику GreatAdNetwork, так как у него было последнее взаимодействие перед установкой.
- AppsFlyer не будет считать Facebook Ads сетью, в которой произошла конверсия, поскольку сырые данные Facebook Ads ограничены.
Однако в случае атрибуции по кликам, если реклама ведет пользователей напрямую в Google Play, поля атрибуции доступны рекламодателям в Google Install Referrer. Поля, предоставленные через реферер, поступают в доступные вам отчеты AppsFlyer с сырыми данными. Благодаря этому AppsFlyer может атрибутировать пользователей, у которых нет рекламного идентификатора (с включенным LAT).
Расхождения между внутренними событиями приложения
Отличия между платформами могут влиять и на события после установки (например, события покупок в приложении), которые отображаются в Facebook и в AppsFlyer. В этой таблице описаны наиболее распространенные причины этих различий и даны рекомендации по их минимизации:
| Причина | Описание | Совет AppsFlyer |
|---|---|---|
|
Атрибуция собственных событий |
Facebook всегда атрибутирует события своим собственным кампаниям, в результате которых эти события произошли, а AppsFlyer атрибутирует эти события источнику привлечения пользователя. |
Установки и события, которые Facebook некорректно атрибутировал своей сети, указаны как вспомогательные установки в AppsFlyer. |
| Разница в определении жизненного цикла | Жизненный цикл пользователя на Facebook считается до 7 дней, то есть Facebook не показывает события, если они произошли более чем через 7 дней после клика по рекламе. В AppsFlyer жизненный цикл пользователя Facebook определяется как период до 180 дней. |
При определении ценности пользователей из кампаний Facebook, проведенных по истечении 7 дней, используйте данные AppsFlyer, чтобы получить более широкую картину. |
| Несопоставленные события | AppsFlyer получает события, которые происходят в SDK, однако они не сопоставлены с событиями в Facebook и поэтому не отправляются. | Обязательно сопоставьте с Facebook все внутренние события приложения, которые демонстрируют качество пользователей. |
| Неотправленные данные о выручке | AppsFlyer получает данные о выручке из событий, которые происходят на уровне SDK, однако они не отправляются в Facebook. | Обязательно установите для внутренних событий приложения флажки Send Revenue (Отправлять данные о доходе). Например, на скриншоте ниже флажок установлен для события покупки. |
| Потеря данных событий при отправке в Facebook | AppsFlyer отправляет в Facebook параметры и их значения в рамках процесса сопоставления событий при условии, что эти данные имеют правильную структуру. | Чтобы обеспечить полноценное сопоставление значений события с событием Facebook, используйте при создании внутренних событий SDK структуры, рекомендованные AppsFlyer. |
Установки, инициированные кампаниями повторного вовлечения, отображаются на панели управления "Привлечение пользователей"?
Кампания повторного вовлечения может побудить пользователей открыть уже установленное приложение (повторное вовлечение). Если AppsFlyer обнаруживает, что приложение уже было установлено на этом же устройстве, то такая конверсия будет считаться повторной атрибуцией.
Если кампания повторного вовлечения в Facebook нацелена на приобретение новых пользователей или таких пользователей, которые снова установили приложение по истечении заданного окна повторной атрибуции после первоначальной установки, то эти пользователи регистрируются в AppsFlyer как новые, а установки этих пользователей считаются результатом кампании по привлечению новых пользователей. При этом в Facebook эти установки относятся к кампаниям по повторному вовлечению.
Что касается установок, которые происходят в пределах заданного окна повторной атрибуции после первоначальной установки, то они регистрируются как повторная атрибуция и отображаются в AppsFlyer на странице ретаргетинга. При этом в Facebook они могут рассматриваться как новые установки.
Примечание
В Facebook все установки, инициированные кампанией ретаргетинга, отображаются в одном и том же месте. На панели управления AppsFlyer установки учитываются на странице обзора (новые установки) или на странице ретаргетинга (повторная атрибуция или повторное вовлечение).
Атрибуция на нескольких устройствах
Facebook включает в отчеты атрибуцию на нескольких устройствах. В отдельных случаях из-за этого могут возникать проблемы ; например, в данных кампании для одной из платформ (iOS или Android) могут отображаться установки, выполненные на другой платформе.
Пример
Линда нажимает в Facebook на рекламу мобильного приложения GreatApp, используя свой телефон на базе Android. Facebook регистрирует нажатие Линды в данных кампании "Android Females", ориентированной на платформу Android. Линда решает установить приложение GreatApp на планшете iPad. После первого запуска AppsFlyer запрашивает у Facebook сведения об источнике этой установки на платформе iOS, и Facebook сообщает, что источником является кампания "Android Females".
Правила проверки и Protect360
Если вы используете Правила проверки AppsFlyer, то в случае отклонения установок, источником которых является Facebook, результаты в AppsFlyer и Facebook могут отличаться. В таких случаях Facebook автоматически атрибутирует эти установки себе, а AppsFlyer эти же установки отклоняет.
Такая же ситуация возникает при использовании решения AppsFlyer для защиты от мошенничества Protect360, так как Facebook может атрибутировать себе те установки, которые AppsFlyer отклоняет.
Пример
Джефф, менеджер по привлечению пользователей в компании GreatApp, создает кампанию под названием SPNA, которая ориентирована только на испаноязычных жителей Северной Америки. Чтобы обеспечить нужный таргетинг, Джефф устанавливает правило проверки, которое позволит пропускать пользователей только из США и Канады.
Если на объявление нажмет пользователь Facebook из Испании и затем установит приложение, Facebook автоматически атрибутирует эту установку себе, а AppsFlyer эту установку отклонит, так как она не соответствует правилу проверки.
Расхождения, связанные с SDK
В некоторых случаях рекламодателям требуется внедрить и SDK AppsFlyer, и SDK Facebook Ads. Это может вызывать расхождения в данных по установкам и внутренним событиям приложения:
- Установки. Если SDK Facebook Ads инициализируется при запуске приложения до SDK AppsFlyer, установка регистрируется только Facebook Ads и не фиксируется AppsFlyer. Убедитесь, что SDK AppsFlyer инициализируется при запуске приложения до SDK Facebook Ads.
-
Внутренние события. Facebook Ads не удаляет дубликаты внутренних событий, которые регистрируются обоими SDK. Это значит, что Facebook Ads может передавать ошибочные данные о доходе и других событиях.
Чтобы предотвратить дублирование данных о внутренних событиях приложения в отчетах Facebook Ads, воспользуйтесь одним из следующих методов:- Не выполняйте настройку событий в SDK Facebook.
- Отключите в AppsFlyer сопоставление внутренних событий приложения с событиями в Facebook.