Le 29 septembre 2026, Google Analytics a fait tomber une cloison qui tenait depuis le lancement de GA4 : vos conversions app entrent enfin dans les rapports cross-canal. Jusqu’ici, l’attribution multi-touch et les modèles cross-canal ne regardaient que le web. Désormais, trois rapports (Performance des conversions, Analyse de l’attribution, Modèles d’attribution) prennent aussi en compte les conversions d’application, avec des paramètres d’attribution que vous réglez séparément pour le web et pour l’app. Bonne nouvelle, mais il y a un piège : tout n’est pas supporté, le crédit app reste bridé, et vos chiffres ne colleront toujours pas avec Google Ads ni Firebase. Ce guide fait le tri, puis vous donne une checklist de mise en place en 5 étapes et une grille pour savoir où les chiffres vont diverger.
Ce qui change vraiment le 29 septembre 2026
Jusqu’à cette date, un parcours qui se terminait par une conversion dans votre application restait invisible dans les rapports d’attribution cross-canal de GA4. Vous pouviez voir vos events app dans les rapports standards, mais pas leur part de crédit dans un modèle multi-touch mêlant web et app. C’est précisément ce qui s’ouvre maintenant.
Trois rapports accueillent les conversions app : Performance des conversions, Analyse de l’attribution et Modèles d’attribution. Autrement dit, vous pouvez enfin comparer comment un même modèle (par exemple data-driven) répartit le crédit sur vos conversions app, et pas seulement sur le web. Le changement structurant tient en un mot : les paramètres d’attribution sont désormais indépendants entre web et app. Vous n’êtes plus obligé d’imposer à votre app la fenêtre et le modèle pensés pour votre site.
Deux précautions avant de vous emballer. D’abord, le déploiement est progressif : si vous ne voyez pas encore ces données, ce n’est pas un bug de configuration, le rollout n’a simplement pas atteint votre propriété. Ensuite, “cross-canal pour l’app” ne veut pas dire “tous les canaux pour l’app”, et c’est le point que la plupart des relais d’actualité ont zappé.
Supporté ou non : la vraie liste
Avant de bâtir un reporting là-dessus, regardez froidement ce qui est couvert et ce qui ne l’est pas. La nuance fait toute la différence entre une analyse juste et une conclusion fausse.
| Élément | Statut pour l’app |
|---|---|
| Rapports Performance des conversions, Analyse de l’attribution, Modèles d’attribution | Conversions app prises en compte |
| Paramètres d’attribution (modèle, fenêtres) web et app | Réglables indépendamment |
| Crédit cross-canal attribué à l’app | Limité aux canaux payants Google |
| Budgétisation cross-canal (plans de projection, Scenario Planner) | Web uniquement |
| Rapport Chemins d’attribution (conversion paths) | Non inclus pour l’app |
| Accès Data API au reporting cross-canal | Alpha, sur liste |
| Déploiement | Progressif sur 2026 |
Le piège numéro un est la ligne “crédit cross-canal attribué à l’app”. Concrètement, l’app ne reçoit du crédit cross-canal que sur les canaux payants Google. Un parcours app qui démarre sur Meta, TikTok ou un canal organique ne verra pas ce point de contact crédité de la même façon qu’en web. Si vous bâtissez un arbitrage média multi-plateformes sur ces chiffres, vous surpondérez mécaniquement Google. Deuxième piège : la budgétisation cross-canal reste web-only, comme détaillé dans notre guide sur la budgétisation cross-canal GA4. N’espérez pas encore planifier un budget app depuis le Scenario Planner.
L’attribution web et app, enfin réglable séparément
C’est le vrai cadeau de cette mise à jour, et il mérite qu’on s’y arrête. Un parcours web et un parcours app n’ont ni la même latence ni le même cycle de décision. Imposer une fenêtre de conversion unique aux deux, c’était fausser au moins l’un des deux. Vous pouvez maintenant choisir, pour l’app, un modèle d’attribution et des fenêtres (clic et engagement) distincts de ceux du web.
Le bon réflexe : ne recopiez pas vos réglages web par défaut. Partez du comportement réel de votre app. Une app dont l’installation précède l’achat de plusieurs jours a besoin d’une fenêtre plus large qu’un site de vente flash. Si vous ne savez pas quelle valeur poser, la méthode est la même qu’en web et je l’ai détaillée dans le guide sur la fenêtre de conversion GA4 : mesurez la distribution réelle du délai entre interaction et conversion, puis calez la fenêtre dessus plutôt que sur une habitude. Pour comprendre pourquoi vos volumes attribués ont déjà bougé en 2026, le point de contexte se trouve dans l’article sur les changements d’attribution GA4 en 2026.
Auditez vos conversions app avant de regarder les rapports
Un rapport d’attribution ne vaut que ce que valent les conversions qu’il mesure. Et côté app, la confusion classique est celle entre key events et conversions. Tous vos key events ne sont pas des conversions : GA4 ne crédite dans ces rapports que les events marqués comme conversions. Si votre purchase app n’est pas marqué, il n’apparaîtra pas dans Performance des conversions, et vous conclurez à tort que l’app ne convertit pas.
La passe d’audit tient en trois contrôles. Vérifiez d’abord quels events app sont effectivement marqués comme conversions, et purgez ceux qui ne devraient pas l’être (un login marqué conversion gonfle tout). Vérifiez ensuite que ces events remontent proprement, sans doublon ni perte : un event app dédoublé contamine l’attribution aussi sûrement qu’en web. Si votre collecte app passe par un tunnel server-side, le guide tracking server-side pour applications mobiles couvre les pièges de déduplication et de nommage. Vérifiez enfin que la définition d’une conversion est la même qu’ailleurs dans votre stack, sinon la comparaison avec Google Ads ou Firebase part déjà faussée.
Mise en place en 5 étapes
Voici la séquence que je recommande pour exploiter ces rapports sans vous faire piéger.
- Confirmez le déploiement. Ouvrez Performance des conversions et vérifiez que vos conversions app y figurent. Si rien n’apparaît, le rollout n’a pas atteint votre propriété : repassez plus tard plutôt que de tout reconfigurer.
- Auditez vos conversions app. Distinguez key events et conversions, marquez les bons events, supprimez les faux positifs. C’est la fondation de tout le reste.
- Réglez l’attribution app séparément. Dans les paramètres d’attribution, choisissez le modèle et les fenêtres propres à l’app, en vous appuyant sur votre délai réel interaction vers conversion.
- Croisez les trois rapports. Lisez Performance des conversions pour le volume, Analyse de l’attribution pour la répartition du crédit, Modèles d’attribution pour comparer les logiques. Un écart entre les trois est une information, pas une erreur.
- Documentez les divergences attendues. Avant toute comparaison avec Google Ads ou Firebase, écrivez noir sur blanc pourquoi les chiffres ne colleront pas (voir la grille ci-dessous). Ça évite les mauvaises réunions.
Où les chiffres vont diverger (et pourquoi)
C’est la partie que personne ne veut lire et que tout le monde devrait lire. Comparer vos conversions app entre GA4, Google Ads et Firebase sans savoir où elles divergent, c’est se préparer à des conclusions absurdes. Voici la grille des divergences structurelles.
| Source de divergence | GA4 (rapports cross-canal) | Google Ads | Firebase |
|---|---|---|---|
| Périmètre des canaux | Tous canaux, mais crédit app limité aux canaux payants Google | Canaux Google Ads uniquement | Réseaux configurés, logique SKAdNetwork |
| Modèle d’attribution | Réglable, indépendant web et app | Attribution propre à Google Ads | Dernière interaction ou modèle réseau |
| Fenêtre de conversion | Réglage GA4 app | Réglage Google Ads | Réglage réseau ou SKAN |
| Date de rattachement | Date d’interaction ou date de conversion selon le rapport | Date de conversion | Date de l’event |
| Définition de la conversion | Key events marqués conversion | Conversions importées ou mesurées | Events Firebase |
Deux lignes méritent un mot. La date de rattachement est un piège silencieux : selon le rapport, une conversion peut être comptée à sa date d’interaction (le jour du clic) ou à sa date de conversion (le jour de l’achat). Comparer un rapport calé sur l’interaction avec un rapport calé sur la conversion, c’est comparer deux journées différentes et s’étonner qu’elles diffèrent. Le périmètre des canaux explique, lui, la majorité des écarts avec les plateformes publicitaires : le mécanisme est le même que celui décrit pour le web dans l’article Meta Ads vs GA4, chaque outil mesure dans son propre référentiel.
Accéder au reporting cross-canal via la Data API (alpha)
Pour ceux qui veulent sortir ces données de l’interface, l’accès au reporting cross-canal via la Data API existe, mais en alpha et sur liste. Utile pour alimenter un Looker Studio ou un entrepôt, à condition d’accepter l’instabilité d’une alpha : schémas susceptibles de bouger, périmètre incomplet, quotas à surveiller.
Mon conseil de praticien : ne reconstruisez pas tout de suite un pipeline de production dessus. Tant que l’alpha n’est pas stabilisée et que le rollout n’est pas généralisé, gardez votre source de vérité ailleurs. Pour une analyse robuste et reproductible des conversions, l’export brut reste le socle le plus fiable, comme le montrent les requêtes BigQuery indispensables pour GA4.
FAQ
Mes conversions app apparaissent-elles dans tous les rapports cross-canal ?
Non. Elles sont prises en compte dans Performance des conversions, Analyse de l’attribution et Modèles d’attribution, mais pas dans le rapport Chemins d’attribution, qui reste hors périmètre pour l’app à ce stade.
Puis-je piloter mon budget app depuis la budgétisation cross-canal ?
Non. Les plans de projection et le Scenario Planner restent web uniquement. La budgétisation cross-canal ne couvre pas encore les conversions app.
Pourquoi mes chiffres app diffèrent-ils de Firebase et de Google Ads ?
Parce que chaque outil mesure dans son propre référentiel : périmètre de canaux, modèle et fenêtre d’attribution, date de rattachement et définition de conversion diffèrent. La grille de divergences ci-dessus détaille chaque axe.
Faut-il raisonner en date d’interaction ou en date de conversion ?
Les deux existent selon le rapport. Fixez la convention avant de comparer quoi que ce soit, sinon vous comparez des périodes décalées.
Comment accéder au reporting cross-canal par la Data API ?
L’accès est disponible en alpha, sur liste. À réserver à l’exploration pour l’instant, pas à un pipeline de production.
En résumé
L’ouverture des rapports cross-canal aux conversions app est une vraie avancée : vous réglez enfin l’attribution app indépendamment du web, et vous voyez vos conversions d’application dans les modèles multi-touch. Mais gardez la tête froide sur trois limites : le crédit cross-canal de l’app se cantonne aux canaux payants Google, la budgétisation reste web-only, et le rapport Chemins d’attribution ignore encore l’app. La marche à suivre est simple : auditez vos conversions app, réglez des fenêtres app cohérentes avec votre délai réel, croisez les trois rapports, et documentez vos divergences avec Google Ads et Firebase avant d’en tirer la moindre décision budgétaire. Faites ce travail de fond, et ces nouveaux rapports deviennent un appui de décision solide plutôt qu’une source de malentendus.