Quelles limites GA4 faut-il connaître avant de migrer ?

GA4 ne remplace pas Universal Analytics à l’identique. On perd l’historique UA, on subit des limites de collecte, et la conformité RGPD reste un vrai sujet. Je vous montre où ça coince, comment réduire les dégâts, et quand GA4 doit être complété par d’autres briques data.

Pourquoi GA4 ne reprend pas l’historique UA ?

GA4 ne reprend pas l’historique UA parce que ce ne sont pas les mêmes données derrière. Ce n’est pas une simple migration d’interface avec un nouveau logo et deux menus déplacés. C’est une rupture de modèle.

Universal Analytics, ou UA, fonctionnait surtout avec des sessions, des pages vues, des objectifs, des transactions et plusieurs types de hits séparés. Un hit, c’est juste une interaction envoyée à Google Analytics, par exemple une page vue ou un événement. GA4, lui, enregistre presque tout sous forme d’événements, avec des paramètres associés. Une page vue devient un événement. Un achat devient un événement. Un clic aussi. Donc Google ne peut pas juste “copier-coller” l’ancien historique dans GA4 sans le transformer, et cette transformation ne serait jamais parfaitement fiable.

Le résultat business est assez concret. Si vous n’avez pas lancé GA4 assez tôt, vous perdez de la profondeur historique dans vos rapports GA4. Vous ne pouvez pas comparer proprement 2021, 2022, 2023 et 2024 dans la même logique de mesure. Les équipes SEO perdent leurs repères sur les tendances longues. L’acquisition ne retrouve plus exactement ses comparaisons par canal. L’e-commerce voit des écarts sur les transactions. La direction demande “pourquoi les chiffres ont changé ?”, et souvent la vraie réponse, c’est que l’outil ne mesure plus pareil.

Les dates sont importantes. Universal Analytics standard a cessé de traiter de nouvelles données le 1er juillet 2023. Universal Analytics 360 a cessé le 1er juillet 2024. Les anciennes données UA ne sont pas transférées dans GA4.

Découvrez égalementComment trouver un bottleneck de funnel avec GA4 ?

Ce que je conseille, c’est simple. Exportez ce qui reste disponible côté UA avant suppression ou indisponibilité. Stockez-le dans BigQuery, dans un data warehouse, ou même dans des exports CSV propres si votre maturité data est plus limitée. On ne recrée pas un historique GA4 après coup. On peut seulement archiver l’ancien, documenter les écarts, et reconstruire une nouvelle base de comparaison à partir de GA4.

J’ai vu des équipes découvrir trop tard que leurs dashboards Looker Studio branchés sur UA ne racontaient plus rien d’exploitable. Le problème n’était pas Looker Studio. Le vrai sujet, c’était l’absence de plan de conservation des données.

Quelles limites de collecte bloquent GA4 ?

GA4 collecte beaucoup de choses, mais pas sans limites. Le piège que je vois souvent en migration, c’est qu’on garde le réflexe Universal Analytics ou dataLayer “fourre-tout”. On envoie tout, puis on découvre que GA4 impose des arbitrages.

Le point dur, c’est surtout la limite de 25 paramètres par événement côté collecte GA4 standard. Ça touche les événements collectés automatiquement, la mesure améliorée, les événements recommandés et vos événements personnalisés. Même logique avec les propriétés utilisateur, les dimensions personnalisées et certains quotas d’événements. GA4 360 augmente plusieurs plafonds, oui, mais à un coût qui correspond plutôt à des organisations déjà matures sur la data.

Sur un gros e-commerce, ça va très vite. Une équipe veut envoyer la marque, la catégorie, la marge, la promo, le stock, le type de livraison, le score client, la disponibilité magasin, le statut fidélité, le canal d’acquisition interne… Tout semble utile. Sauf qu’à la fin, il faut choisir ce qui sert vraiment à décider.

Découvrez égalementQuelles limites de Google Analytics 4 pour vos données ?

Ma règle est simple : je fais un plan de taggage sobre. Je garde les paramètres utiles à l’analyse, à l’activation marketing ou au debug. Je réserve les dimensions personnalisées aux données actionnables. Le reste part dans BigQuery, dans le CRM ou dans un outil BI, mais pas forcément dans chaque event GA4.

