Migration d’Universal Analytics vers GA4 : pièges à éviter

2026-07-27 · 10 min · Google Analytics

Passer de Universal Analytics à GA4 ne se résume pas à “installer une balise”. Découvrez les pièges qui faussent vos données et comment les éviter pas à pas.

Pourquoi la migration UA → GA4 est un projet (pas un simple remplacement)

La migration d’Universal Analytics (UA) vers Google Analytics 4 (GA4) est souvent sous-estimée : on pense “nouvelle balise, mêmes rapports”. En réalité, GA4 repose sur un modèle événementiel (events) et non plus sur des sessions/pages vues comme UA. Résultat : si vous migrez “à l’identique”, vous risquez des écarts importants, des KPI incomparables et des décisions prises sur des données biaisées.

Quelques repères chiffrés réalistes observés lors de migrations :

• Une différence de 5 à 20% sur le nombre de sessions/utilisateurs est fréquente, selon la configuration (consentement, cross-domain, filtres, etc.). • Le taux d’engagement GA4 (basé sur les sessions engagées) n’a pas d’équivalent direct avec le taux de rebond UA : selon les sites, l’écart perçu peut être de 30 à 60 points. • Sur l’e-commerce, des divergences de 2 à 10% sur le chiffre d’affaires attribué peuvent apparaître si les événements (purchase, refunds, currency) ou le dédoublonnage ne sont pas maîtrisés.

Objectif de cet article : vous donner une approche actionnable pour éviter les pièges les plus courants, avec des exemples concrets et des benchmarks réalistes.

Piège n°1 : croire que les KPI UA et GA4 sont “équivalents”

Le premier piège est conceptuel : comparer GA4 et UA comme si c’était le même outil. Les définitions changent, et donc les KPI aussi.

Les différences de modèle qui cassent les comparaisons

• UA : logique session/pageview (catégories, actions, libellés) et objectifs. • GA4 : logique événement (tout est event), avec des paramètres, des propriétés utilisateur, et des conversions.

Conséquences directes :

• Utilisateurs : UA s’appuie sur un modèle différent d’identification (et des paramètres historiques). GA4 peut compter différemment selon le consentement, Google signals, device ID, etc. • Sessions : GA4 redéfinit la session (ex. gestion des campagnes, événements, timeouts). Un changement de source/medium en cours de session peut être traité différemment. • Rebond : en GA4, le “rebond” est dérivé de l’engagement (rebond = 100% - taux d’engagement). Vous ne pouvez pas comparer un taux de rebond UA à GA4 sans expliquer la nouvelle logique.

Benchmarks réalistes pour se calibrer

Sans être une vérité universelle, voici des ordres de grandeur utiles pour détecter une migration “anormale” :

• Site contenu (blog/média) : taux d’engagement GA4 souvent entre 45% et 70%. • Site B2B (lead gen) : 50% à 75% selon la qualité du trafic. • E-commerce : 35% à 65% selon catalogue, vitesse, mobile, sources.

Si votre taux d’engagement tombe à 10% ou grimpe à 95% après migration, c’est souvent un signe de configuration ou de tracking défaillant.

Action : créer une table de correspondance des KPI

Avant de migrer, listez vos KPI critiques et définissez leur “équivalent GA4” (ou son remplacement). Exemples :

• UA “Objectifs” → GA4 Conversions (basées sur événements) • UA “Pages/session” → GA4 Vues + analyse via explorations (moins central) • UA “Taux de rebond” → GA4 Taux d’engagement (et rebond dérivé)

Piège n°2 : une implémentation de tracking incomplète (ou trop automatique)

Installer GA4 via Google Tag Manager (GTM) ou via une intégration CMS ne garantit pas un tracking fiable. Beaucoup de migrations échouent sur les fondamentaux : événements clés absents, doublons, paramètres manquants, cross-domain cassé.

Exemple concret : formulaire de lead “mesuré” mais inutilisable

Cas fréquent : vous déclenchez un événement “form_submit” au clic sur le bouton. Problème :

• Le clic ne signifie pas envoi réussi (erreurs de validation, captcha, timeout). • Vous comptez des conversions fantômes.

Solution actionnable :

• Déclencher l’événement sur la page de confirmation (thank-you page) quand c’est possible. • Ou déclencher sur un événement technique fiable (ex. callback JavaScript de succès) avec un paramètre form_id.

Les erreurs de base à éviter

• Double comptage : GA4 configuré à la fois via gtag intégré au site et via GTM. • Événements en doublon : un événement “purchase” envoyé deux fois (front + back), ou un trigger GTM trop large. • Paramètres manquants : sur e-commerce, absence de currency, value, items[]. • Cross-domain non configuré : vous perdez la continuité de session entre domaine principal et domaine de paiement.

Checklist d’implémentation (actionnable)

Vérifier qu’une seule méthode d’implémentation GA4 est active (gtag OU GTM, pas les deux). Activer le debug (Preview GTM + DebugView GA4) et tester un parcours complet. Valider les événements clés : - generate_lead (ou équivalent) - purchase (si e-commerce) - sign_up, login (si pertinent) - view_item, add_to_cart, begin_checkout (e-commerce) Contrôler les paramètres indispensables : - value, currency - transaction_id (unique) - items (id, name, quantity, price) Tester le cross-domain avec une navigation réelle (et vérifier que la session ne “redémarre” pas).

Piège n°3 : mal gér…