Tracking des installations iOS : ATT, SKAdNetwork et AdAttributionKit

Ce qui a changé avec iOS 14.5

Avant 2021, chaque iPhone exposait un identifiant publicitaire, l’IDFA, que les régies et les outils d’attribution utilisaient pour relier un clic sur une publicité à une installation puis aux achats dans l’app. Avec iOS 14.5, Apple a rendu cet identifiant conditionnel. D’après la page d’Apple sur la confidentialité et les données utilisateur (Apple Developer, 2026), une app doit obtenir la permission de l’utilisateur via le cadre App Tracking Transparency (ATT) pour le suivre ou accéder à l’identifiant publicitaire. Sans permission, l’identifiant est composé de zéros.

Apple définit le « suivi » de façon large. Il s’agit de relier des données collectées dans votre app à des données collectées par d’autres entreprises, pour cibler ou mesurer la publicité, ou de les partager avec un courtier en données. Placer un SDK publicitaire tiers qui combine vos données avec celles d’autres apps entre dans la définition. Et comme un SDK Meta ou un MMP fait exactement cela, c’est ce point qui a cassé la mesure classique.

Pour quelqu’un qui pilote des campagnes, la conséquence tient en une phrase. Sur une grande partie du trafic iOS, vous lisez désormais des signaux agrégés de campagne plutôt qu’un parcours individuel complet. Ce guide explique comment, sans une ligne de code. Pour le cadre général de l’acquisition, le guide pilier acquisition d’utilisateurs pour application mobile situe la mesure parmi les autres chantiers.

La fenêtre ATT : comment elle marche

La fenêtre ATT est un dialogue système, dont vous ne contrôlez que la phrase d’explication (la clé NSUserTrackingUsageDescription, obligatoire d’après la documentation du cadre App Tracking Transparency (Apple Developer, 2026)). L’utilisateur choisit « Autoriser » ou « Demander à l’app de ne pas suivre ». Le système ne réaffiche pas la fenêtre ensuite ; Apple précise qu’un utilisateur de l’Union européenne peut être resollicité un an après son choix précédent.

Avant de discuter du moment avec vos développeurs, gardez en tête ces règles, toutes issues de la page d’Apple citée plus haut :

• Vous pouvez afficher la fenêtre quand vous voulez ; l’identifiant n’est renvoyé qu’après l’accord.
• Vous ne pouvez ni conditionner une fonction à l’accord ni récompenser l’accord (règle 5.1.2(i) des App Review Guidelines).
• L’écran d’explication que vous affichez avant la fenêtre système est autorisé, tant qu’il ne trompe pas et ne pousse pas à cliquer.

Quand l’afficher

Le moment change le taux d’acceptation, et donc la part de vos installations que vous verrez individuellement. Voici les options que je compare. Je ne donne pas de chiffres universels, les vôtres se lisent dans le MMP.

Mon point de départ, c’est un écran d’explication court suivi de la fenêtre système, le tout placé après la première action réussie mais dans la première session. Le bon moment dépend ensuite de votre onboarding. Testez au moins deux moments et comparez le taux d’accord dans votre MMP plutôt que d’appliquer une règle universelle.

Les taux d’acceptation

Les tableaux de bord des MMP publient des taux d’accord par catégorie et par région, et la donnée bouge d’un trimestre à l’autre. Retenez le principe plutôt qu’un chiffre. Une part importante des utilisateurs iOS refuse, et vos rapports individuels ne représentent qu’une fraction de vos installations. Tout ce qui suit sert à mesurer le reste.

SKAdNetwork 4 en langage clair

SKAdNetwork (SKAN) est le mécanisme d’Apple pour attribuer une installation à une publicité sans identifiant. D’après la documentation SKAdNetwork d’Apple (Apple Developer, 2026), trois acteurs participent. La régie signe les publicités et reçoit des postbacks, l’app source affiche la pub, et l’app annoncée met à jour des « valeurs de conversion » quand l’utilisateur agit. Apple signe le postback et garantit qu’il ne contient aucune donnée d’utilisateur ou d’appareil. La régie gagnante reçoit un postback marqué gagnant ; jusqu’à cinq autres régies reçoivent un postback perdant.