// Liste blanche des paramètres autorisés pour GA4 via GTM
const allowedParams = [
  'event',
  'item_id',
  'item_name',
  'item_brand',
  'item_category',
  'price',
  'currency',
  'promotion_name'
];

// Nettoie un event avant push dataLayer
function pushCleanEvent(rawEvent) {
  const cleanEvent = {};

  allowedParams.forEach((key) => {
    if (rawEvent[key] !== undefined && rawEvent[key] !== null && rawEvent[key] !== '') {
      cleanEvent[key] = rawEvent[key];
    }
  });

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push(cleanEvent);
}

// Exemple compatible GTM
pushCleanEvent({
  event: 'view_item',
  item_id: 'SKU123',
  item_name: 'Chaussure running',
  item_brand: 'Nike',
  item_category: 'Sport',
  price: 89.9,
  currency: 'EUR',
  margin: 24,
  stock_status: 'low'
});

BigQuery ne supprime pas la limite de collecte GA4. Par contre, il aide à contrôler la qualité et à voir quand les équipes recommencent à empiler trop de paramètres.

-- Audit du nombre moyen et maximum de paramètres par event_name
WITH event_rows AS (
  SELECT
    event_name,
    user_pseudo_id,
    event_timestamp,
    event_bundle_sequence_id,
    COUNT(ep.key) AS param_count
  FROM `mon_projet.mon_dataset.events_*`,
  UNNEST(event_params) AS ep
  GROUP BY
    event_name,
    user_pseudo_id,
    event_timestamp,
    event_bundle_sequence_id
)

SELECT
  event_name,
  COUNT(*) AS event_count,
  AVG(param_count) AS avg_params,
  MAX(param_count) AS max_params
FROM event_rows
GROUP BY event_name
ORDER BY max_params DESC;

GA4 est-il vraiment conforme au RGPD ?

Je préfère être clair tout de suite : GA4 n’est pas automatiquement conforme au RGPD. Ce n’est pas parce que vous avez coché deux options dans l’interface que le sujet est réglé. La conformité dépend de votre configuration, du consentement, des transferts de données, des contrats, de votre gouvernance interne et du contexte légal dans lequel vous opérez.

Le point sensible, c’est surtout le transfert de données vers les États-Unis. En 2020, la Cour de justice de l’Union européenne a invalidé le Privacy Shield avec l’arrêt Schrems II. Ça a fragilisé une partie des transferts de données personnelles hors UE. Ensuite, plusieurs autorités européennes, dont la CNIL en France en 2022, ont considéré que certaines configurations de Google Analytics exposaient à des transferts insuffisamment encadrés.

Depuis, le Data Privacy Framework UE États-Unis a été adopté en 2023. C’est un cadre juridique qui vise à sécuriser certains transferts. Mais ça ne veut pas dire que tout devient magique. Chaque entreprise doit quand même vérifier sa base légale, ses paramètres, ses contrats, et les recommandations à jour de son DPO, le délégué à la protection des données, ou de son conseil juridique.

Découvrez égalementComment créer un tableau de bord Google Analytics ?

Dans GA4, certains réglages aident vraiment. Le Consent Mode, la désactivation des signaux Google selon les cas, la durée de conservation des données, le contrôle des données publicitaires, le filtrage du trafic interne, la limitation des identifiants envoyés, l’anonymisation ou plutôt la non collecte de certaines données identifiantes. Parfois, un proxy ou un tracking server-side peut aussi avoir du sens. Mais seul, aucun de ces réglages ne suffit.

Et surtout, GA4 ne doit jamais recevoir d’email, de numéro de téléphone ou de donnée personnelle directement identifiable en clair. J’ai vu des projets où le vrai problème n’était pas GA4. C’était le dataLayer, cette couche de données envoyée par le site aux outils marketing, qui transmettait des infos client beaucoup trop précises. Le risque commence souvent avant même que la donnée arrive chez Google.

