Comment Google Analytics stocke et affiche les données ?

Google Analytics stocke les données dans deux familles de tables : des tables agrégées pour la performance et des tables granulaires pour l’analyse fine. Cet article explique ces choix, les limites (échantillonnage, ligne (other)) et les solutions pour obtenir des résultats non échantillonnés.

Comment Google Analytics organise les données

Voici comment Google Analytics organise ses données pour concilier rapidité des rapports et précision analytique.

Les données sont réparties en deux familles principales : tables agrégées optimisées pour des requêtes rapides et tables granulaires contenant les événements au niveau utilisateur.

• Tables agrégées : Ces tables regroupent et pré-calculent des métriques (sessions, utilisateurs, conversions) par dimensions courantes (page, source, date). Elles sont conçues pour des réponses rapides dans l’interface et pour éviter l’échantillonnage dans les rapports standards. Source : Google Analytics Help – traitement et rapports.
• Tables granulaires : Ces tables conservent chaque événement individuel avec horodatage, identifiants utilisateur et paramètres. Elles servent aux analyses fines, aux segments complexes et aux explorations personnalisées.

Les tables agrégées sont utilisées quand la requête correspond à des dimensions et métriques pré-calculées, car le système peut retourner des résultats en quelques centaines de millisecondes et sans échantillonnage. La pré-agrégation réduit la charge CPU et le coût de lecture des données.

Le basculement vers les tables granulaires se produit quand la requête nécessite des jointures fines, des segments multi-événements ou des dimensions non pré-agrégées. Dans ces cas, l’utilisation des événements bruts garantit précision et flexibilité, au prix d’un coût de calcul et d’un temps de réponse plus élevés.

Schéma verbal du flux : L’événement côté client (clic, page_view) arrive au serveur, passe par une étape de traitement et enrichissement, puis alimente simultanément des pipelines qui mettent à jour des tables agrégées (pour UI) et stockent l’événement brut dans les tables granulaires (pour analyses approfondies).

Exemples concrets :

• Rapport standard : Utilise les tables agrégées pour afficher rapidement sessions par source sans échantillonnage.
• Exploration personnalisée : Utilise les tables granulaires pour reconstruire les parcours multi-événements ou appliquer des filtres complexes.

Quelles sont les limites de données

Google Analytics applique des limites qui déclenchent de l’agrégation, de l’échantillonnage ou la création d’une ligne « (other) » lorsque les volumes ou la cardinalité dépassent des seuils. Ces mécanismes visent à garantir des temps de réponse raisonnables, mais ils altèrent la précision des rapports. Les valeurs de référence proviennent de la documentation Google Analytics.

• Limites d’échantillonnage documentées : Les propriétés standard déclenchent l’échantillonnage autour de 10 millions d’événements (valeur de référence).
• Limites pour Analytics 360 : Les propriétés payantes (Analytics 360) ont des paliers plus élevés, typiquement autour de 100 millions d’événements (valeur de référence).
• Création de la ligne « (other) » : Lorsque la table de dimension atteint un nombre maximal de lignes affichables, les valeurs rares sont regroupées en « (other) », ce qui masque la longue traîne des valeurs.

L’impact sur le choix de la table et l’exactitude des rapports se lit ainsi : si la requête dépasse le seuil, l’interface utilisera une table agrégée ou un échantillon plutôt que les données brutes. Les totaux globaux restent souvent proches, mais les segments et petites dimensions deviennent peu fiables. Pour les analyses fines (ex : funnel par segment unique), il faut éviter l’échantillonnage ou exporter les données brutes vers BigQuery lorsque disponible.

L’icône de qualité des données signale qu’une estimation est utilisée. Un message ou une icône dans l’interface indique que les résultats sont approximatifs, invitant à restreindre la plage temporelle, affiner le filtre ou exporter pour garantir l’exactitude.

Exemple chiffré : Une requête sur 30 jours totalisant 200 M d’événements sur une propriété standard (seuil ~10 M) peut n’utiliser qu’une fraction (ex. 10 M) comme base d’échantillon → taux d’échantillonnage ~5%. Cela donne des totaux agrégés ajustés mais accroît fortement la variance des petits segments.

Pourquoi apparaît la ligne (other)

La ligne (other) apparaît quand la table de reporting dépasse son seuil de lignes et que Google Analytics regroupe les valeurs de dimension les moins fréquentes en une seule entrée.