Depuis iOS 16.1, la version 4 envoie jusqu’à trois postbacks, un par fenêtre de conversion. Les délais et les fenêtres ci-dessous viennent de la page d’Apple sur les postbacks en plusieurs fenêtres (Apple Developer, 2026).

Les notions à traduire pour votre équipe, sans jargon :

• Valeur de conversion. Un nombre (0 à 63) que votre app ou votre MMP met à jour selon ce que fait l’utilisateur : inscription, essai, achat. Vous décidez du schéma, la régie le lit. Un mauvais schéma rend le reste inutile.
• Anonymat de groupe (crowd anonymity). Apple attribue à chaque installation un niveau de 0 à 3 selon le volume de la campagne, de l’app source, du pays. Au niveau 0, vous ne recevez que le premier postback et un identifiant de source à deux chiffres. Une petite campagne renvoie donc des données pauvres, et c’est voulu par Apple.
• Identifiant de source hiérarchique. Deux à quatre chiffres portés par la régie pour distinguer campagnes, groupes d’annonces et créas. Le nombre de chiffres renvoyés dépend du niveau d’anonymat.
• Verrouillage de fenêtre. L’app peut figer la valeur de conversion avant la fin de la fenêtre pour recevoir le postback plus tôt. Utile si votre événement clé arrive vite.

Pour un marketeur, retenez surtout ceci. La donnée SKAN arrive en retard, donc ne jugez pas une campagne iOS le lendemain. Elle est aussi bruitée sur les petits budgets, ce qui plaide pour regrouper plutôt que fragmenter.

AdAttributionKit

AdAttributionKit est le successeur de SKAdNetwork. D’après sa documentation Apple (Apple Developer, 2026), il est disponible depuis iOS 17.4, couvre l’App Store et les boutiques alternatives, conserve trois fenêtres de conversion et envoie les postbacks à la régie et, sur option, au développeur de l’app. Il ajoute le réengagement : une pub peut être créditée d’une conversion chez un utilisateur qui avait déjà l’app. Apple indique sur la page SKAdNetwork qu’il faut désormais utiliser AdAttributionKit pour les campagnes d’apps.

Les deux cadres coexistent, et d’après le glossaire AdAttributionKit d’AppsFlyer (AppsFlyer, 2026), c’est l’impression la plus récente qui l’emporte quand les deux sont en jeu, avec 64 valeurs de conversion comme sur SKAN. Concrètement, vous n’avez rien à faire tant que votre MMP ou le SDK de la régie est à jour. Retenez simplement que les rapports gardent la même logique de fenêtres et de délais.

Ce que voient les régies

Meta : AEM et campagnes SKAN

Meta mesure les campagnes d’apps iOS avec deux sources. La première, ce sont les postbacks Apple, restitués dans le Gestionnaire de publicités sous des colonnes dédiées aux installations et aux événements SKAdNetwork, avec les délais vus plus haut. La seconde, c’est l’Aggregated Event Measurement (AEM) pour apps : d’après la documentation développeur de Meta (Meta for Developers, 2026), AEM mesure des événements dans l’app chez les utilisateurs iOS 14.5 ou plus qui ont refusé le suivi, via le SDK Meta et le support des Universal Links pour les liens profonds.

Dans le Gestionnaire de publicités, une campagne iOS avec objectif Promotion de l’application demande l’app enregistrée et active la mesure SKAdNetwork ; Meta limite le nombre de campagnes SKAN par app et d’ensembles de publicités par campagne. Ces plafonds ont évolué depuis 2021, vérifiez-les dans l’aide Meta avant de structurer le compte. Le schéma de valeurs de conversion se règle dans le Gestionnaire d’événements ou via le MMP. Le détail du paramétrage est dans le guide Meta Ads pour application mobile.

