· 13 min · Samet Durgun

Comment configurer Google ICM et la mesure on device pour iOS ?

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.

Pour obtenir l’Integrated Conversion Measurement (ICM) de Google sur iOS, il vous faut une App Campaign iOS pour installs, la mesure on device (ODM) via le SDK Google Analytics for Firebase ou le SDK autonome GoogleAdsOnDeviceConversion de Google, un SDK de partenaire d’attribution au moins à sa version minimale documentée avec son réglage Google activé, et les informations de conversion récupérées au premier lancement avant l’envoi de first_open. La condition qui change la réponse est la région : au 29 septembre 2026, la documentation de Google indique que la mesure on device est inactive pour les utilisateurs de l’EEE, du Royaume-Uni et de la Suisse, donc rien de tout cela ne produit encore de revendications ICM pour eux.

Périmètre : les App Campaigns iOS pour installs, mesurées via AppsFlyer, Adjust ou Singular, par la voie Firebase ou par le SDK autonome, vérifiées le 29 septembre 2026 dans les pages propres à chaque éditeur. Google change souvent ce domaine, donc vérifiez la date avant de vous fier à un numéro de version.

J’ai piloté des App Campaigns iOS avec ICM via AppsFlyer, sur une app subscription en mars 2026. La leçon que je retiendrais de ce compte n’avait rien à voir avec l’ICM lui-même, et c’est la dernière étape de l’install de test ci-dessous.

Quelle est la différence entre ODM et ICM ?

L’ODM est le signal. L’ICM est l’endroit où le résultat apparaît.

La page de Google About on-device conversion measurement for iOS App campaigns décrit deux variantes d’ODM : l’une utilise des données first party comme l’email ou le numéro de téléphone issus de votre parcours de connexion, l’autre utilise ce que Google appelle “de-identified, temporary app event data”, des données d’événements d’app dépersonnalisées et temporaires, dérivées de signaux comme l’adresse IP et les horodatages. L’ICM sur iOS dépend de la seconde.

La page de Google About Integrated Conversion Measurement for App Campaigns liste quatre étapes iOS : une App Campaign iOS active pour installs, les données de votre partenaire d’attribution importées dans Google Ads, l’ODM avec des données d’événements, et le dernier SDK du partenaire. Les intégrations server to server doivent transmettre la chaîne d’information ODM au partenaire. Sur Android, la même page indique qu’aucune action n’est requise.

Donc l’ODM rend possibles les revendications d’installs de Google, et l’ICM, c’est Google qui envoie ces revendications dans votre MMP, où elles apparaissent comme des attributions probabilistes.

Que demande chaque voie d’intégration ?

Le tableau met les cinq voies côte à côte, une ligne par voie.

