Краткий обзор. Узнайте о различиях в моделях атрибуции Meta Ads и AppsFlyer.
Расхождения в данных Meta Ads и AppsFlyer
Если установка без идентификатора рекламодателя была атрибутирована Meta Ads с помощью реферера установки Google Play, AppsFlyer не сообщает об этом в Meta Ads. Это приведет к расхождению, поскольку установка будет отображаться в AppsFlyer, но не в Meta Ads.
Хотя мы и работаем в тесном сотрудничестве с Meta Ads, чтобы свести к минимуму такие расхождения, рекламодатели должны знать о том, с чем они связаны (см. ниже).
Обнаружение расхождений между AppsFlyer и Meta Ads
Сравните события, перечисленные в Meta Ads Event Manager, с событиями в отчетах AppsFlyer. Если количество событий существенно различается, возможно расхождение.
Различия в моделях атрибуции
| Причина | Meta Ads | AppsFlyer: |
|---|---|---|
| Окно ретроспективного обзора по нажатиям | 7 дней. (Обратите внимание, что есть некоторые конкретные случаи, когда значение по умолчанию отличается). | 1-30 дней. Установите на 7 дней, как в Meta Ads. |
| Окно ретроспективного обзора атрибуции по просмотрам | 1 день. (Обратите внимание, что есть некоторые конкретные случаи, когда значение по умолчанию отличается). | По умолчанию установлено значение 1 день, но можно задать значение от 1 до 48 часов (не изменяйте значение по умолчанию). |
|
Многоканальная атрибуция источников |
Meta Ads автоматически атрибутирует установки себе, независимо от того, из каких медиа-источников они получены. | AppsFlyer использует атрибуцию по последнему клику (подробнее об атрибуции в AppsFlyer). |
| Атрибуция на различных устройствах | Meta Ads атрибутирует своих пользователей, которые выполняют клики и установку на разных устройствах, включая устройства iOS, Android и настольные компьютеры. | AppsFlyer атрибутирует отдельные устройства, на которых происходит вовлечение и установка. |
| Различные часовые пояса | Часовой пояс по умолчанию для Meta Ads — PST (UTC-8). Измените часовой пояс в Meta Ads Manager, чтобы он соответствовал часовому поясу приложения, указанному в настройках AppsFlyer. | Часовой пояс по умолчанию в AppsFlyer UTC+0. Вы можете изменить настройки часового пояса для приложения на странице настроек приложения, чтобы он соответствовал часовому поясу в Meta Ads Manager. |
| Рефереры установки | Если вы используете Правила проверки AppsFlyer, то в случае отклонения установок, источником которых является Meta Ads, результаты в AppsFlyer и Meta Ads могут отличаться. В таких случаях Meta Ads автоматически атрибутирует эти установки себе, а AppsFlyer эти же установки отклоняет. | |
Атрибуция по нажатиям и просмотрам
AppsFlyer поддерживает атрибуцию как по кликам, так и по просмотрам. Чтобы минимизировать расхождения между платформами Meta Ads и AppsFlyer, настройте окна атрибуции по кликам и просмотрам так же, как в Meta Ads.
В Meta Ads окно атрибуции по кликам по умолчанию составляет 7 дней. Хотя есть некоторые конкретные случаи, когда значение по умолчанию отличается, рекомендуется установить окно атрибуции по кликам в AppsFlyer в 7 дней, чтобы охватить все параметры Meta Ads по умолчанию.
Рекомендуется настраивать окна атрибуции в AppsFlyer в соответствии с настройками в Meta Ads, как показано на этом снимке экрана: См. документацию Meta for Developers о сравнении настроек атрибуции. См. документацию Meta for Developers о сравнении настроек атрибуции.
Пример
Предположим, что в AppsFlyer для кампании в Meta Ads по продвижению вашего приложения com.greatapp установлено окно атрибуции по кликам в 1 день, а в Meta Ads для этого окна по умолчанию задан период 7 дней. Пользователи, которые нажимают на рекламу приложения greatapp в Facebook, но впервые запускают приложение через 2-7 дней, в AppsFlyer атрибутируются как органические, а Meta Ads автоматически атрибутирует этих пользователей себе.
Расхождения между внутренними событиями приложения
Отличия между платформами могут влиять и на события после установки (например, события покупок в приложении), которые отображаются в Meta Ads и в AppsFlyer. В этой таблице описаны наиболее распространенные причины этих различий и даны рекомендации по их минимизации:
| Причина | Описание | Совет AppsFlyer |
|---|---|---|
| Разница в определении жизненного цикла | Жизненный цикл пользователя в Meta Ads считается до 7 дней, то есть Meta Ads не показывает события, если они произошли более чем через 7 дней после клика по рекламе. В AppsFlyer жизненный цикл пользователя Meta Ads определяется как период до 180 дней. |
При определении ценности пользователей из кампаний Meta Ads, проведенных по истечении 7 дней, используйте данные AppsFlyer, чтобы получить более широкую картину. |
| Несопоставленные события | AppsFlyer получает события, которые происходят в SDK, однако они не сопоставлены с событиями в Meta Ads и поэтому не отправляются. | Обязательно сопоставьте с Meta Ads все внутренние события приложения, которые демонстрируют качество пользователей. |
| Неотправленные данные о выручке | AppsFlyer получает данные о доходе из событий, которые происходят на уровне SDK, однако они не отправляются в Meta Ads. | Обязательно установите для внутренних событий приложения флажки Send Revenue (Отправлять данные о доходе). Например, на скриншоте ниже флажок установлен для события покупки. |
| Потеря данных событий при отправке в Meta Ads | AppsFlyer отправляет в Meta Ads параметры и их значения в рамках процесса сопоставления событий при условии, что эти данные имеют правильную структуру. | Чтобы обеспечить полноценное сопоставление значений события с событием Meta Ads, используйте при создании внутренних событий SDK структуры, рекомендованные AppsFlyer. |
| Атрибуция собственных событий | Количество определенного события в приложении (например, события покупки) на дэшборде Facebook (FB) отличается от соответствующего количества на дэшборде AppsFlyer (AF). | Дэшборд Facebook (FB) основан на активности, а дэшборды AppsFlyer (AF) Overview и Event — на LTV. Для сравнения количества событий используйте дэшборд AF, основанный на активности. Для получения дополнительной информации см. LTV vs. Activity |
Установки, инициированные кампаниями повторного вовлечения, отображаются на панели управления "Привлечение пользователей"?
Кампания повторного вовлечения может побудить пользователей открыть уже установленное приложение (повторное вовлечение). Если AppsFlyer обнаруживает, что приложение уже было установлено на этом же устройстве, то такая конверсия будет считаться повторной атрибуцией.
Если кампания повторного вовлечения в Meta ads нацелена на новых пользователей или пользователей, которые впервые установили приложение по истечении срока, превышающего заданное окно реатрибуции после первоначальной установки, эти пользователи регистрируются как новые установки по привлечению пользователей в AppsFlyer, которые в Meta ads относятся к кампаниям повторного вовлечения.
Что касается установок, которые происходят в пределах заданного окна реатрибуции после первоначальной установки, то они регистрируются как реатрибуция и отображаются в AppsFlyer на странице ретаргетинга. При этом в Meta Ads они могут рассматриваться как новые установки.
Примечание
В Meta Ads все установки, инициированные кампанией ретаргетинга, отображаются в одном месте. На дэшборде AppsFlyer установки учитываются на странице «Обзор» (новые установки) или «Ретаргетинг» (реатрибуция или повторное вовлечение).
Атрибуция на различных устройствах
Meta Ads включает в отчеты атрибуцию на нескольких устройствах. В отдельных случаях из-за этого могут возникать проблемы ; например, в данных кампании для одной из платформ (iOS или Android) могут отображаться установки, выполненные на другой платформе.
Пример
Линда нажимает в Facebook на рекламу мобильного приложения GreatApp, используя свой телефон на базе Android. Meta Ads регистрирует клик Линды в данных кампании «Android Females», ориентированной на платформу Android. Линда решает установить приложение GreatApp на планшете iPad. После первого запуска AppsFlyer запрашивает у Meta Ads сведения об источнике этой установки на платформе iOS, и Meta Ads сообщает, что источником является кампания «Android Females».
Правила проверки и Protect360
Если кампания повторного вовлечения в Meta Ads нацелена на приобретение новых пользователей или таких пользователей, которые снова установили приложение по истечении заданного окна повторной атрибуции после первоначальной установки, то эти пользователи регистрируются в AppsFlyer как новые, а установки этих пользователей считаются результатом кампании по привлечению новых пользователей. При этом в Meta Ads эти установки относятся к кампаниям по повторному вовлечению.
Такая же ситуация возникает при использовании решения AppsFlyer для защиты от мошенничества Protect360, так как Meta Ads может атрибутировать себе те установки, которые AppsFlyer отклоняет.
Пример
Джефф, менеджер по привлечению пользователей в компании GreatApp, создает кампанию под названием SPNA, которая ориентирована только на испаноязычных жителей Северной Америки. Чтобы обеспечить нужный таргетинг, Джефф устанавливает правило проверки, которое позволит пропускать пользователей только из США и Канады.
Если на объявление нажмет пользователь Meta Ads из Испании и затем установит приложение, Meta Ads автоматически атрибутирует эту установку себе, а AppsFlyer эту установку отклонит, так как она не соответствует правилу проверки.
Расхождения, связанные с SDK
В некоторых случаях рекламодателям требуется внедрить и SDK AppsFlyer, и SDK Facebook. Это может вызывать расхождения в данных по внутренним событиям приложения. Meta Ads не удаляет дубликаты внутренних событий, которые регистрируются обоими SDK. Это значит, что Meta Ads может передавать ошибочные данные о доходе и других событиях.
- Чтобы предотвратить дублирование данных о внутренних событиях приложения в отчетах Meta Ads, воспользуйтесь одним из следующих методов:
- Не выполняйте настройку событий в SDK Facebook.
- Отключите в AppsFlyer сопоставление внутренних событий приложения с событиями в Meta Ads.
Расхождения при вероятностном моделировании Meta (AEM) в приложениях iOS
Если для приложений iOS включено Aggregated Event Measurement (AEM), Meta может атрибутировать установки или события в приложении с помощью своего вероятностного моделирования. Meta может применять в своей внутренней отчетности методы моделирования, отличающиеся от тех, которыми она делится с AppsFlyer. Из-за этих различий в методах моделирования количество установок в Meta Ads Manager и AppsFlyer может различаться — иногда в большую, иногда в меньшую сторону. В частности:
- Meta может внутренне учитывать конверсии, но не отправлять соответствующие AEM-претензии в AppsFlyer.
- Meta может отправить в AppsFlyer AEM-претензию для смоделированной конверсии, которая не отображается в Ads Manager.
This article was translated using AI and may contain errors. For the most accurate information, please refer to the English version using the language selector.