Quand l'échantillonnage des données commence et comment le repérer dans un rapport

Qu'est-ce que l'échantillonnage des données en analytics ?

Dans un rapport analytique, l'échantillonnage des données signifie que les chiffres que vous lisez ont été calculés à partir d'un sous-ensemble de vos événements puis extrapolés, plutôt que comptés sur chaque événement collecté. La plateforme prélève une portion des données disponibles, exécute la requête sur cette portion, puis remultiplie le résultat pour estimer le chiffre complet. Rien n'est supprimé. Les événements bruts sont toujours là. Ce qui a changé, c'est que le rapport devant vous est une estimation présentée dans la même typographie qu'un décompte.

Cette distinction compte surtout dans les queues de distribution. Une métrique de tête comme le total des sessions survit bien à l'échantillonnage, parce que l'estimation repose sur une large base. Un segment qui pèse 0.3% du trafic, une landing page de longue traîne ou un parcours de conversion à quatre étapes peuvent varier fortement, parce que l'échantillon ne contient parfois qu'une poignée des événements concernés. C'est une défaillance différente de celle décrite dans la façon dont GA4 retient des lignes pour protéger l'identité, où les lignes sont retirées entièrement plutôt qu'estimées.

Quand Google Analytics 4 applique-t-il l'échantillonnage ?

Google documente un déclencheur précis : l'échantillonnage survient "when the number of events used to create a report, exploration, or request exceeds the quota limit for your property." Le quota dépend du niveau de la propriété.

Surface	Propriété standard	Analytics 360
Événements lus par requête par défaut	10 millions	100 millions
Limite maximale disponible	10 millions	1 milliard, via "More detailed results" dans Explore
Explorations non échantillonnées	Non disponible	Disponible, et seulement si une requête renverrait plus de 1 milliard d'événements

Un quota de 10 millions d'événements n'échantillonne pas la plupart des rapports, parce que GA4 ne répond pas à la plupart des requêtes depuis les données au niveau événement. Google décrit deux groupes de tables : "One group of tables aggregates your data to provide fast, unsampled results to the most common requests. The other group of tables stores more granular event and user-level data to provide the flexibility for one-off, advanced investigations." Les rapports standard avec des dimensions standard tapent dans les tables agrégées et reviennent non échantillonnés quel que soit le volume de trafic. L'échantillonnage apparaît quand une requête ne peut pas être servie depuis les tables pré-agrégées : une plage de dates personnalisée, une comparaison, un segment ad hoc, un appariement de dimensions inhabituel, la plus grande partie d'Explore.

Voilà pourquoi deux personnes sur la même propriété peuvent être en désaccord sur le fait que GA4 échantillonne. L'une vit dans les rapports standard et ne l'a jamais vu. L'autre construit des explorations et le voit chaque semaine.

Comment distinguer un rapport échantillonné d'un rapport non échantillonné ?

Regardez l'icône de qualité des données en haut du rapport ou de l'exploration. Google indique que "when your results use sampling, it is indicated in the data quality icon with the percentage of data used to create the results." Ce pourcentage est tout le signal. Un rapport construit à partir de 4% des événements et un autre construit à partir de 96% se ressemblent trait pour trait en dehors de ce chiffre, et méritent des niveaux de confiance très différents.

Dans la Data API, la même information arrive sous forme de champs structurés. ResponseMetaData porte un tableau samplingMetadatas, et Google est précis sur le moment où il apparaît : "If this report results is sampled, this describes the percentage of events used in this report. One samplingMetadatas is populated for each date range. However if the results are not sampled, this field will not be defined." Chaque entrée contient deux chaînes int64 :

• samplesReadCount, "the total number of events read in this sampled report for a date range"
• samplingSpaceSize, "the total number of events present in this property's data that could have been analyzed in this report for a date range"

Divisez la première par la seconde et vous obtenez le pourcentage qu'afficherait l'icône. Pour un pipeline de reporting, le détail qui compte est que l'absence de samplingMetadatas correspond au cas non échantillonné : un code qui vérifie seulement un pourcentage faible traitera donc chaque réponse propre comme suspecte.

