· 17 min · Samet Durgun

Événements d'essai et d'achat inéligibles à Meta AEM : pourquoi ?

Je suis Samet Durgun, fractional Head of UA. Je gère le paid UA pour des apps par abonnement et des jeux mobiles, et j'écris ici ce que je constate dans les comptes que je gère. Cet article fait partie du thème Ingénierie du signal ; en savoir plus sur moi.

Un événement qui arrive dans Events Manager n’est pas encore un événement que vous pouvez optimiser. Meta marque chaque événement iOS comme éligible ou inéligible à Aggregated Event Measurement séparément, et parmi les raisons qu’il liste figurent un événement envoyé par une autre intégration que votre événement d’install, des données manquantes que la voie doit transporter, ou trop peu de signaux sur les 30 derniers jours. Laquelle s’applique dépend de votre voie : RevenueCat qui envoie directement à Meta n’a pas les mêmes exigences que RevenueCat qui envoie à AppsFlyer, lequel poste ensuite vers Meta.

Dans mes comptes, un seul ordre règle généralement le problème : configurer AEM dans Events Manager et activer l’attribution probabiliste dans le MMP, lancer une campagne d’installation, et seulement ensuite déplacer l’optimisation vers l’essai ou l’achat une fois qu’Events Manager le montre éligible. C’est ma pratique, pas un correctif documenté par Meta ; la section sur l’ordre de mise en place plus bas donne le détail.

Périmètre : les campagnes de promotion d’app Meta pour iOS 14+ qui utilisent AEM et optimisent sur des événements d’app ou sur la valeur (les objectifs de Meta “maximize number of app events” et “maximize value of conversions”). Deux voies, gardées séparées tout au long : RevenueCat direct vers Meta, et RevenueCat vers AppsFlyer vers Meta. La section sur l’ordre de mise en place nomme aussi les réglages équivalents dans Adjust et Singular. Rien ici n’est propre à une région. Chaque page d’éditeur ci-dessous a été vérifiée le 29 septembre 2026. Les pages d’aide de Meta n’affichent aucune date et changent sans prévenir : vérifiez-les de nouveau avant d’agir.

Où Meta indique-t-il qu’un événement est inéligible ?

Dans Events Manager. La page de Meta How to check if your app events are eligible for Aggregated Event Measurement donne le chemin : Datasets, votre dataset, l’onglet Settings, Setup tasks for iOS app events, puis Check app eligibility dans la section “Meta’s attribution for iOS 14+”. La colonne Eligibility marque chaque événement comme éligible ou inéligible, More details explique pourquoi, et un statut pending signifie que Meta attend encore ou vérifie des informations venant de votre intégration.

La page de Meta Troubleshoot issues with app eligibility for Aggregated Event Measurement liste chaque message avec ce qu’il peut signifier et le correctif. Notez le message exact et la date avant que quiconque touche au setup, car chaque message de cette page renvoie à un correctif différent.

S’agit-il de réception, de données requises ou d’éligibilité ?

Trois questions différentes se cachent derrière “l’événement ne fonctionne pas” :

  • Réception. Meta a-t-il reçu l’événement ? La page Meta Ads de RevenueCat indique qu’Events Manager peut mettre jusqu’à 24 heures à afficher les événements acceptés.
  • Données requises. L’événement porte-t-il ce dont votre voie a besoin pour AEM ? Cela diffère selon la voie.
  • Éligibilité à l’optimisation. Meta laissera-t-il une campagne l’optimiser ? La page de RevenueCat est explicite : une livraison réussie signifie seulement que Meta a accepté l’événement, et Meta décide encore s’il est éligible à une campagne, à un objectif ou à un rapport.

Le tableau classe les symptômes habituels par couche. La voie compte : une exigence documentée pour une voie ne prouve rien pour l’autre.

