Cuándo empieza el muestreo de datos y cómo detectarlo en un informe

¿Qué es el muestreo de datos en analítica?

En un informe de analítica, el muestreo de datos significa que los números que estás leyendo se calcularon a partir de un subconjunto de tus eventos y luego se escalaron, en lugar de contarse sobre cada evento que recogiste. La plataforma toma una porción de los datos disponibles, ejecuta la consulta contra esa porción y multiplica el resultado de vuelta para estimar la cifra completa. No se borra nada. Los eventos en bruto siguen ahí. Lo que cambió es que el informe que tienes delante es una estimación presentada con la misma tipografía que un recuento.

Esa distinción importa sobre todo en las colas. Una métrica de titular como el total de sesiones aguanta bien el muestreo, porque la estimación tiene una base grande. Un segmento que vale el 0,3% del tráfico, una página de destino de cola larga o una ruta de conversión de cuatro pasos pueden oscilar muchísimo, porque la muestra quizá contenga solo un puñado de los eventos relevantes. Este fallo es distinto del de cómo GA4 retiene filas para proteger la identidad, donde las filas se eliminan del todo en lugar de estimarse.

¿Cuándo aplica muestreo Google Analytics 4?

Google documenta un disparador concreto: el muestreo ocurre "when the number of events used to create a report, exploration, or request exceeds the quota limit for your property", es decir, cuando los eventos usados para crear un informe, exploración o petición superan el límite de cuota de tu propiedad. La cuota depende del nivel de la propiedad.

Superficie	Propiedad estándar	Analytics 360
Eventos leídos por consulta por defecto	10 millones	100 millones
Límite máximo disponible	10 millones	1.000 millones, vía "More detailed results" en Explore
Exploraciones sin muestrear	No disponible	Disponible, y solo cuando una consulta devolvería más de 1.000 millones de eventos

Una cuota de 10 millones de eventos no muestrea la mayoría de informes, porque GA4 no responde la mayoría de consultas desde datos a nivel de evento. Google describe dos grupos de tablas: "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", o sea, un grupo agrega los datos para responder rápido y sin muestreo a lo común, y el otro guarda el detalle por evento y usuario para investigaciones puntuales. Los informes estándar con dimensiones estándar caen en las tablas agregadas y vuelven sin muestrear sin importar el volumen de tráfico. El muestreo aparece cuando una consulta no se puede servir desde las tablas preagregadas: un rango de fechas personalizado, una comparación, un segmento ad hoc, un emparejamiento de dimensiones inusual, casi todo Explore.

Por eso dos personas en la misma propiedad pueden discrepar sobre si GA4 muestrea. Una vive en los informes estándar y no lo ha visto nunca. La otra construye exploraciones y lo ve cada semana.

¿Cómo distingues un informe muestreado de uno sin muestrear?

Mira el icono de calidad de los datos en la parte superior del informe o la exploración. Google afirma que "when your results use sampling, it is indicated in the data quality icon with the percentage of data used to create the results", es decir, el icono indica el porcentaje de datos usados. Ese porcentaje es toda la señal. Un informe construido con el 4% de los eventos y otro construido con el 96% se ven idénticos salvo por ese número, y merecen niveles de confianza muy distintos.

En la Data API la misma información llega como campos estructurados. ResponseMetaData lleva un array samplingMetadatas, y Google es preciso sobre cuándo aparece: "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." Cada entrada guarda dos cadenas 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"

Divide el primero entre el segundo y tienes el porcentaje que mostraría el icono. Para un pipeline de reporting, el detalle importante es que la ausencia de samplingMetadatas es el caso sin muestrear, así que el código que solo comprueba si hay un porcentaje bajo tratará cada respuesta limpia como sospechosa.

¿En qué se diferencian Standard y Analytics 360 en el muestreo?

La diferencia es el tamaño de consulta que 360 se puede permitir ejecutar, no un método distinto. Los dos niveles muestrean igual cuando muestrean. Analytics 360 arranca en 100 millones de eventos por consulta en vez de 10 millones, y añade dos vías de escape.

La primera es un interruptor dentro de Explore. El valor por defecto es "Faster results", y elegir "More detailed results" sube el tamaño de muestra hacia los 1.000 millones de eventos, lo que Google dice que basta para producir resultados sin muestrear en la mayoría de casos. Aquí hay un filo que pilla a la gente a media sesión de análisis: "Any change you make that requires the query to run again will revert back to the default Faster results option." Cambia una fecha, añade un segmento, intercambia una dimensión, y vuelves a la muestra pequeña sin ningún cuadro de diálogo que te lo diga.

La segunda es la petición de exploración sin muestrear, que ejecuta la consulta fuera de línea y te envía un correo cuando está lista. Las restricciones que Google documenta para ella son inusualmente específicas:

Restricción	Valor documentado
Elegibilidad	Solo si la consulta devolvería más de 1.000 millones de eventos
Cuota diaria de tokens	20.000 tokens por propiedad, compartidos entre todos los usuarios y peticiones de API
Techo de coste por consulta	5.000 tokens
Reinicio de cuota	Medianoche hora del Pacífico
Tiempo de procesamiento típico	Menos de 30 minutos
Vida del resultado	50 días desde la petición
Tamaño de exportación	Hasta 10.000.000 de celdas para TSV y CSV
Permiso necesario	Analista o superior
Técnica no admitida	User lifetime

La regla de elegibilidad es la que sorprende a los equipos. Una exploración sin muestrear no es un botón general de "dame números exactos"; solo existe por encima del punto en el que ya se superó el techo de 1.000 millones de eventos del propio 360.

El camino de escalado para salir del muestreo en Analytics 360

La consulta supera la cuota de 100 millones de eventos

Solo Resultados más rápidos (muestra por defecto)

Cambiar a Resultados más detallados (hasta 1000 millones de eventos)

Cualquier cambio revierte a Resultados más rápidos

Solicitud de exploración sin muestrear (solo por encima de 1000 millones de eventos)

¿Qué hacen Adobe y Matomo en su lugar?

Resuelven el mismo problema de rendimiento con otro compromiso, y se manifiesta en otro sitio de tus informes.

Adobe Analytics no documenta ningún mecanismo de muestreo en tiempo de informe para Analysis Workspace, y no ofrece equivalente al porcentaje de calidad de datos de GA4. Lo que Adobe limita es la cardinalidad, no las filas leídas. Hay un umbral de 2.000.000 de valores únicos por dimensión, por report suite y por mes natural. Los valores de dimensión recogidos después de cruzar ese umbral se agrupan en un solo elemento etiquetado "Low-Traffic", con un segundo umbral más agresivo fijado por defecto en 2.100.000 valores únicos. El contador se reinicia globalmente al final de cada mes natural.

La versión de Adobe es invisible del mismo modo que lo es el muestreo, pero distorsiona otro eje. Tus totales siguen siendo correctos. Tus desgloses por dimensión dejan de ser completos a mitad de mes, y Adobe advierte de que la dimensión Page está especialmente expuesta porque varias columnas de backend cuentan contra el mismo umbral, así que Low-Traffic puede aplicarse mucho antes de que el recuento visible de páginas parezca cercano a los 2 millones.

Matomo toma la posición contraria y lo dice directamente: Matomo no muestrea datos, y su documentación de calidad de datos lista "No data sampling" como propiedad de la plataforma. Los informes se procesan a partir de todos los datos rastreados. Esa afirmación es genuina, pero no es lo mismo que decir que los informes de Matomo son íntegros, y Matomo documenta la otra mitad por su cuenta: para mantener rápido el archivado, guarda por defecto un número limitado de filas por informe, en torno a las 500 páginas principales y las 1.000 palabras clave y sitios web principales, y suma todo lo que queda por debajo en una fila "Others". Las instalaciones propias pueden subir el techo con ajustes [General] en config/config.ini.php como datatable_archiving_maximum_rows_actions y datatable_archiving_maximum_rows_referrers, con un coste documentado en el rendimiento del archivado.

Plataforma	Qué limita	Dónde aparece la pérdida
Google Analytics 4	Eventos leídos por consulta	Cada métrica del informe, como estimación
Adobe Analytics	Valores únicos de dimensión por mes	Una sola fila "Low-Traffic" que absorbe la cola larga
Matomo	Filas archivadas por informe	Una sola fila "Others" que absorbe la cola larga

Lee esa tabla como tres respuestas a una misma pregunta. GA4 conserva cada valor de dimensión y aproxima las métricas. Adobe y Matomo mantienen exactas las métricas y colapsan los valores de dimensión. Si tu trabajo vive en totales y tendencias, el canje de GA4 es el barato; si vive en desgloses de cola larga, es el caro, y es una de las razones estructurales detrás de por qué dos herramientas reportan números distintos para la misma semana.

¿Cómo esquivas el muestreo sin cambiar de plan?

Encoge la consulta antes de dudar de la respuesta, ya que el muestreo depende de cuántos eventos tiene que leer una sola consulta.

• Parte un rango de fechas largo en varias consultas más cortas; la cuota se aplica por consulta y por rango de fechas.
• Prefiere los informes estándar para todo lo que un informe estándar pueda responder, porque esos vienen de las tablas agregadas.
• Mueve un segmento recurrente a una audiencia o dimensión personalizada para que el filtrado ocurra en el momento de la recolección.
• Consulta los eventos en bruto en BigQuery, lo que esquiva la cuota de reporting por completo y es la más fiable de las rutas cubiertas en cómo sacar tus datos de Google Analytics.

El hábito que vale la pena construir es mirar primero el icono y después la métrica, porque un número leído del 3% de los eventos parece exactamente igual de autorizado que uno leído de todos. Ese hábito también detecta el problema vecino de los eventos que nunca llegaron a la propiedad, que el muestreo no puede explicar ni arregla.

Preguntas frecuentes