En quoi Standard et Analytics 360 diffèrent-ils sur l'échantillonnage ?

La différence tient à la taille de la requête que 360 peut se permettre d'exécuter, pas à une méthode différente. Les deux niveaux échantillonnent de la même façon quand ils échantillonnent. Analytics 360 part de 100 millions d'événements par requête au lieu de 10 millions, et ajoute deux portes de sortie.

La première est un commutateur à l'intérieur d'Explore. Le réglage par défaut est "Faster results", et choisir "More detailed results" porte la taille de l'échantillon vers 1 milliard d'événements, ce qui suffit selon Google à produire des résultats non échantillonnés dans la plupart des cas. Il y a ici une arête vive qui prend les gens en pleine analyse : "Any change you make that requires the query to run again will revert back to the default Faster results option." Changez une date, ajoutez un segment, permutez une dimension, et vous voilà revenu au petit échantillon sans qu'aucune boîte de dialogue ne vous le dise.

La seconde est la demande d'exploration non échantillonnée, qui exécute la requête hors ligne et vous envoie un e-mail quand elle est prête. Les contraintes documentées par Google sont d'une précision inhabituelle :

Contrainte	Valeur documentée
Éligibilité	Seulement si la requête renverrait plus de 1 milliard d'événements
Quota quotidien de jetons	20 000 jetons par propriété, partagés entre tous les utilisateurs et toutes les requêtes API
Plafond de coût par requête	5 000 jetons
Réinitialisation du quota	Minuit, heure du Pacifique
Temps de traitement habituel	Moins de 30 minutes
Durée de vie du résultat	50 jours après la demande
Taille d'export	Jusqu'à 10 000 000 de cellules pour TSV et CSV
Autorisation requise	Analyst ou supérieur
Technique non prise en charge	Durée de vie utilisateur

La règle d'éligibilité est celle qui surprend les équipes. Une exploration non échantillonnée n'est pas un bouton général "donnez-moi les chiffres exacts" ; elle n'existe qu'au-delà du point où le plafond de 1 milliard d'événements propre à 360 a déjà été dépassé.

Le chemin d'escalade pour sortir de l'échantillonnage dans Analytics 360

La requête dépasse le quota de 100 millions d'événements

Uniquement Résultats plus rapides (échantillon par défaut)

Passage à Résultats plus détaillés (jusqu'à 1 milliard d'événements)

Tout changement revient à Résultats plus rapides

Demande d'exploration non échantillonnée (seulement au-delà d'1 milliard d'événements)

Que font Adobe et Matomo à la place ?

Ils règlent le même problème de performance avec un compromis différent, et cela se voit à un autre endroit de vos rapports.

Adobe Analytics ne documente aucun mécanisme d'échantillonnage au moment du rapport pour Analysis Workspace, et n'offre aucun équivalent du pourcentage de qualité des données de GA4. Ce qu'Adobe plafonne, c'est la cardinalité plutôt que le nombre de lignes lues. Un seuil de 2 000 000 de valeurs uniques est fixé par dimension, par report suite et par mois calendaire. Les valeurs de dimension collectées après le franchissement de ce seuil sont regroupées dans un élément unique étiqueté "Low-Traffic", avec un second seuil, plus agressif, fixé par défaut à 2 100 000 valeurs uniques. Le compteur se remet à zéro globalement à la fin de chaque mois calendaire.

La version d'Adobe est invisible de la même manière que l'échantillonnage, mais elle déforme un autre axe. Vos totaux restent corrects. Vos ventilations par dimension cessent d'être complètes en cours de mois, et Adobe prévient que la dimension Page est particulièrement exposée, parce que plusieurs colonnes de backend comptent toutes dans le même seuil : Low-Traffic peut donc s'appliquer bien avant que le nombre de pages visible n'approche les 2 millions.