Couche Symptôme Système à inspecter Preuve requise Action suivante
Réception StartTrial ou Subscribe absent d’Events Manager (RevenueCat direct) RevenueCat Customer History, ligne de livraison Meta Ads Onglets Request et Response ; pour la Conversions API, le fbtrace_id Pas de ligne : vérifiez les attributs requis et suivez le dépannage de RevenueCat pour une ligne de livraison manquante. Accepté : laissez passer les 24 heures maximum que RevenueCat documente avant de vérifier Events Manager
Réception Événements absents dans AppsFlyer (voie AppsFlyer) Attributs client RevenueCat Si $appsflyerId a été défini avant l’achat Définissez-le après la configuration du SDK Purchases et avant le premier achat
Données requises Peu ou pas d’événements App Store atteignent Meta (RevenueCat direct) Réglages Meta Ads de RevenueCat et attributs client $fbAnonId ou un vrai IDFA, le statut ATT, le réglage “Send events when ATT consent is not authorized” Décidez du réglage de consentement de façon délibérée, avec votre propre revue de confidentialité
Données requises Événements serveur à serveur inéligibles (voie AppsFlyer) Un payload d’événement brut Adresse IP et IDFV présents sur chaque événement Collectez les identifiants d’appareil dans RevenueCat pour que $ip et $idfv soient définis avant l’achat
Données requises “Contact your mobile measurement partner (MMP) to check eligibility steps for Meta’s attribution for iOS 14+” Le dashboard du MMP Si le réglage AEM du MMP est activé Activez-le ; l’ordre de mise en place plus bas le nomme pour chaque MMP
Données requises “IP data version isn’t optimal for setup” L’intégration nommée dans le message Si l’IP est absente ou envoyée de façon incohérente Envoyez l’IP de façon cohérente ; sur la voie AppsFlyer, désactivez le masquage d’IP
Données requises “Advertiser Tracking Enabled parameter volume out-of-range” Statut ATT des événements entrants Part des événements sans tracking activé ou avec un IDFA à zéro Vérifiez le taux de consentement ATT ; Meta renvoie à votre account manager pour celui-ci
Éligibilité “Different integrations across multiple event types” Events Manager, l’événement d’install et l’événement d’essai ou d’achat Quelle intégration envoie chacun Envoyez l’install et l’événement d’optimisation par la même intégration
Éligibilité “Multiple integrations for the same event” Events Manager, Manage event Toutes les sources qui envoient l’événement Choisissez une seule intégration pour l’événement ; supprimez le logging en double côté client
Éligibilité “Not enough signals from last 30 days” Events Manager et l’outil de test des événements Nombre d’événements sur 30 jours Confirmez le setup avec des événements de test, puis regardez quel volume la voie laisse passer
Éligibilité Pending, “Awaiting or verifying information from your integration” Events Manager Date d’apparition du statut Revérifiez sous 3 jours, comme le dit Meta

De quoi la voie RevenueCat direct a-t-elle besoin ?

La page Meta Ads de RevenueCat pose quatre points qui comptent ici.

Le SDK Meta reste. RevenueCat demande de garder le SDK Meta pour l’install, l’activation et les signaux on device ; ses événements serveur à serveur ne remplacent pas le setup du SDK de Meta pour les campagnes d’installation, SKAdNetwork ou AEM. Il recommande la Conversions API plutôt que l’App Events API pour la fiabilité et le support à long terme, et note qu’il peut envoyer les conversions d’essai et les renouvellements quand l’app n’est pas ouverte.

La livraison dépend des identifiants et du consentement. Pour les événements App Store via la Conversions API, RevenueCat ne tente la livraison que si le client a $fbAnonId ou $idfa, plus un statut ATT authorized, sauf si le réglage du dashboard “Send events when ATT consent is not authorized” est activé. Il traite les valeurs d’IDFA vides ou à zéro comme absentes. L’IDFV, l’IP, l’email et le numéro de téléphone ne font pas partie des attributs qu’il exige pour la livraison ; il les liste comme des attributs que Meta peut utiliser pour le matching quand ils sont présents. RevenueCat demande de les définir après la configuration de son SDK et avant le premier achat autant que possible, et de collecter de nouveau les identifiants d’appareil une fois la permission ATT accordée.

