En bref : découvrez les différences entre les modèles d'attribution des Meta ads et d'AppsFlyer.
Discordances entre les Meta ads et AppsFlyer
En tant qu'acteurs majeurs dans l'écosystème d'acquisition des utilisateurs mobile, AppsFlyer et Meta ads diffèrent dans leurs modèles d'attribution. Cette situation peut entraîner des discordances entre les tableaux de bord de Meta ads et d'AppsFlyer.
Même si nous travaillons en étroite collaboration avec Meta ads pour réduire ces discordances, les annonceurs doivent être conscients des conséquences suivantes.
Comment détecter les écarts entre AppsFlyer et Meta ads
Comparez les événements répertoriés dans le Gestionnaire d'événements de Meta ads à ceux des rapports AppsFlyer. Si le nombre d'événements varie considérablement, cela peut indiquer une anomalie.
Discordances dans les modèles d'attribution
| Cause | Meta Ads | AppsFlyer |
|---|---|---|
|
Clic sur la fenêtre rétrospective d'attribution |
7 jours (sachez que dans certains cas précis la valeur par défaut est différente). |
1-30 jours. Assurez-vous de définir sur 7 jours avec Meta ads. |
|
Fenêtre rétrospective d'attribution post vue |
1 jour (sachez que dans certains cas précis la valeur par défaut est différente). |
1 jour par défaut, mais peut être configuré de 1 à 48 heures (conserver cette valeur par défaut) |
|
Attribution |
Meta ads attribue les installations de manière indépendante sans se soucier des autres sources média. |
AppsFlyer utilise l'attribution du dernier clic (plus d'informations sur l'attribution AppsFlyer disponibles ici). |
|
Attribution inter-appareils |
Meta ads attribue ses utilisateurs qui cliquent puis installent sur différents appareils, par exemple iOS / Android / ordinateur de bureau. |
AppsFlyer attribue des appareils uniques, qui effectuent à la fois l'engagement et l'installation |
|
Différents fuseaux horaires |
Le fuseau horaire par défaut des Meta ads est PST. Veillez à le modifier dans Meta Ads Manager pour qu'il corresponde à celui qui a été défini dans les paramètres de l'app du côté d'AppsFlyer. |
Le fuseau horaire par défaut d'AppsFlyer est UTC + 0. Vous pouvez modifier le fuseau horaire défini pour l'app sur la page paramètres de l'app afin de correspondre au fuseau horaire défini dans Meta Ads Manager. |
|
Référent d'installation Google |
Lorsqu'une installation dénuée d'ID d'annonceur a été attribuée à Meta Ads à l'aide du référent d'installation Google Play, AppsFlyer ne la rapportera pas à Meta Ads. Cela entraînera des résultats différents car elle s’affichera chez AppsFlyer, mais pas dans Meta Ads. |
|
|
AEM pour le partage des données |
Pour le partage de données AEM, Meta ads reçoit tous les événements de conversion. Ces attributions supplémentaires n'apparaissent pas dans AppsFlyer. Les écarts de résultat entre les deux plateformes sont donc plus importants en ce qui concerne le nombre d'installations (la majorité des cas), et le nombre d'événements in-app, ce qui inclut les sessions. |
|
Attribution post clic et post vue
AppsFlyer prend en charge aussi bien l'attribution post clic que l'attribution post vue. Pour éviter les écarts entre les Meta ads et AppsFlyer, faites en sorte que les fenêtres de réattribution post-clic et post-vue soient en accord avec les fenêtres par défaut des Meta ads.
Par défaut, la fenêtre rétrospective post-clic des Meta ads est définie sur 7 jours. Même si dans certains cas la valeur par défaut est différente, nous vous conseillons de définir la fenêtre rétrospective post-clic sur 7 jours dans AppsFlyer, et ce afin de couvrir toutes les options par défaut des Meta Ads.
Pour comparer les fenêtres d'attribution post clic et post vue sur Meta ads avec celles d'AppsFlyer, merci de consulter le site Meta ads. Nous vous recommandons de configurer les fenêtres d'attribution sur AppsFlyer d'après les valeurs de Meta ads, telles qu'indiquées dans la capture d'écran suivante :
Exemple
Supposons que la fenêtre rétrospective de clic de Meta ads est définie sur 1 jour pour votre app com.greatapp sur AppsFlyer, mais qu'elle est de 7 jours par défaut sur Meta ads. Les utilisateurs qui cliquent sur l'annonce de Greatapp sur Facebook, mais qui lancent l'application pour la première fois au bout de 2 à 7 jours, sont attribués en tant qu'utilisateurs organiques sur AppsFlyer, alors que Meta ads déclare automatiquement ces utilisateurs.
Différences de médias restreints
Depuis le 28 octobre 2021, les données d'attribution des utilisateurs apportées par l'attribution post vue (VTA) sont limitées et ne sont pas disponibles pour les annonceurs.Depuis le 29 octobre 2021, les restrictions s'appliquent aux utilisateurs dont l'attribution se fait à la fois par vue et par clic. Les rapports agrégés ne sont pas concernés par cette mesure.
Comme Meta ads ne transmet aucune données de niveau utilisateur, il peut arriver que AppsFlyer n'attribue pas les impressions ou les clics de conversions à Meta ads.
Exemple
- Un utilisateur consulte ou clique sur une publicité dans Facebook pour AwesomeApp. Plus tard, il consulte et clique sur une publicité GreatAdNetwork pour AwesomeApp, puis il l'installe.
- Meta ads revendique la conversion puisqu’elle a eu lieu durant sa fenêtre rétrospective.
- AppsFlyer attribue la conversion à GreatAdNetwork, car ils ont eu le dernier engagement avant l'installation.
- Comme les données brutes de Meta ads sont limitées, AppsFlyer ne verra pas Meta ads comme un réseau d'aide à la conversion.
Toutefois, pour l'attribution posts clic, si l'annonce dirige les utilisateurs vers le Google Play Store, les champs d'attribution sont disponibles pour les annonceurs dans le référent d'installation Google. Les champs fournis via le référent peuplent les rapports de données brutes AppsFlyer mis à votre disposition et permettent à AppsFlyer d'attribuer des utilisateurs qui n'ont pas d'identifiant publicitaire (option LAT activée).
Discordances entre les événements in-app
Les différences entre les plateformes peuvent aussi se présenter avec les événements en post-installation (ex : achats in-app) qui s'affichent sur Meta ads et sur AppsFlyer. Le tableau suivant détaille les principales causes qui provoquent ces décalages, et propose des solutions pour les minimiser :
| Cause | Description | Conseil d'AppsFlyer |
|---|---|---|
|
Auto-attribution |
Meta ads attribue toujours les événements aux campagnes qui les ont générés, tandis que AppsFlyer attribue ces événements à la source d'acquisition. |
Les installations et événements que Facebook s'auto-attribue à tort portent la mention assistances dans AppsFlyer. |
| Définition différente de la durée de vie | La durée lifetime des utilisateurs monte à 7 jours sur Meta ads, ce qui signifie que Meta ads ne montre pas les événements qui se produisent plus de 7 jours après le clic sur une publicité. La durée Lifetime des utilisateurs Meta ads sur AppsFlyer est fixée à 180 jours. |
Lorsque vous évaluez la valeur des utilisateurs à partir des campagnes Meta ads remontant à plus de 7 jours, utilisez les données d'AppsFlyer pour obtenir de meilleurs résultats. |
| Événements non mappés | AppsFlyer reçoit les événements provenant du SDK, mais ils ne sont pas mappés sur Meta ads, et ne sont donc pas envoyés. | Assurez-vous de mapper à Meta ads tous les événements in-app qui indiquent la qualité des utilisateurs. |
| Revenu non envoyé | AppsFlyer obtient le revenu des événements générés par le SDK, mais ils ne sont pas envoyés à Meta ads. | Vérifiez que les cases Envoyer les revenus des événements in-app sont bien cochées, par exemple l'événement d'achat dans la capture d'écran ci-dessous. |
| Valeurs d'évenement manquantes dans Meta ads | AppsFlyer envoie les paramètres et les valeurs à Meta ads dans le cadre du mappage des événements, s'ils possèdent les structures appropriées. | Créez vos événements in-app de SDK conformément aux structures recommandées par AppsFlyer pour assurer le mappage intégral des valeurs d'événement avec Meta ads. |
Installation à partir des campagnes de réengagement dans Mon tableau de bord AU
Une campagne de réengagement peut amener les utilisateurs à ouvrir une application déjà installée (réengagement). Autrement, si AppsFlyer reconnaît qu'une installation précédente de l'application existait sur le même appareil, il peut assimiler cette conversion à une réattribution.
Si, lors d'une campagne de réengagement, Meta ads cible de nouveaux utilisateurs ou des utilisateurs qui ont installé l'application pour la première fois après un délai excédant la fenêtre de réattribution définie après l'installation initiale, ces utilisateurs sont enregistrés en tant que nouvelles installations d'acquisition utilisateur sur AppsFlyer , appartenant à des campagnes de réengagement sur Meta ads.
En revanche, les installations intervenant pendant la fenêtre de réattribution définie à la suite de l'installation initiale, sont considérées comme des réattributions et apparaissent sur la page de retargeting d'AppsFlyer, alors qu'elles peuvent apparaître comme de nouvelles installations sur Meta ads.
Note
Alors que Meta ads affiche toutes les installations d'une campagne de retargeting au même endroit, sur le tableau de bord AppsFlyer, les installations sont réparties entre la page Présentation (nouvelles installations) et la page Retargeting (réattribution et réengagements).
Attribution inter-appareils
Rapports Meta ads sur l'attribution inter-appareils. Cette opération peut parfois entraîner des problèmes lorsqu'une campagne pour une plate-forme (iOS/Android) montre des installations sur une autre plateforme.
Exemple
Sur son téléphone Android, Linda clique sur une annonce mobile de GreatApp dans Facebook. Facebook enregistre le clic effectué par Linda dans le cadre de la campagne d'origine ciblée Android «Android / Femmes». Linda décide d'installer GreatApp sur son iPad personnel. Au premier lancement, AppsFlyer demande à Meta ads l'origine de cette installation iOS, et Meta ads répond en indiquant la campagne « Android / Femmes ».
Règles de validation et Protect360
Si vous utilisez les règles de validation d'AppsFlyer, les résultats peuvent différer entre AppsFlyer et Meta ads lorsque des installations provenant de Meta ads sont rejetées. Dans ces cas précis, Facebook s'auto-attribue ces installations, tandis que AppsFlyer rejette les mêmes installations.
De même, si vous utilisez la solution antifraude AppsFlyer, Protect360, vous pouvez constater des installations, puisque Meta ads s'auto-attribue tandis que AppsFlyer rejette.
Exemple
Jeff, directeur AU de GreatApp, crée une campagne appelée SPNA, qui cible uniquement les hispanophones basés en Amérique du Nord. Pour ce faire, Jeff définit une règle de validation qui accepte exclusivement les utilisateurs basés au Canada et aux États-Unis.
Lorsqu'un utilisateur Meta ads résidant en Espagne clique et installe l'app, Meta ads s'auto-attribue l'installation, tandis qu'AppsFlyer rejette toutes les installations qui ne suivent pas la règle de validation.
Écarts liés au SDK
Il peut arriver que des annonceurs implémentent à la fois des SDK AppsFlyer et Facebook. Cela peut entraîner des divergences de résultat, tant pour les événements in-app que pour les événements in-app. Meta Ads ne redivise pas pas les événements in-app rapportés par les deux SDK à la fois. Cela signifie que Meta Ads peut rapporter des revenus ou d'autres événements de manière incorrecte.
- Utilisez l'une des méthodes suivantes pour éviter la création de rapports dupliqués sur les évènements in-app dans Meta ads :
- Ne configurez pas les évènements dans le SDK Facebook.
- Désactivez le mappage des évènements in-app Meta ads à partir d'AppsFlyer.