Voie Minimum documenté Réglage Périmètre régional Étape de vérification Source, vérifiée le
Firebase (GA4F) iOS 12+. GA4F 11.14.0 selon la page d’aide de Google et le tutoriel Firebase ; 12.12.1+ selon le guide iOS de Google (non tranché, voir plus bas) Liez la propriété Google Analytics au compte Google Ads. Le pod FirebaseAnalytics inclut déjà GoogleAdsOnDeviceConversion Inactif pour les utilisateurs de l’EEE, du Royaume-Uni et de la Suisse Lancez avec -FIRDebugEnabled, cherchez le log “framework is linked”, puis la propriété utilisateur _psmvalue_gads après environ 15 secondes Google 12119136, tutoriel Firebase, 29 sept. 2026
SDK autonome GoogleAdsOnDeviceConversion Aucun minimum indiqué sur la page de Google. Dernière version 3.7.0 (1er sept. 2026). Si vous installez aussi GA4F, suivez la table de correspondance des versions de Google setFirstLaunchTime avec la vraie date du premier lancement, puis fetchAggregateConversionInfo(for: .installation), puis transmettez le résultat comme odm_info La page ODM de Google exclut l’EEE, le Royaume-Uni et la Suisse ; la ligne de dépannage de cette page la contredit (voir plus bas) Vérifiez qu’une chaîne d’information non vide existe avant l’envoi de first_open, et que odm_info figure dans le premier appel d’install Google 16384720, page Google pour développeurs, dépôt GitHub, 29 sept. 2026
AppsFlyer SDK iOS 6.17.9+, plus Firebase 11.14.0+ ou le SDK autonome Advanced Data Sharing dans l’intégration Google Ads. first_open importé comme conversion. IDFV avec chaque ouverture d’app et chaque événement in app, adresse IP avec chaque ouverture d’app Non disponible pour les utilisateurs iOS de l’EEE, du Royaume-Uni et de la Suisse match_type dans les données brutes : srn pour les revendications déterministes, probabilistic pour les revendications ICM bulletin AppsFlyer, configuration AppsFlyer, 29 sept. 2026
Adjust SDK iOS 5.4.1+ avec le plugin ODM (testé avec GoogleAdsOnDeviceConversion 3.0.0), plus Firebase 11.14.0+ ou le SDK autonome “Enable probabilistic modeling” dans les réglages d’attribution du partenaire Google Ads. Appelez initSdk le plus tôt possible Les pages d’Adjust ne nomment aucune limite régionale ; l’exclusion ODM de Google s’applique toujours Adjust ne documente aucune étape de vérification dans les pages que j’ai consultées Adjust Dev Hub, Adjust Help, 29 sept. 2026
Singular SDK iOS natif 12.8.1+ (Unity 5.5.0+) enableOdmWithTimeoutInterval, 5 secondes recommandées. “Include Integrated Conversion Measurement Attributions” dans la configuration du partenaire Google Ads Non supporté sur les appareils iOS de l’EEE et du Royaume-Uni (Suisse non nommée) Les installs ICM apparaissent comme des installs par clic, libellés probabilistic dans les rapports au niveau utilisateur aide Singular, 29 sept. 2026

Chaque ligne de partenaire ne liste que ce que ce partenaire documente pour lui-même. Le choix entre Firebase et le SDK autonome a une conséquence sur les enchères que les pages de configuration n’expliquent pas. La page de Google About bidding in App campaigns indique que le tROAS exige le SDK Google Analytics for Firebase, et l’article de configuration d’AppsFlyer indique que vous ne pouvez exclure des audiences des App Campaigns que si la campagne optimise vers des événements du SDK Firebase, pas vers des événements du MMP. Si vous prévoyez d’enchérir sur la valeur plus tard, la voie autonome résout la mesure mais pas cela. Si vous installez les deux, le dépôt GoogleAdsOnDeviceConversion de Google publie une table de correspondance des versions : GA4F 12.19.0 va avec ODM 3.7.0, 12.12.1 avec 3.5.0, et 11.14.0 avec 2.0.0.

Quelle est la version minimale de Firebase, 11.14.0 ou 12.12.1 ?

La documentation de Google donne deux réponses, et je n’ai trouvé aucune source qui tranche.

La page d’aide de Google sur la mesure on device demande “version 11.14.0 available in June 2025”, et le Tutorial: Measure iOS Ads conversions using event data de Firebase (dernière mise à jour le 25 septembre 2026) indique 11.14.0 ou supérieure. Le iOS Best Practices Guide: Do the iOS Three to maximize your ROI de Google, qui n’est pas daté, liste le SDK Firebase en “minimum version 12.12.1+” dans ses étapes d’implémentation. AppsFlyer et Adjust répètent tous les deux 11.14.0.

Je traite cela comme un écart non résolu entre deux sources de Google. Notez la version que l’app embarque, et signalez l’écart à Google avant de figer l’app en dessous de 12.12.1.

Pourquoi l’ordre du premier lancement compte-t-il ?