RevenueCat dit que laisser le réglage désactivé exige un consentement ATT authorized avant l’envoi des événements App Store. Sa page ne dit pas en toutes lettres dans quel sens démarre une nouvelle intégration : regardez donc le réglage dans votre propre dashboard avant de tirer quoi que ce soit des volumes d’événements de Meta. Ainsi, avec le réglage désactivé, les événements d’essai et d’achat App Store des utilisateurs qui n’ont pas autorisé le tracking ne sont pas envoyés à Meta sur cette voie, et Meta voit moins d’événements que RevenueCat n’en enregistre. Ma lecture : sur un petit compte, c’est un chemin plausible vers “Not enough signals from last 30 days”. Activer le réglage est une décision de confidentialité, pas un ajustement de mesure.

Subscribe est large. Par défaut, RevenueCat mappe Trial Started vers StartTrial, et Trial Converted, Initial Purchase et Renewal tous vers Subscribe. Un achat sans renouvellement va vers fb_mobile_purchase. Le nombre de Subscribe dans Events Manager mélange donc premiers paiements et renouvellements. RevenueCat vous laisse choisir d’autres noms d’événements standard Meta pour ces événements, et note que Meta recommande les événements standard pour optimiser les campagnes. Si quelqu’un a changé le mapping, vérifiez d’abord sur quel nom d’événement votre campagne optimise.

Une source par événement, et la question de l’intégration. RevenueCat demande de supprimer le logging d’achat et de revenu côté client pour les événements qu’il envoie, car le SDK Meta et RevenueCat ne partagent pas d’event_id. La page de dépannage de Meta ajoute une règle qui compte ici : un événement peut être inéligible aux objectifs d’événements d’app ou de valeur quand il arrive par une autre intégration que votre événement d’install, et le correctif est d’utiliser la même intégration pour les deux. La page de Meta About Partner Integrations for app events, dans ses conseils sur l’optimisation de la valeur, nomme le Facebook SDK, un MMP et la Conversions API comme des canaux séparés et demande d’envoyer chaque événement par un seul. Sur la voie directe, les installs viennent du SDK Meta et les essais et paiements de la Conversions API. Les pages Meta citées ici ne disent pas si Meta traite ce couple comme deux intégrations pour cette règle : vérifiez donc l’intégration choisie pour les deux événements dans Events Manager plutôt que de le supposer.

De quoi la voie AppsFlyer a-t-elle besoin ?

RevenueCat envoie les événements à AppsFlyer, qui les poste vers Meta. Deux pages fixent les exigences, et elles diffèrent.

La page d’AppsFlyer Meta Ads Aggregate Event Measurement (AEM) for iOS dit que, pour les événements in app envoyés de serveur à serveur, Meta exige à la fois l’adresse IP et l’IDFV dans le payload de l’événement, et que sans eux l’événement n’est pas éligible à l’attribution Meta dans AEM. La page AppsFlyer de RevenueCat ne marque que $appsflyerId comme requis. Elle liste $idfa, $idfv et $ip comme recommandés, et demande de définir les attributs après la configuration du SDK Purchases et avant le premier achat, en avertissant que certains événements peuvent ne pas être livrés sans l’ID AppsFlyer. Le helper collectDeviceIdentifiers de RevenueCat collecte $idfa, $idfv et $ip. Sur cette voie, traitez “recommandé” comme requis pour AEM, puisqu’AppsFlyer dit que Meta a besoin des deux.

La checklist de dépannage d’AppsFlyer pour les événements inéligibles, dans son ordre, sans son étape pour les campagnes de remarketing :

  1. Advanced Data Sharing activé dans l’intégration Meta Ads (Collaborate, Active Integrations, Meta Ads). Désactivé, seuls les événements des utilisateurs ayant un advertiser ID sont partagés. Le tableau récapitulatif d’AppsFlyer le nomme comme l’interrupteur qui active AEM pour la promotion d’app, et c’est le réglage MMP de l’ordre de mise en place plus bas.
  2. Masquage d’IP désactivé dans App Settings. AppsFlyer dit que les événements avec des IP masquées ne sont pas éligibles.
  3. Adresse IP et IDFV sur chaque événement serveur à serveur.
  4. Taux de consentement ATT revu. Meta accepte un volume limité d’événements avec des IDFA manquants ou à zéro.
  5. Postbacks mappés sur “Send all (including organic)”. La page partenaire de Meta donne le même conseil.
  6. Si les événements restent inéligibles, définissez le trafic MMP comme connexion préférée dans Events Manager.