Google : les conversions modélisées

Google traite la perte de visibilité par la modélisation. D’après sa page d’aide sur les conversions modélisées (Google Ads, 2026), Google utilise des données qui n’identifient pas les individus pour estimer les conversions qu’il ne peut pas observer directement, cite explicitement l’ATT parmi les causes, et a étendu les conversions modélisées à toutes les App Campaigns : vos colonnes installations, actions dans l’app et valeur de conversion peuvent contenir des conversions modélisées. Google précise qu’elles mettent jusqu’à cinq jours à se stabiliser.

En pratique, une campagne iOS Google App Campaigns rapporte des installations plus vite et plus lissées que SKAN, mais vous ne pouvez pas distinguer l’observé du modélisé ligne par ligne. Comparez toujours le total Google au total SKAN de votre MMP avant de décider d’un budget. J’explique le réglage des enchères tCPI et tCPA dans le guide Google App Campaigns.

Apple Ads : un cas à part

L’attribution d’Apple Ads ne passe ni par l’IDFA ni par SKAdNetwork. D’après la documentation du cadre AdServices (Apple Developer, 2026), disponible depuis iOS 14.3, l’app demande un jeton, valable 24 heures, que le serveur (le vôtre ou celui du MMP) échange contre un enregistrement d’attribution contenant la campagne, le groupe d’annonces, le mot-clé, l’annonce, le pays et la date du clic. Le téléchargement est attribué si l’utilisateur a tapé sur une annonce dans les 30 jours ou l’a vue dans les 24 heures. Cette documentation ne mentionne pas l’ATT, et au moment où j’écris, le niveau de détail de l’enregistrement ne semble pas dépendre du consentement.

C’est pour cela qu’Apple Ads reste le canal iOS le plus lisible. Vous savez quel mot-clé a produit quelle installation, sans attendre 48 heures. Le guide Apple Ads explique comment en tirer parti, y compris la contrainte française sur les comptes annonceur.

Faut-il un MMP, et lequel

Un MMP (mobile measurement partner) est le SDK qui reçoit les postbacks Apple, collecte les événements de l’app, dédoublonne les installations entre régies et présente le tout dans un seul rapport. Sans MMP, chaque régie se crédite des mêmes installations et vous additionnez des chiffres qui se recouvrent.

Dès que vous devez comparer plusieurs régies et dédoublonner l’attribution, un MMP devient beaucoup plus utile. Un repère simple : deux régies payantes en même temps sur iOS. Le prix des MMP change souvent et se négocie, je ne l’affiche donc pas ici. J’ai travaillé avec AppsFlyer et Adjust sur des campagnes Android à grande échelle comme sur iOS avec ATT et SKAdNetwork, à peu près moitié-moitié sur ma carrière. Le choix entre les deux se fait surtout sur l’outil que l’équipe technique connaît déjà et sur les régies à couvrir. Le choix pèse ensuite sur le calcul de rentabilité, que je détaille dans le guide sur la rentabilité de la publicité pour application mobile.

Ce que je vérifie sur un compte iOS

• Les chiffres Meta, SKAN et MMP divergent, parce qu’ils ne reposent pas sur la même méthode. Sur un même mois, Meta remonte souvent plus d’installations iOS que le MMP n’en compte via SKAN, et l’écart se creuse sur les petites campagnes où les postbacks arrivent avec des valeurs de conversion vides. Je lis les colonnes côte à côte avant de décider d’un budget.
• Sur une petite campagne, une bonne partie des postbacks peut tomber au niveau d’anonymat le plus bas. Le nombre d’installations est là, la valeur de conversion ne l’est pas, ce qui interdit d’optimiser sur un événement dans l’app tant que le volume ne monte pas.
• Si vous ajoutez un écran d’explication avant la fenêtre ATT, faites-lui dire ce que l’app fait des données, pas seulement qu’elle en a besoin. Mesurez ensuite l’effet sur le taux d’accord dans le MMP.
• Un schéma de valeurs de conversion mal conçu fait optimiser une campagne sur le mauvais événement. Exemple typique, un schéma qui déclenche la valeur sur l’ouverture du paywall plutôt que sur l’essai démarré. La régie apprend à trouver des curieux, et le ROAS suit.