Le mécanisme exact consiste à conserver les valeurs de dimension les plus fréquentes (top N) puis à agréger le reste sous (other). La « dimension » désigne un attribut descriptif (par exemple Page, Source/Support, Pays). Le but est d’assurer des temps de rendu et une utilisation mémoire maîtrisés côté interface en évitant d’afficher des millions de lignes peu pertinentes.

• Pages : Quand un site a des milliers de pages à faible trafic (variantes de produit, paramètres d’URL), Google conserve les pages les plus vues et regroupe le reste en (other).
• Sources de trafic : Quand des campagnes UTM mal standardisées produisent des centaines de valeurs uniques, les sources les moins fréquentes finissent dans (other).
• Pays : Cas rare mais possible sur des propriétés internationales avec beaucoup d’îles/territoires à très faible trafic, on observe aussi (other).

Conséquence pour l’interprétation : Les mesures agrégées (taux de conversion, revenus, pages vues) peuvent être sous-estimées pour la longue traîne. Les analyses de priorisation deviennent biaisées puisque le top N reflète uniquement la masse la plus fréquente, alors que des signaux significatifs peuvent être noyés dans (other).

• Réduire la plage de dates : Permet de diminuer le nombre de valeurs uniques et parfois de faire disparaître (other).
• Appliquer un filtre ou segment : Filtrer sur un sous-ensemble (par exemple un chemin /section) pour exposer les valeurs masquées.
• Comparer avec l’export BigQuery : L’export (disponible pour GA4 et GA360) fournit les lignes brutes sans agrégation UI, ce qui permet de vérifier exactement quelles valeurs ont été regroupées.

Comment fonctionne l’échantillonnage

Voici comment l’échantillonnage fonctionne dans Google Analytics et quelles conséquences il peut avoir sur vos rapports.

Le principe statistique consiste à analyser un sous-ensemble représentatif des sessions ou événements pour estimer des métriques sur l’ensemble. Cette technique repose sur l’échantillonnage aléatoire : on sélectionne des sessions de manière pseudo‑aléatoire, on calcule les métriques sur cet échantillon, puis on les extrapole (on multiplie ou on pondère) pour obtenir une estimation sur la population totale. Cette méthode fournit un estimateur non biaisé en moyenne, mais avec une incertitude (erreur‑type) liée à la taille de l’échantillon.

Google déclenche l’échantillonnage pour préserver la performance et la réactivité des rapports quand le volume de données est trop élevé pour un traitement interactif. Cette règle dépend de l’offre et du type de rapport : pour Universal Analytics, le seuil communément documenté est de 500 000 sessions pour les comptes standards, et il est beaucoup plus élevé pour les comptes payants (Analytics 360). Source : Google Analytics Help — About data sampling.

Le choix de l’échantillon se fait généralement sur des sessions (définition : séquence d’interactions d’un utilisateur sur le site pendant une période donnée), avec sélection pseudo‑aléatoire et mise à l’échelle des résultats. Les métriques globales fréquentes (visites, pages vues) gardent une bonne stabilité, alors que les métriques rares (un événement très spécifique, une conversion peu fréquente) subissent une forte variabilité relative.

Par exemple, sur 1 000 000 de sessions, si Analytics échantillonne 10 % (100 000), un événement rare apparaissant 0,1 % du temps (1 000 occurrences réelles) donnera environ 100 occurrences dans l’échantillon. Après extrapolation l’estimation moyenne revient à 1 000, mais l’erreur‑type sur l’estimation est d’environ 10 % (soit ±100 occurrences, 1 sigma), ce qui altère la confiance sur les comparaisons.

Dans l’interface, Google affiche le taux d’échantillonnage en haut du rapport et signale l’usage d’un échantillon par un avertissement visuel. Via les API, des champs renvoient la taille de l’échantillon et l’espace d’échantillonnage pour permettre une validation automatisée.

Comment contourner les limites et l’échantillonnage

Pour limiter l’impact de l’échantillonnage dans Google Analytics, plusieurs options existent selon que vous disposiez ou non d’Analytics 360. L’échantillonnage survient lorsque Google utilise un sous-ensemble de sessions pour estimer des métriques, ce qui peut fausser des analyses fines.