RevenueCat demande aussi de supprimer le suivi de revenu côté client dans le SDK AppsFlyer pour éviter le double comptage. Ma lecture : cette voie peut placer installs et événements d’essai ou d’achat sur une même intégration, ce que demande le correctif de la même intégration de Meta, tant qu’aucune autre source n’envoie les mêmes événements.

Meta limite-t-il toujours les apps à huit événements ?

La page de Meta “How to configure app events to use Meta’s Aggregated Event Measurement”, qui prévoyait huit emplacements d’événements pour la configuration AEM d’une app, renvoie désormais Page Not Found (vérifié le 29 septembre 2026). Les guides qui vous demandent de classer huit événements d’app pour AEM décrivent donc un setup que Meta ne documente plus. La page About Meta’s Aggregated Event Measurement de Meta dit qu’il déploie progressivement des mises à jour des campagnes d’app, et qu’avec elles vous pouvez lancer des campagnes de promotion d’app sans configurer d’événements d’app pour SKAdNetwork, avec davantage d’événements d’app disponibles pour l’optimisation. Le classement des événements que Meta documente encore relève de la configuration SKAdNetwork : sa page About value sets y décrit des priority IDs de 1 à 63, et dit qu’il n’est pas nécessaire d’activer les value sets pour les événements envoyés via AEM. Aucun des messages de la page de dépannage de Meta ne porte sur l’ordre des emplacements : ne perdez pas un diagnostic là-dessus.

Combien de temps attendre après un correctif ?

Changez une seule chose, notez la date, puis attendez la fenêtre qui s’applique :

  • Les événements acceptés peuvent mettre jusqu’à 24 heures à s’afficher dans Events Manager (RevenueCat).
  • Un changement de l’intégration choisie peut mettre jusqu’à 24 heures à se refléter, selon la page de Meta Choose a single integration for app events in Meta Events Manager if you send events from multiple integrations.
  • Un événement en attente : revérifiez sous 3 jours (Meta).
  • Après la sélection d’une intégration pour résoudre un message : jusqu’à 7 jours avant de revérifier, et les modifications de campagne peuvent être indisponibles entre-temps (Meta).
  • Après la checklist d’AppsFlyer : de 2 à 3 jours au maximum pour que Meta reflète l’éligibilité (AppsFlyer).

Deux changements dans une même fenêtre vous empêchent de dire lequel a fonctionné.

Quel ordre de mise en place règle généralement le problème ?

