Google Ads, votre MMP et SKAN ne rapporteront pas les mêmes conversions iOS, parce qu’ils comptent des choses différentes, les rattachent à des moments différents et voient des utilisateurs différents. N’en utilisez aucun comme le seul vrai chiffre. Utilisez Google Ads pour le retour sur les enchères, le MMP pour répartir le budget entre les canaux, et votre source de revenu pour la finance, et regardez si l’écart entre eux bouge. La condition qui change la réponse est la région : pour les utilisateurs iOS de l’EEE, du Royaume-Uni et de la Suisse, il n’y a aucune revendication ICM dans le MMP, donc la vue du MMP sur Google y est plus mince et SKAN pèse davantage.
Périmètre : les Google App campaigns pour les installs sur iOS, mesurées via un partenaire d’attribution (je m’appuie sur la documentation d’AppsFlyer pour le côté MMP, et les autres MMP ont leurs propres règles), toutes régions, avec l’exception régionale ci-dessus. Chaque fait de plateforme ci-dessous a été vérifié sur la page source le 29 septembre 2026. Pour le côté Meta du même problème, lisez Meta contre RevenueCat contre Adjust. Pour la configuration qui produit des revendications ICM au départ, lisez le guide de configuration d’ICM et de la mesure on device.
Où vit chaque chiffre iOS, et que compte-t-il ?
Google publie sa propre comparaison côte à côte dans Understanding iOS App campaign measurement and reporting. Lisez le tableau qui s’y trouve. En résumé :
- Les conversions modélisées de Google Ads figurent dans les tableaux Campaigns et Ad groups. Elles incluent les conversions click through et engaged view, pas les view through. Google dit qu’elles peuvent être retardées jusqu’à cinq jours, et qu’elles couvrent tous les utilisateurs, y compris ceux de l’EEE, du Royaume-Uni et de la Suisse.
- Les revendications ICM dans votre MMP sont les revendications d’installs de Google envoyées à votre partenaire d’attribution et affichées dans son interface. La page de Google indique que ces données ne sont pas disponibles aujourd’hui dans le reporting Google Ads, et ajoute que la mesure iOS dans Google Ads changera à l’avenir pour se rapprocher d’ICM pour les apps disposant d’ICM et de données d’événements de mesure on device, sans date. About Integrated Conversion Measurement for App Campaigns le décrit comme un reporting au niveau événement et liste la mesure de conversion on device utilisant les données d’événements comme prérequis iOS.
- Les postbacks SKAdNetwork arrivent dans vos rapports MMP ou BI. Dans Google Ads, seuls les installs SKAdNetwork apparaissent, dans un rapport SKAdNetwork dédié. SKAN est le seul des trois qui inclut les conversions view through, et Google recommande de le consulter tous les 30 jours à cause des délais variables.
Dans AppsFlyer, la page Google Ads (AdWords) Integration setup for advertisers indique que les revendications Google déterministes affichent un match_type égal à srn dans les données brutes, et que les revendications ICM affichent “probabilistic”. Cette seule colonne vous permet de séparer les installs Google du MMP en deux types avant de comparer quoi que ce soit.
Pourquoi les chiffres diffèrent-ils même quand tout est bien configuré ?
Parce que les différences sont structurelles. La page Google Ads (AdWords) FAQ and discrepancies d’AppsFlyer liste les causes, et la plupart sont des définitions, pas des erreurs.
Chaque côté ne montre que son propre modèle. AppsFlyer dit que Google Ads affiche les installs issus de la modélisation interne de Google et n’affiche pas les installs ICM, tandis qu’AppsFlyer affiche les revendications ICM et n’affiche pas les installs modélisés en interne par Google. Deux modèles, deux sorties, aucun total commun.
Heure du clic contre heure du lancement. Google Ads enregistre l’install à l’heure du clic. AppsFlyer l’enregistre à l’heure du lancement. La page Understand your conversion tracking data de Google confirme que les colonnes de conversions principales reposent sur l’heure du clic, et propose une colonne “Conversions (by conv. time)” quand vous avez besoin de la date de conversion à la place. Les événements in app suivent la même séparation : Google les rattache à l’heure du clic, et le dashboard AppsFlyer les rattache à l’heure de l’install.
Dernier clic contre chaque engagement. AppsFlyer attribue au dernier clic et traite les engagements antérieurs comme des assists. Google, en tant que réseau qui déclare ses propres résultats, attribue tous les installs qui suivent un engagement avec ses annonces, dans sa propre fenêtre.
Fenêtres. Pour les conversions modélisées, la comparaison de Google liste une fenêtre click through configurable avec 30 jours par défaut et une fenêtre engaged view configurable avec 2 jours par défaut. Pour ICM, elle liste une fenêtre configurable dans l’interface du partenaire d’attribution, de 6 heures à 30 jours, mais cite AppsFlyer comme une exception sans préciser en quoi AppsFlyer diffère. La page de configuration d’AppsFlyer a son propre réglage de fenêtre de lookback pour les clics d’install et recommande 30 jours pour s’aligner sur Google Ads. Pour SKAN, Google liste une fenêtre click through configurable de 30 jours, une fenêtre engaged view de 30 jours que vous ne pouvez pas modifier et une fenêtre view through configurable de 1 jour.
Règles view through. AppsFlyer note que Google Ads place les conversions view through dans la colonne All conversions, pas dans Conversions, sauf si vous le réglez autrement. La comparaison de Google indique qu’ICM inclut les conversions click through et engaged view mais pas les view through, et la page de configuration d’AppsFlyer dit que Google ne revendique actuellement que les clics sur iOS, pas les impressions.
Le délai de la modélisation. Jusqu’à cinq jours pour les conversions modélisées de Google Ads. Les derniers jours de tout rapport Google Ads ne sont pas terminés.
Couverture de l’EEE, du Royaume-Uni et de la Suisse. La page About on-device conversion measurement for iOS App campaigns de Google indique que la mesure on device utilisant les données d’événements est inactive pour les utilisateurs de ces régions, et Bulletin: AppsFlyer and Google attribution solution (Open BETA) d’AppsFlyer indique qu’ICM n’est pas disponible pour le trafic iOS de ces régions. Les conversions modélisées et SKAN les couvrent toujours. Attendez-vous donc à ce que l’écart entre Google Ads et le MMP dépende de la part de votre trafic iOS Google qui vient de ces trois régions.
Retéléchargements. Google Ads applique ce que vous avez configuré comme retéléchargement par opposition à nouvelle install, tandis qu’ICM utilise une définition fixe, selon la comparaison de Google. AppsFlyer ajoute que Google Ads affiche les réinstallations comme une conversion session_start, tandis qu’AppsFlyer les place dans ses données de retargeting.
Périmètre du coût. La page d’AppsFlyer sur les écarts indique qu’il reçoit le coût Google de tous les canaux d’une campagne mais n’attribue que les conversions de YouTube et Display dans les App campaigns iOS, si bien que le CPI paraît plus élevé dans AppsFlyer. Sa page de configuration, modifiée plus tard, indique que toute App campaign iOS pour les installs peut être attribuée via ICM. Les deux pages se lisent différemment, donc vérifiez vos propres données brutes pour repérer des installs Google probabilistes avant de décider quelle description correspond à votre compte.
Déduplication SKAN. La même page sur les écarts indique qu’AppsFlyer n’affiche que les postbacks avec did_win=TRUE, alors que le dashboard Google Ads ne les sépare pas de ceux avec did_win=NULL, si bien que le nombre d’installs SKAN du MMP peut être plus bas.
Comment réconcilier Google Ads, le MMP et SKAN ?
Avec une feuille de travail, une ligne par champ, remplie pour les trois sources avant de regarder les totaux. L’objectif est de nommer chaque raison connue de l’écart, pour que ce qui reste soit assez petit pour être investigué.
| Champ | Google Ads modélisé | MMP (revendications ICM et srn) | SKAN |
|---|---|---|---|
| Source de reporting | Tableaux Campaigns et Ad groups | Le dashboard ou les données brutes de votre partenaire d’attribution, séparés par match_type | Rapports MMP ou BI ; le rapport SKAdNetwork dans Google Ads |
| Définition de l’événement | L’action de conversion importée sur laquelle vous filtrez, par exemple first_open uniquement | Le nom de l’événement d’install ou in app dans le MMP | L’événement ou les événements que votre schéma de conversion value associe |
| Fenêtre d’attribution | Fenêtres click through et engaged view configurées | Le réglage de fenêtre de lookback du MMP, et comment il s’applique aux revendications ICM | Les fenêtres d’Apple plus les fenêtres SKAN de Google |
| Base de date de cohorte ou d’événement | Date du clic, ou “by conv. time” si vous changez de colonnes | Date de lancement pour les installs ; date d’install pour les événements dans le dashboard, date de l’événement dans les données brutes | Date d’install estimée |
| Fuseau horaire | Le fuseau que le rapport Google Ads utilise | Le fuseau que l’app MMP utilise | Le fuseau que votre rapport SKAN utilise |
| Âge de la cohorte | Au moins cinq jours après le dernier clic, plus la fenêtre | Après la fenêtre de lookback du MMP | Après le dernier postback dont vous dépendez |
| Réinstallations | Vos réglages de retéléchargement ; réinstallations comme session_start | Réattributions dans les données de retargeting | La comparaison de Google ne donne aucune règle ; notez comment votre MMP les traite |
| Base du revenu | Valeur attachée à l’action de conversion importée, et d’où elle vient | Revenu envoyé par le SDK ou le serveur, brut ou net, avec ou sans remboursements | Revenu induit par le schéma de conversion value |
| Écart résiduel inexpliqué | À laisser vide tant que chaque ligne ci-dessus ne correspond pas |
Quelques cellules demandent une source. La date SKAN est une estimation : la page SKAN Conversion Studio d’AppsFlyer déduit l’heure d’install de l’heure d’arrivée du postback moins une plage moyenne de dernière activité et un délai fixe de postback iOS. La même page indique que SKAN 4 envoie trois postbacks, après les fenêtres qui se terminent aux jours 2, 7 et 35. La page AdAttributionKit d’Apple Receiving postbacks in multiple conversion windows donne les trois mêmes fenêtres, jours 0 à 2, 3 à 7 et 8 à 35 depuis le premier lancement, avec des postbacks envoyés après un délai aléatoire de 24 à 48 heures pour le premier et de 24 à 144 heures pour les autres, et seul le premier postback peut porter une fine value. Pour le revenu, la page Set up your SKAdNetwork conversion value schema de Google indique que sa modélisation des conversions n’utilise que les fine conversion values et ne prend pas actuellement en charge les coarse conversion values de SKAN 4, donc une valeur qui n’atteint SKAN que sous forme de coarse value, comme dans les deuxième et troisième postbacks, n’alimente pas la modélisation de Google. AppsFlyer avertit aussi que les données Google Ads importées depuis Firebase sont structurées différemment et ne sont pas entièrement comparables aux données AppsFlyer, donc écrivez la source d’import dans la ligne du revenu.
À quoi ressemble un écart qui n’est pas normal ?
En voici un tiré de mon propre travail. En février et mars 2026, j’ai piloté des Google App campaigns pour une app subscription sur Android et iOS, avec AppsFlyer comme MMP et ICM activé pour iOS. C’est le même compte que mon test de stratégie d’enchères. Sur 39 jours et 88 920 $, Google Ads a rapporté 37,7 % de ROAS sur l’ensemble des campagnes. AppsFlyer affichait 29,8 % de ROAS lifetime et 17,0 % à D0.
La première leçon tient à la ligne sur la base du revenu dans la feuille de travail. Comparé au chiffre D0 d’AppsFlyer, Google paraissait trop élevé de 21 points. Comparé au ROAS lifetime d’AppsFlyer, l’écart était de 8 points. Mêmes campagnes, même dépense, et la taille de l’“écart” dépendait de la colonne AppsFlyer que nous choisissions. La plupart des campagnes prises une à une étaient à environ 10 points d’AppsFlyer, dans les deux sens, ce que les raisons ci-dessus expliquent.
La seconde leçon est ce que signifie généralement un écart très éloigné de cette plage. La campagne iOS en Max Conversion Value a dépensé 11 312 $ et affichait 71,4 % de ROAS dans Google Ads contre 17,3 % de ROAS lifetime dans AppsFlyer, soit 54 points d’écart. Les raisons documentées étaient les premières suspectes : conversions modélisées, view through, fenêtres différentes. La cause était plus simple. L’événement de revenu de l’app, AllRevenue, passait une valeur de 1 $ à Google quand il n’y avait pas de conversion value, au lieu de 0 $. Cela a gonflé le ROAS de Google partout, et sur iOS, où les volumes de conversion étaient plus faibles, cela a écrasé les vrais chiffres. Aucune ligne de la feuille de travail ne l’aurait expliqué, parce que rien n’y relevait d’une définition. C’était une mauvaise valeur.
Quelle est la procédure, étape par étape ?
Quand j’audite cela, je vérifie d’abord ce que chaque événement envoie, puis la base de date et le filtre d’événement, parce que chacun est rapide à confirmer et que n’importe lequel peut à lui seul faire bouger une comparaison.
- Vérifiez les valeurs avant les modèles. Regardez la valeur que chaque événement de revenu envoie réellement à Google, y compris les événements qui ne portent aucun revenu. Une valeur par défaut de 1 là où il devrait y avoir 0 ou rien gonfle tous les chiffres fondés sur la valeur que Google affiche, et aucun modèle d’attribution ne l’explique.
- Comparez uniquement des cohortes arrivées à maturité. Écartez au moins les cinq derniers jours pour Google Ads, et allez plus loin quand l’événement se situe plus tard que l’install. La comparaison de Google dit d’attendre la durée complète de la fenêtre de conversion avant d’évaluer une campagne, et la page Set a recommended initial Target ROAS for your App campaigns de Google suggère une fenêtre de 14 à 30 jours qui exclut la période la plus récente. Pour SKAN, attendez les postbacks sur lesquels vous vous appuyez.
- Choisissez un événement et une fenêtre. AppsFlyer note que, dans Google Ads, le rapport de conversions peut mélanger installs, achats et abonnements, donc filtrez sur la conversion d’install avant de comparer les installs. Puis placez côte à côte les fenêtres de la feuille de travail.
- Mettez tout sur la même base de date. Utilisez “Conversions (by conv. time)” dans Google Ads quand vous comparez à un MMP qui compte par date de lancement, ou comparez des totaux hebdomadaires là où un jour de dérive s’efface.
- Séparez les installs Google du MMP par match_type. Les lignes srn et probabilistic viennent de méthodes de revendication différentes, donc comparez chacune séparément et notez leurs parts au fil du temps.
- N’ajoutez jamais SKAN aux totaux modélisés. Ils mesurent les mêmes campagnes par des méthodes différentes. Placez-les l’un à côté de l’autre, pas l’un sur l’autre.
- Traitez la variation de l’écart comme le signal, pas l’écart. Un écart stable entre Google Ads et le MMP est une propriété des deux méthodes. Un écart qui double en une semaine est une question : une version du SDK, un changement de consentement, une nouvelle région, une action de conversion changée, un nouveau réglage de retéléchargement.
Les réglages de confidentialité n’ont leur place dans cette liste que comme des faits à consigner. La page de configuration d’AppsFlyer indique que lorsque son réglage Aggregated Advanced Privacy est activé, les données attribuées à Google dans les rapports bruts apparaissent comme restricted, et que le masquage d’IP peut affecter ICM. Ce sont des décisions de confidentialité du propriétaire de l’app. Je note comment ils sont réglés ; je ne les désactive pas pour faire correspondre les chiffres.
Quel chiffre dois-je utiliser pour quelle décision ?
Retour sur les enchères : Google Ads. Les cibles tCPA et tROAS se fixent et se jugent dans Google Ads, sur les conversions que Google Ads rapporte. Quand je me demande si une cible est trop serrée, je lis la colonne propre à Google, sur des jours arrivés à maturité, sur la fenêtre de 14 à 30 jours que Google suggère. Vérifier une cible Google avec des chiffres MMP mélange deux modèles et peut vous pousser à changer une cible qui était bonne.
Budget entre les canaux : le MMP. Il applique une seule règle de dernier clic sur tous les réseaux, ce que ni Google ni Meta ne peuvent faire l’un pour l’autre. C’est donc l’endroit le plus juste pour comparer Google à Meta ou à tout autre canal, à condition de se rappeler qu’il ne compte que les installs Google que Google lui revendique, et que la part de votre trafic iOS Google venant de l’EEE, du Royaume-Uni et de la Suisse n’a aucune revendication ICM. Là où cette part est importante, j’utilise SKAN comme seconde lecture de la direction.
Finance : aucune des deux plateformes publicitaires. Le revenu doit venir de là où il est facturé : votre plateforme d’abonnement ou les stores, rapproché du paid avec les vérifications de l’article sur la réconciliation Meta. Le MMP vous donne le revenu par canal, et SKAN offre un contrôle indépendant pour savoir si un canal bouge, mais aucun des trois n’est un grand livre.
Cela fait partie du travail de signal engineering que je mène : décider quel événement chaque système voit, depuis quelle source, et comment les écarts entre eux sont lus. Si vos chiffres Google iOS divergent et que vous ne savez pas quel écart est normal, un growth audit commence par cette feuille de travail, et il peut se réserver seul, quel que soit le niveau de dépense.
Sources
Toutes les pages ont été vérifiées le 29 septembre 2026.
- Understanding iOS App campaign measurement and reporting, Google Ads Help, aucune date de page affichée
- About Integrated Conversion Measurement for App Campaigns, Google Ads Help
- About on-device conversion measurement for iOS App campaigns, Google Ads Help
- Understand your conversion tracking data, Google Ads Help
- Set a recommended initial Target ROAS for your App campaigns, Google Ads Help
- Set up your SKAdNetwork conversion value schema, Google Ads Help
- Google Ads (AdWords) FAQ and discrepancies, AppsFlyer, dernière modification le 16 mars 2026
- Google Ads (AdWords) Integration setup for advertisers, AppsFlyer, dernière modification le 15 septembre 2026
- Bulletin: AppsFlyer and Google attribution solution (Open BETA), AppsFlyer, dernière modification le 5 août 2026
- SKAN Conversion Studio, AppsFlyer, dernière modification le 26 avril 2026
- Receiving postbacks in multiple conversion windows, Apple Developer, aucune date de page affichée
Questions fréquentes
Puis-je additionner les installs SKAN et ceux de Google Ads pour obtenir le total iOS complet ?
Non. Google décrit les conversions modélisées, ICM et SKAdNetwork comme trois façons de mesurer les mêmes App campaigns iOS, précise que votre choix entre elles dépend de l'état de votre implémentation, et note que les conversions modélisées sont elles-mêmes alimentées par SKAdNetwork quand c'est pertinent. Leurs installs se recoupent. Les additionner compte plusieurs fois les mêmes utilisateurs. Comparez-les plutôt côte à côte, sur le même événement et la même fenêtre.
Pourquoi Google Ads n'affiche-t-il pas les installs ICM que mon MMP affiche ?
Parce que Google les garde séparés aujourd'hui. La page de Google sur la mesure iOS indique que les données ICM ne sont pas disponibles dans le reporting Google Ads, et AppsFlyer précise que Google Ads n'affiche pas les installs basés sur ICM, tandis qu'AppsFlyer affiche les revendications ICM et n'affiche pas les installs modélisés en interne par Google. Chaque côté montre son propre modèle. Google dit que la mesure iOS dans Google Ads se rapprochera d'ICM pour les apps disposant d'ICM et de données d'événements de mesure on device, mais ne donne aucune date.
Pourquoi mon CPI Google est-il plus élevé dans AppsFlyer que dans Google Ads ?
La page d'AppsFlyer sur les écarts indique qu'il reçoit le coût Google de tous les canaux d'une campagne mais n'attribue les conversions des App campaigns iOS que depuis YouTube et Display, si bien que le MMP divise le coût total par moins d'installs. Vérifiez vos données brutes pour repérer des revendications ICM probabilistes avant de supposer que cela décrit encore votre compte.
Combien de temps attendre avant de comparer les trois chiffres ?
Google indique que les conversions iOS modélisées peuvent prendre jusqu'à cinq jours et recommande d'attendre la fenêtre de conversion complète avant de juger une campagne. SKAN est plus lent : la troisième fenêtre de conversion d'Apple se termine 35 jours après le premier lancement, et ce postback arrive après un délai aléatoire supplémentaire pouvant atteindre 144 heures.
ICM fonctionne-t-il pour les utilisateurs iOS de l'EEE, du Royaume-Uni et de la Suisse ?
Pas au 29 septembre 2026. La page de Google sur la mesure on device indique que la mesure on device utilisant les données d'événements, que Google liste comme prérequis iOS d'ICM, est inactive pour les utilisateurs de ces régions, et le bulletin d'AppsFlyer sur ICM indique qu'ICM n'est pas disponible pour le trafic iOS de ces régions. Les conversions modélisées de Google Ads et SKAN les couvrent toujours.