Le déploiement de l’App Tracking Transparency (ATT) d’Apple en avril 2021 a changé la façon dont Meta mesure les performances publicitaires. L’impact est devenu la base de toute mesure Meta. Cette note couvre ce qui a changé, comment le cadre de mesure de Meta s’est adapté, et les implications pour la conception du pipeline warehouse et l’interprétation des données.
Ce qu’ATT a changé
Avant ATT, Meta (et tous les autres annonceurs) pouvaient utiliser l’IDFA (Identifier for Advertisers) pour tracker les utilisateurs iPhone entre les applications et les sites web. Lorsque quelqu’un cliquait sur une annonce Meta et effectuait ensuite un achat dans une application, Meta savait — précisément, de manière déterministe — que le clic avait conduit à l’achat.
ATT exigeait que les applications demandent aux utilisateurs une autorisation explicite pour les tracker. Le taux d’opt-in s’est stabilisé autour de 30 à 40 % mondialement, ce qui signifie que la disponibilité de l’IDFA est tombée à environ 6 % de la population iOS (en tenant compte de la fraction qui s’inscrit activement par rapport à l’état désactivé par défaut). La plupart des utilisateurs iPhone sont devenus effectivement invisibles pour le tracking cross-application.
Les conséquences directes pour la mesure Meta :
Les fenêtres d’attribution se sont réduites. Les fenêtres d’attribution par défaut de Meta sont passées de 28 jours au clic + 1 jour à la vue à 7 jours au clic + 1 jour à la vue. Les fenêtres plus longues nécessitaient le type de tracking déterministe cross-session qu’ATT a rendu impossible à grande échelle. Une fenêtre de clic de 28 jours sur des données estimées est trop bruitée pour être significative.
Les conversions sont devenues estimées. Meta rapporte de plus en plus des conversions « estimées » basées sur la modélisation statistique plutôt que sur la correspondance déterministe d’événements. Lorsque Meta ne peut pas observer le parcours de conversion complet, il utilise des patterns agrégés d’utilisateurs similaires qui ont effectivement opté pour modéliser ce qui s’est probablement passé pour les utilisateurs qui ne l’ont pas fait. Ces chiffres modélisés se mettent à jour à mesure que davantage de signal arrive, ce qui est l’une des raisons pour lesquelles les données d’attribution continuent de changer pendant des jours après les faits.
La portée est devenue moins précise. La métrique reach est passée de « nous avons tracké ces utilisateurs spécifiques » à « nous estimons que ce nombre d’utilisateurs uniques ont vu votre annonce ». Le changement était méthodologique, pas seulement sémantique — la portée estimée se comporte différemment sous agrégation que la portée déterministe d’autrefois.
Aggregated Event Measurement
La réponse de Meta a été l’Aggregated Event Measurement (AEM), un cadre pour mesurer les conversions sur les sites web depuis les utilisateurs iOS en utilisant une agrégation respectueuse de la vie privée. Les caractéristiques clés :
- Les conversions sont mesurées de manière agrégée, pas au niveau individuel
- Les données sont retardées jusqu’à 72 heures avant d’apparaître dans l’API (c’est délibéré — c’est une partie de l’architecture de confidentialité)
- Historiquement, il y avait une limite de 8 événements par domaine (8 événements de conversion prioritaires). Cette limite a été supprimée en juin 2025 — la configuration est désormais automatique
- Les conversions AEM mettent toujours jusqu’à 72 heures à apparaître dans l’Insights API, même après la simplification de juin 2025
Pour la conception du pipeline, le délai de 72 heures sur les conversions AEM est la contrainte critique. Toute fenêtre de lookback inférieure à 3 jours manquera entièrement les conversions AEM. Le lookback de 28 jours recommandé pour les pipelines Meta couvre le délai AEM avec une marge considérable.
La Conversions API comme réponse
La principale réponse industrielle à la perte de signal est la Conversions API (CAPI) : envoyer des événements de conversion directement depuis votre serveur vers Meta, en contournant entièrement le tracking côté navigateur. Les événements CAPI ne sont pas affectés par les bloqueurs de publicité, les restrictions des navigateurs ou les changements de confidentialité iOS parce qu’ils proviennent de votre serveur, pas de l’appareil de l’utilisateur.
L’impact rapporté est réel. Les équipes implémentant CAPI voient systématiquement 15 à 25 % de conversions attribuées en plus dans le premier trimestre d’implémentation par rapport à la mesure pixel uniquement. Le lift provient d’événements qui étaient précédemment perdus en raison des restrictions du navigateur et qui atteignent maintenant Meta.
Mais CAPI introduit sa propre complexité : la déduplication. Si vous envoyez des événements à la fois via le Pixel (côté navigateur) et CAPI (côté serveur), Meta reçoit la même conversion de deux sources. Sans déduplication, les deux sont comptés séparément, gonflant vos chiffres de conversion.
La déduplication nécessite la correspondance des valeurs event_id entre les deux signaux :
// Appel Pixel côté navigateurfbq('track', 'Purchase', { value: 49.99, currency: 'USD'}, { eventID: 'order-123-abc' // doit correspondre à l'appel CAPI});# Appel CAPI côté serveurevent = { 'event_name': 'Purchase', 'event_time': int(time.time()), 'event_id': 'order-123-abc', # doit correspondre à l'appel Pixel 'user_data': {...}, 'custom_data': {'value': 49.99, 'currency': 'USD'}}Meta associe les événements avec le même event_id dans une fenêtre de 48 heures et les déduplique. Lorsque cela fonctionne correctement, Events Manager affiche « 1 événement de 2 sources » plutôt que deux conversions séparées. Voir Meta CAPI Server-Side Setup: Deduplication and Event Match Quality pour les détails complets d’implémentation.
Pour les pipelines warehouse, la déduplication affecte les chiffres auxquels vous faites confiance. Si votre Pixel et votre CAPI envoient des événements correspondants avec une correspondance event_id correcte, l’API de Meta retourne des décomptes de conversions dédupliqués. Si la déduplication n’est pas configurée, vous verrez des conversions gonflées dans les données brutes de l’API. Valider cela en vérifiant si le total des conversions a diminué après l’implémentation de CAPI + déduplication — une baisse est correcte et attendue.
Ce que cela signifie pour vos chiffres warehouse
Plusieurs implications pour la conception du pipeline et l’interprétation des données :
Les chiffres modélisés sont normaux. Les données de conversion Meta post-ATT sont un mélange de déterministe (utilisateurs qui ont opté) et de modélisé (utilisateurs qui ne l’ont pas fait). Les deux sont inclus dans les chiffres que Meta rapporte. Il s’agit d’un comportement documenté, pas d’un bug. L’accepter et le documenter.
Les données récentes sont provisoires. Les conversions modélisées se mettent à jour à mesure que davantage de signal arrive. Le décompte des achats d’hier sera différent demain. Cela s’ajoute à l’exigence de fenêtre de lookback — vous n’attendez pas seulement les événements en retard, vous attendez que les modèles se stabilisent.
La portée ne peut pas être additionnée. La portée estimée pour un segment d’audience ne peut pas être additionnée entre les jours ou les ventilations sans double comptage. Si vous demandez des données de portée quotidiennes et les additionnez, vous obtiendrez un chiffre supérieur aux viewers uniques réels parce que la même personne peut être estimée atteinte plusieurs jours. Stocker les métriques de portée avec soin et ne jamais les additionner dans des agrégations.
Les benchmarks de taux de conversion ont changé. Tout benchmark pour les taux de conversion ou le ROAS Meta antérieur à avril 2021 utilise une méthodologie différente. Les comparaisons historiques qui traversent le déploiement ATT doivent tenir compte du changement de méthodologie de mesure, pas seulement des changements de performance de campagne.
La perte de signal crée un biais systématique. Les utilisateurs qui ont refusé le tracking sont davantage des personnes soucieuses de leur vie privée, souvent à revenus plus élevés. Cela signifie que les données modélisées de Meta peuvent sous-représenter systématiquement certains segments d’utilisateurs. Pour les annonceurs ciblant ces segments, le sous-comptage peut être plus prononcé que le chiffre moyen de 6 % de disponibilité IDFA ne le suggère.
L’état des choses en 2026
L’impact d’ATT a atteint un plateau mais ne s’est pas inversé. Apple n’a montré aucun signe d’assouplissement des exigences ATT. La modélisation statistique de Meta s’est améliorée — les conversions estimées sont plus précises qu’en 2021 — mais le tracking déterministe cross-application à grande échelle a définitivement disparu.
La réponse pratique pour 2026 :
- Implémenter CAPI si ce n’est pas encore fait — la récupération de 15 à 25 % des conversions est réelle
- Définir des fenêtres de lookback de 28 jours dans votre pipeline d’extraction pour capturer les délais AEM
- Spécifier les fenêtres d’attribution explicitement dans les appels API et documenter quelles fenêtres vous utilisez
- Accepter et documenter la variance entre le warehouse et Ads Manager, notamment pour les audiences à forte proportion iOS
- Utiliser la Valeur des Conversions (revenu) comme signal principal de ROAS plutôt que les décomptes de conversions — le revenu est moins affecté par l’incertitude de modélisation que les décomptes d’événements
L’ère de l’attribution Meta pixel-perfect est terminée. Les pipelines qui fonctionnent bien dans cet environnement sont ceux conçus autour de la nouvelle réalité plutôt qu’essayant de recréer l’ancienne.