• Vérifiez votre CMP, la plateforme qui collecte le consentement utilisateur.
• Contrôlez que GA4 ne se déclenche pas avant consentement si votre base légale l’exige.
• Relisez votre plan de taggage et les événements envoyés.
• Appliquez la minimisation des données, donc uniquement ce qui est nécessaire.
• Documentez les finalités, les paramètres et les choix techniques.
• Testez les tags avec et sans consentement.
• Mettez à jour le registre de traitement RGPD.
• Faites valider l’implémentation par le DPO ou le juridique.
• Prévoyez une vraie recette technique avant mise en production.

La bonne question n’est pas seulement : Est-ce que GA4 est légal ? La vraie question, c’est : Est-ce que votre implémentation GA4 est défendable, documentée et proportionnée ?

Comment limiter les dégâts avec GA4 ?

On limite les dégâts avec GA4 en arrêtant de l’utiliser comme une boîte noire. Je le traite comme une brique de mesure, pas comme toute la stack data. GA4 reste utile pour comprendre les parcours, piloter certains canaux, alimenter Google Ads et suivre les événements clés. Mais il doit être cadré, sinon on finit avec des rapports jolis, et des décisions bancales.

La méthode est simple. Je commence toujours par les décisions à prendre avec les données. Est-ce qu’on veut arbitrer un budget média ? Identifier les pages qui convertissent ? Mesurer les leads qualifiés ? Une fois que c’est clair, je définis seulement les événements nécessaires. Pas cinquante événements “au cas où”. Ça, je l’ai vu chez un client e-commerce, ils avaient 120 events, personne ne savait lesquels utiliser.

• Clarifier les décisions business à prendre.
• Définir les événements vraiment utiles.
• Documenter chaque événement, ses paramètres, sa source, son déclencheur, le niveau de consentement et son usage.
• Tester dans DebugView, Tag Assistant, BigQuery et les rapports GA4.
• Partager un plan de marquage lisible par le marketing, la data et les développeurs.

Pour les noms d’événements, je reste proche des événements recommandés par GA4 quand c’est possible : view_item, add_to_cart, generate_lead, sign_up, purchase. Inventer des noms exotiques comme clic_bouton_super_panier ou lead_form_v2_final complique les rapports, les audiences, les conversions et les intégrations avec Google Ads.

// Ne jamais envoyer de donnée personnelle dans le dataLayer.
window.dataLayer = window.dataLayer || [];

window.dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "EUR",
    items: [
      {
        item_id: "SKU-12345",
        item_name: "Chaussures running homme",
        item_category: "Chaussures",
        price: 89.90,
        quantity: 1
      }
    ]
  }
});

Cet exemple doit ensuite être mappé dans GTM vers une balise GA4 Event. GTM, c’est Google Tag Manager, l’outil qui déclenche les tags sans modifier le code du site à chaque fois.

BigQuery change aussi beaucoup de choses. L’export natif GA4 permet de reprendre la main sur l’analyse brute, vérifier les écarts, créer des modèles métiers et éviter de dépendre seulement de l’interface GA4. Ça ne corrige pas tout, notamment les sujets de consentement ou de qualité de tracking. Mais ça donne un vrai niveau de contrôle, et franchement, c’est souvent là que GA4 redevient exploitable.

Quand faut-il compléter GA4 par autre chose ?

Je complète GA4 dès que l’entreprise a besoin d’un historique solide, d’une conformité mieux maîtrisée, d’analyses avancées, de données non échantillonnées selon les usages, ou d’un pilotage business qui dépasse les rapports marketing. GA4 reste utile, vraiment. Mais seul, il devient vite court dès qu’on veut faire de l’analytics engineering sérieux, avec des définitions stables, des KPI auditables et des données qu’on peut recroiser proprement.

Dans la vraie vie, je garde souvent GA4 pour ce qu’il fait bien : lecture rapide, exploration, activation média, audiences, suivi des campagnes. Puis je le complète avec quelques briques simples, pas une usine à gaz.

