Environ 75 pour cent des utilisateurs iOS refusent le suivi des applications en 2026, et pour beaucoup d'annonceurs Meta cette seule invite Apple explique pourquoi les conversions reportées sur le trafic iPhone semblent s'être effondrées du jour au lendemain — alors que les ventes ne se sont jamais arrêtées. L'App Tracking Transparency ne coupe pas vos campagnes ; elle supprime le signal déterministe que Meta utilisait pour relier un achat à un clic, donc des événements bien réels cessent d'être reportés comme avant.
Ce guide remonte le fil depuis le refus à travers sept points de perte de signal — consentement ATT, limite de 8 événements, vérification de domaine, Conversions API, conversions modélisées, fenêtre d'attribution et ventilations supprimées — pour que vous corrigiez la mesure au lieu de courir après une baisse de performance fantôme. Pour contrôler automatiquement votre compte face aux fuites de signal post-ATT les plus courantes, lancez notre audit gratuit de compte publicitaire en 5 axes.
Mis à jour le 2026-05-17 avec le comportement actuel de l'Aggregated Event Measurement, de la Conversions API et des conversions modélisées observé sur des comptes américains, britanniques et européens.
- Environ 75 pour cent des utilisateurs iOS refusent en 2026 — la baisse est dans le reporting, pas dans les ventes réelles. 2. L'Aggregated Event Measurement vous plafonne à 8 événements — seul celui de plus haute priorité qu'un utilisateur complète est compté. 3. La vérification de domaine vient en premier — sans elle vous ne pouvez ni configurer ni classer ces huit emplacements. 4. La Conversions API récupère le signal que le pixel perd au blocage quand on dédoublonne avec un ID d'événement partagé. 5. Les conversions modélisées sont des estimations avec un délai allant jusqu'à 3 jours — jugez les totaux et les tendances, jamais une conversion isolée.
Comment les refus ATT coupent-ils le signal de conversion iOS ?
L'ATT est le premier point de perte de signal à comprendre car toutes les contraintes en aval découlent d'un seul choix utilisateur. Quand un utilisateur iOS touche Demander de ne pas suivre, Meta perd l'identifiant déterministe sur lequel il s'appuyait, et la chaîne du clic à la conversion se rompt à la source.
App Tracking Transparency — L'invite d'Apple demande à chaque utilisateur si une application peut le suivre à travers d'autres applications et sites web. En 2026 la grande majorité refuse, donc pour la plupart du trafic iOS Meta ne peut plus observer la conversion à l'ancienne et doit mesurer dans un cadre respectueux de la vie privée.
Perte déterministe — Sans permission, il n'existe aucun identifiant stable pour relier un achat au clic précis qui l'a déclenché. La vente a toujours lieu, mais le lien que votre tableau de bord affichait n'est tout simplement plus disponible pour cet utilisateur, et c'est pourquoi les chiffres reportés baissent alors que le chiffre d'affaires tient.
Une baisse de reporting, pas de performance — Cette distinction est tout l'enjeu. Avant de mettre en pause des campagnes ou de tailler dans les budgets, prouvez si les ventes ont vraiment chuté ou si elles ont simplement cessé d'être comptées. Notre guide de stratégie post-ATT couvre la réponse structurelle en profondeur.
Qu'est-ce que l'Aggregated Event Measurement et la limite de 8 événements ?
Une fois qu'un utilisateur refuse, Meta ne peut plus reporter cette conversion librement ; il doit la router via l'Aggregated Event Measurement, et ce cadre impose la contrainte qui surprend la plupart des annonceurs — un plafond strict de huit événements par domaine.
Aggregated Event Measurement — C'est le système respectueux de la vie privée de Meta pour mesurer les événements web des utilisateurs iOS refusés. Il agrège les conversions de sorte qu'aucune personne ne puisse être identifiée, ce qui est précisément pourquoi il supprime le détail que vous voyiez avant.
La limite de 8 événements — Chaque domaine vérifié ne peut configurer que 8 événements de conversion. Ils sont classés par priorité, et pour un utilisateur donné, seul l'unique événement de plus haute priorité qu'il complète est compté. Un achat l'emportera sur un ajout au panier, donc l'événement panier n'est pas mesuré si le même utilisateur achète.
Pourquoi l'ordre compte — Si vous placez un événement de faible valeur comme une vue de page dans un emplacement élevé, il peut évincer l'achat qui vous importe vraiment. Configurer les huit emplacements n'est pas du rangement optionnel ; cela décide directement de ce que Meta peut mesurer pour la majorité de votre trafic iOS. La section suivante détaille la configuration exacte dans Events Manager.
Comment vérifier mon domaine et prioriser 8 événements ?
Vous ne pouvez pas toucher à la liste de priorité des huit événements tant que Meta n'a pas confiance dans le fait que le domaine est le vôtre, donc la vérification de domaine est le verrou qui ouvre toute la configuration post-ATT. Faites-la d'abord, puis classez vos événements.
Vérification de domaine — Dans Business Manager, ajoutez l'enregistrement DNS TXT, un fichier HTML ou une balise meta pour prouver la propriété, puis confirmez dans Events Manager. Tant que ce n'est pas au vert, vous ne pouvez ni configurer ni prioriser les événements Aggregated Event Measurement, et Meta peut ne rien mesurer d'utile pour les utilisateurs refusés.
Configurer les 8 événements — Ouvrez Events Manager, sélectionnez le domaine vérifié et choisissez les huit événements de conversion qui comptent. Mappez-les sur votre vrai tunnel : achat, lead, début de paiement, ajout au panier, et ainsi de suite, seulement jusqu'au huitième emplacement.
Prioriser par valeur — Classez l'action de plus grande valeur en premier. Comme seul l'événement le plus haut qu'un utilisateur complète est compté, votre événement monétaire doit être tout en haut et les micro-conversions de faible valeur tout en bas ou hors de la liste. Pour comparer avec la configuration confidentialité de Google, voyez notre comparaison CAPI contre Enhanced Conversions.
La Conversions API peut-elle récupérer le signal perdu ?
La vérification et la priorité des événements décident de ce que Meta a le droit de mesurer ; la Conversions API décide de la quantité qui arrive réellement. C'est le levier de récupération à plus fort effet de la mesure post-ATT.
La Conversions API — Au lieu de dépendre uniquement du pixel navigateur, que l'ATT, les bloqueurs de publicités et l'ITP peuvent dégrader, la Conversions API envoie les événements de serveur à serveur depuis votre backend directement vers Meta. Comme le serveur sait déjà qu'un achat a eu lieu, il peut reporter l'événement même quand le navigateur ne le peut pas.
Correspondance hachée — Le serveur transmet des données client hachées comme l'e-mail et le téléphone pour que Meta puisse apparier l'événement à un utilisateur de façon privée. Une meilleure correspondance signifie plus de conversions récupérées et attribuées, ce qui améliore le score d'event match quality que vous devez surveiller dans Events Manager.
Déduplication — Faites tourner la Conversions API en parallèle du pixel, pas à sa place, et partagez un seul ID d'événement pour qu'un même achat ne soit pas compté deux fois. Bien fait, le flux serveur comble les trous que laisse le pixel plutôt que de gonfler vos chiffres. Pour les options de mise en œuvre, comparez notre guide CAPI Gateway contre GTM côté serveur.
Que sont les conversions modélisées et le délai de reporting ?
Même avec un flux Conversions API propre, certaines conversions refusées ne pourront jamais être observées directement. Plutôt que de reporter zéro, Meta les estime — et ces estimations arrivent avec un délai autour duquel vous devez vous organiser.
Conversions modélisées — Quand Meta ne peut pas observer directement une conversion parce que l'utilisateur a refusé, il utilise des données agrégées et consenties pour estimer statistiquement combien ont probablement converti, puis les reporte comme modélisées. Elles gardent vos chiffres honnêtes en agrégé plutôt que de sous-estimer la performance.
Le délai de reporting — Les événements agrégés sont traités par lots, donc les conversions modélisées et agrégées apparaissent avec un délai pouvant aller jusqu'à environ trois jours. La dépense d'aujourd'hui ne montrera pas son image complète de conversions avant que les données se stabilisent, ce qui est normal sous ce cadre.
Lisez-les comme directionnelles — Les chiffres modélisés sont les plus fiables au niveau du compte et de la campagne et les moins fiables dans les ventilations fines. Jugez les tendances et les totaux, jamais une conversion isolée, et ne réagissez jamais à un jour de données non stabilisées. Pour transformer la valeur de conversion récupérée en chiffre de retour, utilisez notre correctif de divergence pixel et CAPI pour confirmer d'abord que le flux est propre.
Le tableau diagnostic de la mesure Meta post-ATT
Travaillez ce tableau de haut en bas — il est ordonné selon le caractère fondamental de chaque point de perte de signal et la fréquence à laquelle il est la vraie raison pour laquelle vos conversions iOS semblent cassées.
Quand l'ATT coupe vos conversions reportées, mettre en pause les campagnes iOS semble le correctif évident, mais cela tue généralement des ventes réelles qui avaient toujours lieu sans jamais apparaître dans le pixel. Une campagne dont les achats atterrissent dans votre backend mais pas dans votre tableau de bord est un problème de mesure, pas de performance. Récupérez le signal avec la vérification de domaine, la liste de priorité des huit événements et la Conversions API d'abord, puis jugez la campagne sur des totaux modélisés stabilisés — pas sur le chiffre brut du pixel le lendemain de l'invite d'Apple.
Que pouvez-vous et ne pouvez-vous pas mesurer après l'ATT ?
Vous ne retrouverez pas le tableau de bord d'avant l'ATT, et le poursuivre fait perdre du temps. L'objectif est de récupérer autant de signal fiable que le cadre l'autorise, puis de construire le reporting autour de ce qui est réellement mesurable.
Ce que vous pouvez mesurer — Les totaux de conversions agrégés, les tendances au niveau de la campagne, les conversions modélisées et les événements confirmés par le serveur via la Conversions API. Avec la vérification et les huit événements configurés, ils sont assez fiables pour optimiser au niveau du compte et de la campagne.
Ce que vous ne pouvez pas mesurer — Les ventilations fines par âge, sexe, région et placement sont limitées ou disparues pour les utilisateurs iOS refusés, l'attribution fine par utilisateur est indisponible, et la fenêtre d'attribution s'est resserrée à 7 jours après clic et 1 jour après vue avec un délai de traitement d'environ 72 heures sur les événements agrégés.
Construisez le reporting autour des totaux. Réglez les attentes des parties prenantes sur les tendances et les agrégats, pas sur des lignes isolées ni des tranches fines, et acceptez des chiffres légèrement plus anciens comme le prix de la mesure respectueuse de la vie privée. Re-mesurez les conversions appariées et la qualité de correspondance des événements après chaque correctif, pas tous d'un coup, pour savoir quel levier a bougé le résultat. Pour récupérer automatiquement chaque signal récupérable, lancez l'audit gratuit en 5 axes de SteerAds, et dimensionnez le retour sur votre valeur de conversion récupérée avec notre calculateur ROAS.
Sources
Sources officielles consultées pour ce guide :
-
facebook.com — Aggregated Event Measurement
-
facebook.com — vérification de domaine
-
developers.facebook.com — documentation Conversions API
-
facebook.com — Meta Ads
FAQ
Pourquoi mes conversions Meta ont-elles chuté sur iOS après l'ATT ?
L'App Tracking Transparency impose une invite qui permet aux utilisateurs iOS de refuser le suivi au niveau de l'application, et en 2026 environ 75 pour cent d'entre eux refusent. Quand un utilisateur refuse, Meta perd l'identifiant déterministe qui servait à rattacher une conversion au clic, donc des événements bien réels cessent simplement d'être reportés comme avant. La baisse que vous voyez est généralement une baisse de reporting, pas une vraie baisse de performance. Les ventes ont toujours lieu, mais elles arrivent sous forme de chiffres modélisés ou retardés, ou tombent hors de la mesure limitée qu'autorise l'Aggregated Event Measurement. Corrigez la mesure avant de juger une campagne.
Qu'est-ce que l'Aggregated Event Measurement et pourquoi seulement 8 événements ?
L'Aggregated Event Measurement est le cadre respectueux de la vie privée de Meta pour mesurer les événements web des utilisateurs iOS qui n'ont pas accordé le suivi. Pour protéger la vie privée individuelle, les règles d'Apple plafonnent chaque domaine vérifié à huit événements de conversion configurés, classés par priorité. Seul l'événement de plus haute priorité qu'un utilisateur complète est comptabilisé, et un seul de ces huit emplacements se déclenche par session. Voilà pourquoi vous devez choisir et classer vos huit événements délibérément dans Events Manager. Tout ce qui dépasse le huitième emplacement, ou tout événement oublié, reste invisible pour le trafic iOS refusé et n'atteint jamais vos rapports.
La vérification de domaine compte-t-elle pour la mesure Meta ?
Oui, et elle est non négociable pour la configuration post-ATT. Tant que vous n'avez pas vérifié le domaine dans Business Manager, vous ne pouvez pas configurer ni prioriser les huit emplacements d'Aggregated Event Measurement qui décident de ce qui est mesuré pour les utilisateurs iOS refusés. Un domaine non vérifié signifie que Meta choisit les événements à votre place ou ne mesure rien d'utile, et vous perdez le contrôle de la conversion qui occupe l'unique emplacement disponible. La vérification protège aussi vos événements d'être revendiqués par une autre entreprise. Ajoutez l'enregistrement DNS TXT ou la balise meta, confirmez dans Events Manager, puis configurez votre liste de priorité avant de dépenser un euro de plus.
Comment la Conversions API récupère-t-elle le signal perdu ?
La Conversions API envoie les événements de conversion de serveur à serveur, depuis votre backend directement vers Meta, au lieu de dépendre uniquement du pixel navigateur que l'ATT et les bloqueurs peuvent bloquer. Comme le serveur sait déjà qu'un achat a eu lieu, il peut transmettre des données client hachées et l'événement même quand le pixel est bloqué, ce qui récupère le signal perdu par le navigateur. Associez-la au pixel et dédoublonnez avec un ID d'événement partagé pour qu'un même achat ne soit pas compté deux fois. Bien déployée, la Conversions API augmente généralement les conversions appariées et améliore les données qui alimentent l'optimisation de Meta sur le trafic iOS.
Que sont les conversions modélisées dans le reporting Meta Ads ?
Les conversions modélisées sont des estimations statistiques que Meta rapporte pour les conversions qu'il ne peut plus observer directement parce que l'utilisateur a refusé le suivi. Plutôt que d'afficher zéro, Meta utilise des données agrégées et consenties pour estimer combien d'utilisateurs refusés ont probablement converti, puis les attribue dans le reporting. Elles sont étiquetées comme modélisées et apparaissent avec un délai de reporting pouvant aller jusqu'à environ trois jours. Traitez-les comme directionnelles, pas exactes : elles sont meilleures au niveau du compte et de la campagne et les moins fiables pour les ventilations fines. Jugez les tendances et les totaux sur les données modélisées, jamais une conversion isolée.
Pourquoi mes ventilations Meta manquent-elles après l'ATT ?
L'Aggregated Event Measurement supprime délibérément les ventilations détaillées pour protéger la vie privée, donc les répartitions par âge, sexe, région et placement sont limitées ou indisponibles pour les conversions iOS refusées. L'attribution est aussi confinée à une fenêtre plus courte, et la valeur par défaut est passée à un modèle de 7 jours après clic et 1 jour après vue avec un délai de traitement d'environ 72 heures sur les événements agrégés. Vous verrez moins de dimensions et des chiffres légèrement plus anciens qu'avant l'ATT. C'est une contrainte permanente du cadre de confidentialité, pas un bug, alors construisez votre reporting autour des totaux et des tendances plutôt que des tranches fines.
Combien de temps faut-il pour récupérer le signal Meta après l'ATT ?
Les correctifs de base se déploient en un jour ou deux mais ont besoin de données pour faire leurs preuves. La vérification de domaine et la configuration de vos huit événements prennent un après-midi, et la liste de priorité prend effet rapidement. Un déploiement de la Conversions API demande généralement quelques jours d'ingénierie plus une fenêtre de vérification pour confirmer que le score de qualité de correspondance des événements est sain. Ensuite, comptez une à deux semaines pour que les conversions modélisées et l'optimisation se stabilisent sur le signal enrichi. Séquencez le travail pour que la vérification et la priorité des événements arrivent d'abord, puis ajoutez la Conversions API et laissez l'apprentissage se stabiliser.