Dans mes comptes, cet ordre règle généralement un événement d’essai ou d’achat inéligible, et sur une nouvelle app je le mets en place avant la première campagne d’installation. La page de dépannage de Meta ne liste pas de campagne d’installation parmi ses correctifs : lisez donc la troisième étape comme mon expérience, pas comme une consigne de Meta.

  1. Configurez AEM dans Events Manager avant la première campagne d’installation. J’ouvre l’onglet Settings du dataset, je vais dans Setup tasks for iOS app events et je parcours la section “Meta’s attribution for iOS 14+”, en acceptant les conditions de Meta quand il les demande. Les pages Meta que j’ai vérifiées ne documentent ni interrupteur AEM séparé ni étape de conditions pour les apps : About Meta’s Aggregated Event Measurement dit qu’aucune action n’est nécessaire pour obtenir les mises à jour des campagnes d’app, même si vous devrez peut-être agir pour rendre votre app éligible. Si Events Manager vous montre une invite, acceptez-la ; s’il n’en montre aucune, passez à la suite.
  2. Activez l’attribution probabiliste dans le MMP, ainsi que son réglage AEM. La page de Meta Recommendations for setting up Meta Aggregated Event Measurement with a mobile measurement partner demande d’activer tout interrupteur ou réglage AEM que propose le dashboard de votre MMP, de vérifier si la promotion d’app et le retargeting demandent des réglages séparés, et avertit que restreindre le partage d’IP ou limiter le partage de données pour les utilisateurs qui refusent peut interférer même avec l’interrupteur activé. La page de Meta ne mentionne pas l’attribution probabiliste : l’activer est ma pratique. Le nom des réglages dépend du MMP :
    • AppsFlyer : Advanced Data Sharing dans l’intégration Meta Ads. Le tableau récapitulatif d’AppsFlyer dit qu’il active AEM pour la promotion d’app, y compris les événements des utilisateurs sans advertiser ID et les revendications non déterministes là où ils s’appliquent. L’interrupteur probabiliste se trouve dans App Settings, et la page d’AppsFlyer lui donne deux noms : “Enable view-through attribution via probabilistic modeling” dans le tableau et “Enable view-through attribution via campaign measurement modeling” dans le texte. Il couvre les revendications de view through, et je l’active aussi.
    • Adjust : sa page de setup Meta dit que l’intégration prend en charge automatiquement les campagnes d’installation AEM, et que la modélisation probabiliste est activée par défaut pour tous les liens de campagne d’installation AEM même si vous l’avez désactivée au niveau de l’app. Elle peut encore être modifiée dans les réglages d’attribution d’un lien : vérifiez donc que personne ne l’a désactivée là. Son interrupteur “Enable AEM for MAE” sert aux campagnes de retargeting, pas aux installs.
    • Singular : “Include Advanced AEM Attributions” dans la configuration du partenaire Facebook, coché par défaut. Sa page d’intégration Meta dit que la configuration par défaut envoie déjà les événements des utilisateurs qui n’ont pas accordé la permission ATT.
    • RevenueCat direct : aucun MMP sur le chemin. Le réglage le plus proche est “Send events when ATT consent is not authorized”, traité plus haut, et celui-là est une décision de confidentialité.
  3. Lancez d’abord une campagne d’installation. Je lance une campagne de promotion d’app optimisée sur les installs, et je ne demande à Meta d’optimiser sur les essais ou les achats qu’après. Ma lecture de pourquoi cela fonctionne : la campagne d’installation donne à Meta des installs, et les événements ultérieurs de ces utilisateurs, avant qu’on lui demande d’optimiser sur un événement plus rare. La page de Meta s’en approche sans le dire : l’une des raisons qu’elle donne pour “Integration quality issue” est “We’ve received a low number of install events”, et son correctif est d’envoyer tous les événements de conversion, pas de lancer une campagne d’installation.
  4. Déplacez l’événement d’optimisation une fois qu’il apparaît éligible. Vérifiez la colonne Eligibility, comme décrit plus haut, avant de basculer la campagne sur “maximize number of app events” ou “maximize value of conversions” pour l’essai ou l’achat.

Deux limites. Si More details nomme un champ manquant ou une intégration scindée, ce correctif passe d’abord : une campagne d’installation n’ajoute pas un IDFV manquant, ne démasque pas une IP et ne déplace pas un événement sur l’intégration de l’install, et plus de budget non plus. Si la voie est propre et que l’événement est trop rare, la question devient quel événement une app subscription doit optimiser.

Peut-on envoyer l’IP et l’IDFV des utilisateurs qui ont refusé le tracking ?

C’est votre décision juridique, et rien ici n’est un conseil juridique. La page d’Apple User privacy and data use dit que l’IDFV ne peut pas être combiné à d’autres données pour suivre un utilisateur sur les apps et sites d’autres entreprises, et vous laisse responsable du respect de la loi applicable. AppsFlyer vous demande de confirmer qu’Advanced Data Sharing respecte les politiques de vos plateformes et les réglementations avant de l’activer.

Quelles preuves rassembler avant de passer par le support Meta ?