Je résume le problème de visibilité iOS dans le Short en tête de cette page, et je montre dans ce Short comment mesurer les téléchargements issus d’un panneau publicitaire, un cas où aucun postback n’existe et où seule la méthode de comparaison de périodes fonctionne.

À faire cette semaine

1. Vérifier la phrase de la fenêtre ATT dans l’app et son moment d’affichage. Si elle apparaît à froid au premier lancement, planifier un test avec un écran d’explication.
2. Lire le taux d’accord ATT dans le MMP ou dans le SDK de la régie, par version d’app et par pays.
3. Ouvrir le schéma de valeurs de conversion et vérifier qu’il code l’événement qui compte pour vous (essai, abonnement, première commande), et pas seulement l’installation.
4. Comparer, sur le mois dernier, les installations iOS selon Meta, selon Google et selon le MMP. Les écarts entre les trois donnent votre marge d’erreur.
5. Vérifier la version du SDK du MMP ou de la régie, qui doit supporter SKAdNetwork 4 et AdAttributionKit.
6. Regrouper les campagnes iOS trop fragmentées. Une campagne avec un budget minuscule risque de rester au niveau d’anonymat 0 et de ne renvoyer qu’un postback pauvre.
7. Décaler vos revues de performance iOS d’au moins trois jours après la fin de la période, le temps que les premiers postbacks arrivent.

Les erreurs fréquentes

• Juger une campagne iOS le lendemain. Le premier postback arrive 24 à 48 heures après la fin d’une fenêtre de deux jours. Le tableau du lendemain est vide ou faux.
• Additionner les installations de Meta et de Google. Sans MMP, les deux régies se créditent parfois la même installation, et le total dépasse la réalité.
• Laisser le schéma de conversion par défaut. Une valeur qui ne code que l’installation pousse les régies à chercher du volume plutôt que des abonnés.
• Multiplier les petites campagnes iOS. Chaque campagne isolée tombe dans les niveaux d’anonymat bas. Moins de campagnes, plus de données.
• Comparer un CPI iOS aux CPI Android sans tenir compte des installations non attribuées. Le guide sur le coût par installation, lié en bas de page, explique comment lire les deux.
• Croire que l’ATT n’a pas d’effet sur le retargeting. Sans accord, pas d’audience d’identifiants. Le retargeting iOS repose sur les utilisateurs ayant accepté et sur vos propres canaux (push, e-mail).
• Confondre modélisé et mesuré. Les chiffres de Google et de Meta incluent des estimations, ce qui reste utile pour piloter mais devient dangereux quand vous facturez un partenaire à la performance.

Quand ne pas s’en occuper

Si votre app est uniquement sur Android, ce guide ne vous concerne pas encore, même si la logique de la Privacy Sandbox suit une direction voisine. Si vous ne dépensez rien en publicité et que vous voulez seulement compter vos installations, App Store Connect suffit, puisque les sources d’acquisition y sont visibles sans SDK. Et si votre budget iOS est très faible, ne payez pas un MMP pour le mesurer. Le SDK de la régie unique et la comparaison de périodes suffiront jusqu’à ce que le budget justifie l’outil. Quand ce moment arrive, la page service acquisition payante décrit comment je mets en place la mesure avant de lancer les campagnes. Et si vous ne savez pas si vos chiffres iOS sont lisibles, envoyez-moi votre app et votre setup de mesure via la page contact.