• Un data warehouse comme BigQuery pour centraliser les données, garder l’historique et croiser GA4 avec le CRM, les ventes, les marges ou les coûts média.
• Une couche SQL avec dbt ou des vues contrôlées pour fiabiliser les indicateurs. Dbt sert à transformer les données avec du SQL versionné, testé et documenté.
• Looker Studio ou un outil BI plus robuste pour construire des dashboards lisibles, avec les bonnes définitions métier.
• Un tracking server-side pour mieux contrôler les flux, les consentements, les enrichissements autorisés et la qualité de collecte.
• Une CMP bien configurée pour gérer le consentement. CMP veut dire Consent Management Platform, c’est l’outil qui affiche et transmet les choix utilisateur.
• Une solution analytics plus orientée privacy si le contexte juridique, sectoriel ou interne l’impose.

Attention, le server-side n’est pas magique. Et ce n’est pas automatiquement conforme. Ça permet de mieux contrôler ce qui part vers Google, Meta ou d’autres plateformes, de filtrer, normaliser, enrichir prudemment et réduire certaines pertes techniques. Mais si c’est mal conçu, on déplace juste le problème ailleurs.

Sur un site e-commerce avec beaucoup de campagnes et des parcours assez longs, on a gardé GA4 pour l’activation média et les analyses rapides. Mais les KPI fiables, chiffre d’affaires, commandes, nouveaux clients, marge, taux de conversion, ont été reconstruits dans BigQuery. Les réunions sont devenues beaucoup plus simples. Tout le monde regardait les mêmes définitions, au lieu de débattre pendant 30 minutes sur deux chiffres différents.

Alors, comment utiliser GA4 sans se raconter d’histoires ?

GA4 reste utile, mais il ne faut pas lui demander ce qu’il ne sait pas faire. Il ne reprend pas l’historique UA, il impose des limites de collecte, et sa conformité RGPD dépend beaucoup de votre implémentation. Mon conseil est simple. Gardez GA4 pour ce qu’il fait bien, documentez votre tracking, limitez les données envoyées, testez vraiment vos événements, puis complétez avec BigQuery, du server-side ou une couche BI quand le business l’exige. Vous gagnez surtout une mesure plus propre, plus défendable, et plus utile pour décider sans passer vos journées à expliquer des écarts incompréhensibles.

FAQ

• GA4 peut-il importer mes anciennes données Universal Analytics ?
  Non, GA4 ne permet pas d’importer l’historique Universal Analytics. Le modèle de données est différent. Le mieux est d’archiver les anciennes données UA disponibles dans un entrepôt de données, des exports ou des rapports figés, puis de reconstruire une nouvelle base d’analyse dans GA4.
• Pourquoi mes chiffres GA4 ne correspondent pas à Universal Analytics ?
  Parce que GA4 ne mesure pas exactement comme UA. Les sessions, les événements, les conversions, l’attribution et certains traitements de données ont changé. Chercher une correspondance parfaite fait perdre du temps. Il vaut mieux documenter les écarts et repartir sur des définitions propres.
• La limite de 25 paramètres par événement GA4 est-elle bloquante ?
  Elle peut l’être pour les gros sites ou les plans de taggage trop chargés. Ça force à prioriser. Je garde les paramètres utiles à l’analyse ou à l’activation, j’évite les attributs décoratifs, et je contrôle régulièrement la collecte dans BigQuery quand l’export est activé.
• GA4 est-il conforme au RGPD par défaut ?
  Non, pas par défaut. La conformité dépend de votre consentement, de votre configuration, des données envoyées, des transferts, de la documentation et de vos choix internes. Il faut impliquer le DPO ou un conseil juridique, surtout si vous traitez des données sensibles ou des volumes importants.
• Faut-il remplacer GA4 par une autre solution analytics ?
  Pas forcément. GA4 peut rester utile pour le marketing, Google Ads et l’analyse des parcours. Mais pour l’historique, la qualité data, le reporting business ou certains enjeux privacy, je recommande souvent de le compléter avec BigQuery, du tracking server-side et une vraie couche de gouvernance.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’analytics engineering, GA4, l’automatisation no low code avec n8n, l’IA appliquée au business et le SEO GEO. J’ai travaillé pour des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser votre mesure GA4, cadrer votre collecte ou mettre en place une stack data plus propre, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.