Parce que les informations de conversion doivent exister avant que l’install soit rapporté. La page développeur de Google pour l’App Conversion API, Integrated Conversion Measurement, indique de récupérer les informations de conversion peu après le premier lancement de l’app, avant l’envoi de l’événement first_open, et de les transmettre dans le paramètre odm_info. La page du SDK autonome de Google ajoute que la récupération s’applique à first_open comme à reinstall_open, et que setFirstLaunchTime doit recevoir la date à laquelle l’app a réellement été lancée pour la première fois.

Les partenaires gèrent l’attente différemment :

  • Le SDK de Singular attend les informations ODM jusqu’au délai que vous fixez, 5 secondes recommandées, et Singular avertit que cela retarde les callbacks du SDK, y compris les deep links. Pour les configurations server to server, il note que la récupération est asynchrone et qu’il peut falloir retenir l’événement de session jusqu’à ce qu’elle soit terminée.
  • Adjust indique d’appeler initSdk le plus tôt possible, idéalement dans application:didFinishLaunchingWithOptions:. Avec First Session Delay, vous appelez quand même initSdk tôt pour que l’ODM enregistre l’heure du lancement, et vous mettez fin au délai plus tard.

Dans un audit, la première chose à vérifier est de savoir si un écran de consentement, un paywall ou un parcours d’onboarding démarre le SDK du MMP plus tard que la documentation ne l’attend. La documentation ne donne aucune valeur de délai universelle, donc testez l’ordre sur un vrai install.

L’ICM fonctionne-t-il pour les utilisateurs iOS de l’EEE, du Royaume-Uni et de la Suisse ?

Pas dans la documentation consultée le 29 septembre 2026.

  • La page de Google sur la mesure on device : la fonctionnalité sera inactive pour tous les utilisateurs situés dans l’EEE, le Royaume-Uni et la Suisse (“will be inactive for all users located within”, dans le texte de la page).
  • Le tutoriel Firebase : le message de vérification n’apparaîtra pas pour les appareils situés dans ces zones.
  • Le Bulletin: AppsFlyer and Google attribution solution [Open BETA] d’AppsFlyer (modifié le 5 août 2026) exclut le trafic iOS des utilisateurs des trois zones, et son article de configuration (modifié le 15 septembre 2026) liste l’UE, le Royaume-Uni et la Suisse comme non supportés.
  • Singular (mis à jour le 24 septembre 2026) indique que l’ICM n’est pas supporté sur les appareils iOS de l’EEE et du Royaume-Uni.

En mai 2026, l’annonce iOS App campaign advancements de Google disait qu’elle élargit le support de mesure pour les utilisateurs de l’EEE, du Royaume-Uni et de la Suisse (“expanding measurement support for EEA, UK, and Switzerland users”). Elle ne donne aucune date. Une annonce est un plan, donc je ne planifie pas de budget dessus tant que la page d’aide de Google et la documentation des MMP n’ont pas changé.

Une incohérence de documentation : la liste de dépannage sur la page du SDK autonome de Google dit de vérifier que votre app tourne dans l’EEE, le Royaume-Uni et la Suisse. Cela contredit la propre page de Google sur la mesure on device. Je la lis comme une erreur de documentation, pas comme la preuve que le support de l’Europe est lancé.

Les utilisateurs iOS européens restent mesurés, simplement pas via l’ICM. La page de Google Understanding iOS App campaign measurement and reporting indique que les conversions modélisées dans Google Ads et SKAdNetwork sont disponibles pour tous les utilisateurs, y compris ceux de l’EEE, du Royaume-Uni et de la Suisse. La colonne ICM ne fait pas cette déclaration.

Qu’est-ce que l’ICM couvre, et qu’est-ce qu’il laisse de côté ?