Matomo prend la position inverse et le dit directement : Matomo n'échantillonne pas les données, et sa documentation sur la qualité des données liste "No data sampling" comme une propriété de la plateforme. Les rapports sont traités à partir de toutes les données suivies. Cette affirmation est sincère, mais elle ne revient pas à dire que les rapports Matomo sont intégraux, et Matomo documente lui-même l'autre moitié : pour garder l'archivage rapide, il stocke par défaut un nombre limité de lignes par rapport, grosso modo les 500 premières pages et les 1 000 premiers mots-clés et sites web, et additionne tout le reste dans une ligne "Others". Les installations sur site peuvent relever le plafond avec des réglages [General] dans config/config.ini.php tels que datatable_archiving_maximum_rows_actions et datatable_archiving_maximum_rows_referrers, au prix documenté d'une perte de performance à l'archivage.

Plateforme	Ce qu'elle limite	Où la perte se voit
Google Analytics 4	Événements lus par requête	Chaque métrique du rapport, sous forme d'estimation
Adobe Analytics	Valeurs de dimension uniques par mois	Une seule ligne "Low-Traffic" qui absorbe la longue traîne
Matomo	Lignes archivées par rapport	Une seule ligne "Others" qui absorbe la longue traîne

Lisez ce tableau comme trois réponses à une même question. GA4 conserve chaque valeur de dimension et approxime les métriques. Adobe et Matomo gardent les métriques exactes et écrasent les valeurs de dimension. Si votre travail vit dans les totaux et les tendances, l'échange proposé par GA4 est le moins cher ; s'il vit dans les ventilations de longue traîne, c'est le plus cher, et c'est l'une des raisons structurelles derrière le fait que deux outils rapportent des chiffres différents pour la même semaine.

Comment contourner l'échantillonnage sans passer à la version supérieure ?

Réduisez la requête avant de douter de la réponse, puisque l'échantillonnage dépend du nombre d'événements qu'une requête doit lire.

• Découpez une longue plage de dates en plusieurs requêtes plus courtes ; le quota s'applique par requête et par plage de dates.
• Préférez les rapports standard pour tout ce qu'un rapport standard sait traiter, parce qu'ils viennent des tables agrégées.
• Déplacez un segment récurrent dans une audience ou une dimension personnalisée pour que le filtrage se fasse au moment de la collecte.
• Interrogez les événements bruts dans BigQuery, ce qui contourne entièrement le quota de reporting et constitue la plus fiable des voies décrites dans comment sortir vos données de Google Analytics.

L'habitude à prendre est de regarder l'icône d'abord et la métrique ensuite, parce qu'un chiffre lu sur 3% des événements a exactement l'air aussi solide qu'un chiffre lu sur la totalité. Cette habitude attrape aussi le problème voisin des événements qui n'ont jamais atteint la propriété, que l'échantillonnage n'explique pas et ne répare pas.

Questions fréquentes

Quel est le seuil exact d'événements pour l'échantillonnage dans GA4 ?

Google documente 10 millions d'événements par requête pour les propriétés standard et 100 millions pour les propriétés Analytics 360 comme réglages d'échantillonnage par défaut. Analytics 360 peut porter une exploration unique à 1 milliard d'événements en sélectionnant "More detailed results". Sous ces limites, une requête renvoie des résultats non échantillonnés ; au-dessus, un échantillon est lu et le résultat est extrapolé.

L'échantillonnage veut-il dire que Google a jeté mes données ?

Non. Les événements restent dans la propriété et dans l'export BigQuery si vous en avez configuré un. L'échantillonnage est une décision prise au moment de la requête sur le nombre d'événements à lire dans le quota, pas une décision de collecte ou de stockage. Poser la même question sur une plage de dates plus courte, ou contre BigQuery, peut renvoyer une réponse exacte à partir des mêmes données.

Pourquoi mon exploration redevient-elle échantillonnée après un changement de filtre ?

Parce qu'Analytics 360 réinitialise le réglage de taille d'échantillon chaque fois que la requête doit être relancée. Google indique que "any change you make that requires the query to run again will revert back to the default Faster results option." Resélectionnez "More detailed results" après chaque changement, et vérifiez l'icône de qualité des données au lieu de supposer que le réglage a tenu.