La page de dépannage de Meta renvoie plusieurs messages à votre account manager Meta, et AppsFlyer demande une capture d’écran des événements inéligibles avec tout ticket. Arrivez avec :

  1. Une capture d’écran datée de la colonne Eligibility et le message More details complet.
  2. L’ID du dataset, l’ID de l’app et chaque nom d’événement exactement tel qu’envoyé, en précisant s’il est standard ou personnalisé.
  3. L’intégration choisie pour l’événement d’install et pour l’événement d’essai ou d’achat, et la liste de toutes les sources qui envoient chacun.
  4. Pour RevenueCat direct : la ligne de livraison d’un client de test récent avec la Request, la Response et le fbtrace_id.
  5. Pour la voie AppsFlyer : un événement serveur à serveur anonymisé montrant l’IP et l’IDFV présents, plus les réglages Advanced Data Sharing, de masquage d’IP et de postbacks.
  6. La part d’autorisation ATT sur les 30 derniers jours.
  7. Un journal de chaque changement avec sa date, et le temps d’attente après chacun.

Qui peut corriger la CAPI et le mapping d’événements pour Meta ?

C’est le travail que je prends en charge dans le signal engineering : tracer chaque événement de l’achat jusqu’à Events Manager, décider quelle intégration en est propriétaire, et corriger ce qui manque à la voie avant que quiconque touche aux enchères ou aux budgets.

Avant la première campagne d’installation d’une app sur Meta, je configure AEM dans Events Manager, j’accepte les conditions de Meta là où il les demande, et j’active l’attribution probabiliste dans le MMP ainsi que tout réglage AEM qu’il propose. Seulement alors la campagne d’installation part, et l’essai ou l’achat devient l’événement d’optimisation une fois qu’Events Manager le marque éligible.

Sources

Chaque page a été ouverte et vérifiée le 29 septembre 2026.

Questions fréquentes

Envoyer un achat depuis RevenueCat le rend-il éligible à Meta AEM ?

Non. La page Meta Ads de RevenueCat indique qu'une livraison réussie signifie que Meta a accepté l'événement, et que Meta peut encore décider que l'événement n'est pas éligible à une campagne, à un objectif d'optimisation ou à un rapport. Réception et éligibilité sont deux contrôles distincts.

Les événements serveur à serveur ont-ils besoin de l'adresse IP et de l'IDFV pour Meta AEM ?

Sur la voie AppsFlyer, oui : AppsFlyer documente que Meta exige les deux dans le payload des événements in app envoyés de serveur à serveur, et que les événements qui en sont dépourvus ne sont pas éligibles à l'attribution Meta dans AEM. L'intégration Meta directe de RevenueCat n'exige ni l'IDFV ni l'IP pour la livraison et les utilise pour le matching quand ils sont présents : l'exigence tient donc à la voie, pas à tous les setups.

Combien de temps Meta met-il à mettre à jour l'éligibilité AEM après un correctif ?

Cela dépend du correctif. AppsFlyer annonce jusqu'à 2 à 3 jours une fois sa checklist terminée. Meta dit qu'un événement en attente doit être revérifié sous 3 jours, et qu'après la sélection d'une intégration la revérification peut prendre jusqu'à 7 jours, avec des modifications de campagne parfois indisponibles entre-temps.

Meta limite-t-il toujours les apps iOS à huit événements AEM ?

La page de Meta sur la configuration des événements d'app pour AEM, qui prévoyait huit emplacements d'événements, renvoie Page Not Found (vérifié le 29 septembre 2026). Les guides qui vous demandent de classer huit événements d'app pour AEM décrivent donc un setup que Meta ne documente plus. Le classement des événements que Meta documente encore relève de la configuration SKAdNetwork, et aucun de ses messages d'éligibilité AEM ne porte sur l'ordre des emplacements.

Une campagne d'installation ou plus de budget rendront-ils mes événements éligibles ?

D'après mon expérience, une campagne d'installation règle généralement le problème, quand elle tourne après deux étapes de mise en place : AEM configuré dans Events Manager, avec les conditions de Meta acceptées là où il les demande, et l'attribution probabiliste activée dans le MMP, ainsi que tout réglage AEM qu'il propose. Je déplace l'optimisation vers l'essai ou l'achat une fois qu'Events Manager le montre éligible. C'est ma pratique, pas une consigne de Meta : sa page de dépannage ne cite ni niveau de dépense ni campagne d'installation parmi ses correctifs. Un budget plus élevé ne suffit pas à ajouter un champ manquant ni à faire passer un événement sur l'intégration de l'install.