D’après l’article de configuration d’AppsFlyer, qui a la liste la plus complète :

  • Installs et réattributions uniquement. Pas de réengagements.
  • Clics uniquement sur iOS. “Google currently claims only clicks on iOS. It does not claim impressions.” Singular décrit aussi seulement la mesure des installs par clic, et Adjust indique que l’ICM n’est supporté que pour les App Campaigns pour installs.
  • Campagne et groupe d’annonces, pas l’annonce. AppsFlyer indique que les revendications incluent la campagne et le groupe d’annonces “in most cases” et aucune information sur l’annonce. Singular indique que l’ID du groupe d’annonces n’est pas disponible, et le guide de Google parle de données au niveau campagne maintenant, au niveau groupe d’annonces “soon”. Comptez sur le niveau campagne.
  • Un canal partiel. Le champ canal affiche ACI_ sans suffixe de réseau.
  • Des horodatages arrondis. Les horodatages des revendications probabilistes sont arrondis à des intervalles de 15 minutes.

Le guide de Google indique aussi que l’ICM supporte des fenêtres de lookback post install jusqu’à 180 jours, ce qui compte pour les apps subscription dont les événements payants arrivent des semaines après l’install. Le guide relie ces fenêtres au tROAS, mais la page d’enchères de Google indique toujours que le tROAS exige le SDK Firebase, donc le choix de voie ci-dessus s’applique toujours.

Comment tester un install de bout en bout ?

Pour un install de test, notez :

  1. Les versions. Build de l’app, version de GA4F ou de GoogleAdsOnDeviceConversion, version du SDK du MMP. Vérifiez la paire avec la table de correspondance des versions de Google.
  2. La région. Où l’appareil est situé. Un appareil de l’EEE, du Royaume-Uni ou de Suisse ne devrait pas produire d’informations ODM.
  3. L’état ATT et du consentement. La réponse ATT et les choix de votre plateforme de consentement, et si l’un des deux retient le SDK du MMP.
  4. L’ordre. Si les informations de conversion ont été récupérées avant l’envoi de first_open, et si odm_info figurait dans le premier appel d’install. Sur la voie Firebase, la séquence de logs de debug du tableau.
  5. Les réglages. L’interrupteur du partenaire du tableau, et first_open importé comme conversion dans Google Ads.
  6. La ligne brute du MMP. Dans AppsFlyer, match_type valant srn ou probabilistic. Dans Singular, la répartition probabiliste dans les rapports au niveau utilisateur.
  7. Les valeurs. Ce que chaque événement de revenu envoie à Google, y compris les événements qui ne portent aucun revenu. Sur le compte ci-dessus, l’événement de revenu envoyait 1 $ au lieu de 0 $ quand il n’y avait pas de valeur. Google Ads affichait 71,4 % de ROAS sur la campagne iOS contre 17,3 % de ROAS lifetime dans AppsFlyer, et l’ICM n’en était pas la cause. Ma lecture de cet écart est dans pourquoi Google Ads, votre MMP et SKAN rapportent des conversions iOS différentes.

Changez un composant à la fois. Une revendication manquante ne prouve pas qu’une configuration est cassée : AppsFlyer valide chaque revendication probabiliste de Google avec son propre modèle, et une revendication acceptée doit encore l’emporter face aux autres candidats d’attribution.

Faut-il changer les réglages de confidentialité ou le masquage d’IP pour obtenir plus de revendications ?

Je ne les traite pas comme des interrupteurs de couverture. Ce sont des décisions de conformité du propriétaire de l’app.

L’article de configuration d’AppsFlyer indique que le masquage d’IP peut affecter l’ICM et que Google recommande de le désactiver. Il indique aussi qu’avec l’interrupteur Aggregated Advanced Privacy activé, les données attribuées à Google apparaissent comme restreintes dans les rapports bruts, et qu’Advanced Data Sharing envoie les installs à Google avec ou sans identifiant d’appareil. La page d’Apple User Privacy and Data Use dit “you may not derive data from a device for the purpose of uniquely identifying it” (vous ne pouvez pas dériver des données d’un appareil dans le but de l’identifier de façon unique), et que tracker un utilisateur exige l’autorisation ATT.

Deux faits aident à décider : le pod FirebaseAnalytics inclut déjà la bibliothèque ODM, et l’opt out prévu par Google consiste à exclure GoogleAdsOnDeviceConversion du build. Décidez avec votre conseil juridique en matière de confidentialité, puis mesurez ce que la configuration choisie permet.