Puis-je détecter l'échantillonnage depuis la Google Analytics Data API ?

Oui, via le tableau samplingMetadatas sur ResponseMetaData. Il est rempli une fois par plage de dates quand le résultat est échantillonné, et n'est pas défini du tout quand le résultat ne l'est pas. Chaque entrée donne samplesReadCount et samplingSpaceSize sous forme de chaînes int64, et leur rapport donne le pourcentage d'événements lus.

Adobe Analytics échantillonne-t-il les données comme GA4 ?

La documentation d'Adobe sur Analysis Workspace ne décrit aucun contrôle d'échantillonnage au moment du rapport et n'offre aucun pourcentage de taille d'échantillon dans l'interface. La limite qu'Adobe documente porte sur la cardinalité des dimensions : au-delà de 2 000 000 de valeurs uniques par dimension, par report suite et par mois calendaire, les nouveaux éléments sont regroupés sous une étiquette "Low-Traffic", le compteur se réinitialisant à la fin de chaque mois.

Si Matomo n'échantillonne pas, pourquoi mes totaux Matomo diffèrent-ils d'un décompte complet des logs ?

Parce que Matomo limite les lignes archivées par rapport plutôt que les événements lus. Matomo traite toutes les données suivies et affirme ne pas échantillonner, mais il n'archive par défaut que les quelques centaines de premières lignes de nombreux rapports et additionne le reste dans une ligne "Others". Une installation auto-hébergée peut relever ce plafond via les réglages datatable_archiving_maximum_rows_* dans config/config.ini.php, ce qui peut affecter sensiblement la performance d'archivage, comme Matomo le note.

L'échantillonnage de GA4 affecte-t-il toutes les métriques d'un rapport de la même façon ?

L'échantillonnage ne se répartit pas de façon égale dans un rapport. Une métrique phare comme le total des sessions le supporte bien, car l'estimation s'appuie sur une base large, tandis qu'un segment représentant 0,3 % du trafic, une page de destination de longue traîne ou un tunnel de conversion à quatre étapes peut varier fortement, parce que l'échantillon ne contient parfois qu'une poignée des événements concernés. Le rapport affiche les deux chiffres dans la même police, donc rien à l'écran n'indique lequel des deux est le plus fragile.

Les rapports standards de GA4 sont-ils parfois échantillonnés ?

Rarement, parce que la plupart des rapports standards sont servis par les tables agrégées que Google a construites pour donner des résultats rapides et non échantillonnés aux requêtes courantes. L'échantillonnage apparaît quand une requête ne peut pas être servie par ces tables, comme une plage de dates personnalisée, une comparaison, un segment ad hoc, une combinaison de dimensions inhabituelle ou la plupart des explorations. Cette différence explique pourquoi deux personnes sur la même propriété peuvent ne pas être d'accord sur le fait que GA4 échantillonne : l'une vit dans les rapports standards et ne le voit jamais, l'autre construit des explorations et le voit chaque semaine.

Combien de temps les résultats d'une exploration non échantillonnée restent-ils disponibles dans Analytics 360 après la demande ?

Google documente une durée de vie du résultat de 50 jours après la demande, avec un temps de traitement habituel de moins de 30 minutes. L'export peut contenir jusqu'à 10 000 000 de cellules pour les formats TSV et CSV, et la demande n'est éligible que lorsque la requête retournerait plus d'1 milliard d'événements.

Le seuil Low-Traffic d'Adobe s'applique-t-il de façon uniforme à toutes les dimensions ?

Le seuil ne se répartit pas de façon uniforme. Il est fixé à 2 000 000 de valeurs uniques par dimension, par report suite et par mois calendaire, mais Adobe prévient que la dimension Page est particulièrement exposée parce que plusieurs colonnes du backend comptent pour la même limite. Cela veut dire que Low-Traffic peut s'appliquer bien avant que le nombre de pages visible n'approche les 2 millions, avec un second seuil plus agressif fixé par défaut à 2 100 000.