• Analytics 360 — Requêtes non échantillonnées. Cette option permet d’obtenir des rapports complets sans échantillonnage pour des plages et volumes plus importants. Elle convient lorsque chaque session compte pour la décision.
• Analytics 360 — Expanded data / données étendues. Fournit des dimensions et métriques plus détaillées et des seuils supérieurs avant déclenchement de l’échantillonnage. Utile pour des analyses segmentées (pays, device, campagne).
• Analytics 360 — Unsampled Reporting API. Permet de générer des exports non échantillonnés (rapports téléchargeables). Pratique pour automatiser et archiver des extractions exactes.

Export vers BigQuery. Exporter les hits/événements bruts vers BigQuery donne accès aux données granulaires non échantillonnées (BigQuery est l’entrepôt cloud de Google). Cela permet d’écrire des requêtes SQL, d’agréger comme on veut et d’intégrer d’autres sources. Exemple simple pour compter les événements par jour :

SELECT event_date, COUNT(1) AS events
FROM `dataset.events_*`
GROUP BY event_date
ORDER BY event_date DESC
LIMIT 10

Solutions pour utilisateurs non 360. Réduire la plage de dates pour éviter le seuil d’échantillonnage. Segmenter les requêtes (par pays, device, campagne) et recomposer les résultats hors-ligne. Exporter des échantillons stables via l’API Reporting et vérifier la variance statistique. Envisager l’upgrade vers 360 si la précision est critique.

Checklist opérationnelle avant analyse.

• Vérifier le pourcentage d’échantillonnage indiqué dans l’interface.
• Limiter la plage temporelle ou fractionner la requête par segments.
• Utiliser des filtres/segments précis pour réduire le volume traité.
• Exporter en unsampled (360) ou vers BigQuery si disponible.
• Comparer résultats agrégés vs échantillonnés pour mesurer l’écart.

Prêt à exploiter vos données Google Analytics sans approximations ?

Google Analytics combine tables agrégées et tables granulaires pour arbitrer performance et précision. Les limites (seuils d’événements, ligne (other), échantillonnage) existent pour garantir la réactivité, mais elles biaisent parfois les analyses. Pour obtenir des données non échantillonnées : Analytics 360 offre des options élargies, l’export BigQuery permet des requêtes SQL sur les événements bruts, et des pratiques simples (réduire la plage, segmenter) réduisent l’impact. En appliquant ces leviers, vous augmentez la fiabilité de vos décisions basées sur les données et gagnez en confiance opérationnelle.

FAQ

• Pourquoi la ligne (other) apparaît-elle dans mes rapports ?
  La ligne (other) regroupe les valeurs de dimension peu fréquentes quand le nombre de lignes dépasse la limite de la table utilisée. Google conserve d’abord les valeurs les plus communes et regroupe le reste sous (other), ce qui réduit le nombre de lignes à afficher et protège la performance.
• Qu’est-ce que l’échantillonnage et quand intervient-il ?
  L’échantillonnage analyse un sous-ensemble des événements pour accélérer les requêtes sur de gros volumes. Il intervient lorsque la requête dépasse les seuils internes de traitement, afin de fournir une estimation plus rapide au détriment d’une précision totale.
• Quels sont les seuils d’événements à connaître ?
  Parmi les repères documentés, les propriétés standard atteignent des limites autour de 10 millions d’événements pour certaines opérations ; Analytics 360 relève ces seuils (ordre de grandeur 100 millions) et propose des options pour obtenir des résultats plus détaillés ou non échantillonnés.
• Comment obtenir des rapports non échantillonnés ?
  Solutions : utiliser les fonctionnalités Analytics 360 (expanded data, more detailed results), exporter les données brutes vers BigQuery pour requêtes SQL non échantillonnées, ou réduire/segmenter la plage de dates pour rester sous les seuils.
• Est-ce nécessaire de passer à Analytics 360 ?
  Pas toujours. Pour des besoins d’analyse intensifs et des volumes très élevés, Analytics 360 simplifie l’accès à des résultats non échantillonnés. Pour d’autres cas, l’export BigQuery ou des pratiques opérationnelles (réduction de plage, segmentation) peuvent suffire.

A propos de l’auteur

Je m’appelle Franck Scandolera. J’accompagne et forme les entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation no/low-code (n8n) et l’intégration de l’IA. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics, j’ai travaillé pour Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐

• 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.