Pourquoi Google Ads, le MMP et SKAN ne seront-ils toujours pas d’accord ?

Parce que ce sont trois mesures différentes. La page de Google sur la mesure et le reporting indique que les données ICM ne sont pas disponibles aujourd’hui dans le reporting Google Ads, que Google Ads affiche ses propres conversions modélisées avec des délais pouvant aller jusqu’à cinq jours, et que SKAdNetwork est le flux agrégé d’Apple avec ses propres fenêtres. Google indique aussi que le reporting iOS de Google Ads passera des conversions modélisées à l’attribution ground truth pour les campagnes disposant de données d’événements de mesure on device. Je réconcilie les trois sur le même événement, la même base de dates et la même fenêtre plutôt que de les additionner, et j’explique cette méthode dans pourquoi Google Ads, votre MMP et SKAN rapportent des conversions iOS différentes.

Où cela s’inscrit-il dans mon travail ?

C’est la partie Google iOS du signal engineering : s’assurer que le système d’enchères voit les conversions qui comptent vraiment pour le business. Concrètement, cela veut dire choisir la voie Firebase ou autonome en pensant aux enchères, confirmer l’ordre du premier lancement sur un vrai install, et écrire noir sur blanc l’écart attendu entre Google Ads, le MMP et SKAN avant que quiconque déplace du budget. Si vous ne savez pas si la mesure est le problème, le growth audit est l’endroit où je le vérifie. Une meilleure mesure ne décide pas où une App Campaign dépense, ce que j’explique dans pourquoi une App Campaign déplace la dépense vers YouTube.

Sources

Toutes vérifiées le 29 septembre 2026.

Questions fréquentes

Faut-il Firebase pour la mesure on device de Google sur iOS ?

Pas pour la mesure elle-même. Google documente un SDK GoogleAdsOnDeviceConversion autonome pour les apps qui ne peuvent pas intégrer Google Analytics for Firebase, et AppsFlyer comme Adjust acceptent les deux voies. Firebase compte pour les enchères : Google indique que le tROAS sur les App Campaigns exige le SDK Firebase, et AppsFlyer indique que l'exclusion d'audiences ne fonctionne que si la campagne optimise vers des événements Firebase.

Google ICM est-il disponible en Europe sur iOS ?

Pas selon la documentation au 29 septembre 2026. La page de Google sur la mesure on device indique que la fonctionnalité est inactive pour les utilisateurs de l'EEE, du Royaume-Uni et de la Suisse, AppsFlyer exclut ce trafic iOS de l'ICM, et Singular exclut les appareils iOS de l'EEE et du Royaume-Uni. Google a annoncé en mai 2026 un support élargi pour ces utilisateurs, sans date. Les conversions modélisées dans Google Ads et SKAdNetwork les couvrent toujours.

Les installs ICM apparaîtront-ils dans Google Ads ?

Pas aujourd'hui. Google indique que les données ICM ne sont pas disponibles dans le reporting Google Ads et apparaissent chez votre partenaire d'attribution, tandis que Google Ads affiche ses propres conversions modélisées. Google indique aussi que le reporting iOS de Google Ads passera des conversions modélisées à l'attribution ground truth pour les campagnes disposant de données d'événements de mesure on device.

Faut-il désactiver le masquage d'IP ou les réglages de confidentialité pour obtenir plus de revendications ICM ?

C'est une décision de conformité pour le propriétaire de l'app, pas une étape de dépannage. AppsFlyer note que le masquage d'IP peut affecter l'ICM et que son interrupteur de confidentialité affiche les données Google comme restreintes. Apple interdit de dériver des données d'un appareil pour l'identifier et exige l'autorisation ATT pour tracker. Décidez de ces réglages avec votre conseil juridique en matière de confidentialité, puis mesurez ce que la configuration choisie permet.