¿Cuál es el umbral exacto de eventos para el muestreo en GA4?

Google documenta 10 millones de eventos por consulta en propiedades estándar y 100 millones en propiedades de Analytics 360 como ajustes de muestreo por defecto. Analytics 360 puede subir una exploración concreta a 1.000 millones de eventos seleccionando "More detailed results". Por debajo de esos límites la consulta devuelve resultados sin muestrear; por encima, se lee una muestra y el resultado se escala.

¿Que haya muestreo significa que Google tiró mis datos?

No. Los eventos siguen en la propiedad y en la exportación de BigQuery si hay una configurada. El muestreo es una decisión en tiempo de consulta sobre cuántos eventos leer dentro de la cuota, no una decisión de recolección ni de almacenamiento. Hacer la misma pregunta sobre un rango de fechas más corto, o contra BigQuery, puede devolver una respuesta exacta a partir de los mismos datos.

¿Por qué mi exploración vuelve a estar muestreada después de cambiar un filtro?

Porque Analytics 360 revierte el ajuste de tamaño de muestra cada vez que la consulta tiene que ejecutarse de nuevo. Google afirma que "any change you make that requires the query to run again will revert back to the default Faster results option". Vuelve a seleccionar "More detailed results" después de cada cambio, y mira el icono de calidad de los datos en vez de dar por hecho que el ajuste se mantuvo.

¿Puedo detectar el muestreo desde la Data API de Google Analytics?

Sí, a través del array samplingMetadatas en ResponseMetaData. Se rellena una vez por rango de fechas cuando el resultado está muestreado y no se define en absoluto cuando no lo está. Cada entrada da samplesReadCount y samplingSpaceSize como cadenas int64, y su cociente es el porcentaje de eventos leídos.

¿Adobe Analytics muestrea datos como lo hace GA4?

La propia documentación de Analysis Workspace de Adobe no describe ningún control de muestreo en tiempo de informe y no ofrece porcentaje de tamaño de muestra en la interfaz. El límite que Adobe sí documenta es sobre la cardinalidad de dimensiones: pasados 2.000.000 de valores únicos por dimensión, por report suite y por mes natural, los elementos nuevos se agrupan bajo una etiqueta "Low-Traffic", y el contador se reinicia al final de cada mes.

Si Matomo no muestrea, ¿por qué mis totales de Matomo difieren de un recuento completo de registros?

Porque Matomo limita las filas archivadas por informe y no los eventos leídos. Matomo procesa todos los datos rastreados y afirma que no muestrea, pero por defecto archiva solo las primeras cientos de filas de muchos informes y suma el resto en una fila "Others". Una instalación autoalojada puede subir ese techo con los ajustes datatable_archiving_maximum_rows_* en config/config.ini.php, que Matomo señala que pueden afectar significativamente al rendimiento del archivado.

¿El muestreo de GA4 afecta a todas las métricas de un informe por igual?

El muestreo no se reparte igual en un informe. Una métrica principal como el total de sesiones lo resiste bien porque la estimación se apoya en una base grande, mientras que un segmento que representa el 0,3 % del tráfico, una página de destino de cola larga o un embudo de conversión de cuatro pasos puede variar mucho, porque la muestra quizá solo contenga un puñado de los eventos relevantes. El informe muestra ambas cifras con la misma tipografía, así que nada en la pantalla indica cuál de las dos es más frágil.

¿Los informes estándar de GA4 llegan a muestrearse alguna vez?

Pocas veces, porque la mayoría de los informes estándar se responden desde las tablas agregadas que Google construyó para dar resultados rápidos y sin muestrear a las consultas habituales. El muestreo aparece cuando una consulta no puede resolverse con esas tablas, como un rango de fechas personalizado, una comparación, un segmento ad hoc, una combinación de dimensiones poco común o la mayoría de Explorar. Esa diferencia explica por qué dos personas en la misma propiedad pueden no ponerse de acuerdo sobre si GA4 muestrea: una vive en los informes estándar y nunca lo ve, la otra construye exploraciones y lo ve cada semana.

¿Cuánto tiempo permanecen disponibles los resultados de una exploración sin muestrear en Analytics 360 tras solicitarla?

Google documenta una vida útil del resultado de 50 días tras la solicitud, con un tiempo de procesamiento habitual de menos de 30 minutos. La exportación admite hasta 10.000.000 de celdas en TSV y CSV, y la solicitud solo es elegible cuando la consulta devolvería más de 1000 millones de eventos.

¿El umbral de Low-Traffic de Adobe se aplica igual a todas las dimensiones?

El umbral no se reparte igual entre dimensiones. Se fija en 2.000.000 de valores únicos por dimensión, por conjunto de informes y por mes natural, pero Adobe advierte que la dimensión Page es especialmente vulnerable porque varias columnas del backend cuentan para el mismo límite. Eso significa que Low-Traffic puede activarse mucho antes de que el recuento visible de páginas se acerque a los 2 millones, con un segundo umbral más agresivo fijado por defecto en 2.100.000.