¿Por qué faltan tablas events_YYYYMMDD en mi dataset de GA4?

El export diario crea una tabla por día solo si ese día hubo eventos. En propiedades con poco tráfico, o si el consentimiento impide medir, habrá días sin tabla sin que se haya perdido nada. Hay que contrastar con otra fuente antes de concluir que hay pérdida de datos.

¿Cómo detecto un hueco real en el export?

Compara los días con tabla con los días en que otra fuente independiente (logs del servidor de etiquetado, analítica del CDN) registró tráfico. Si hay tráfico en esa fuente y no hay tabla, o la tabla tiene muchos menos eventos de lo esperable, investiga: puede ser un fallo del export o de la recogida.

Un día sin tabla en el export de GA4 a BigQuery no siempre es un hueco: cómo distinguirlo

Vi que en mi dataset de GA4 en BigQuery faltaban tablas de varios días y pensé en un fallo del export. No lo era. Antes de abrir un caso de soporte conviene comprobar una cosa muy simple.

Qué hace el export diario

GA4 genera una tabla events_YYYYMMDD por día solo si ese día hubo eventos. Si no hubo ninguno, no crea una tabla vacía: no crea nada. En una propiedad con mucho tráfico nunca lo ves. En una con poco tráfico, o con un consentimiento que impide medir a muchos visitantes, los días sin tabla pueden ser la norma.

Paso 1: lista los días que faltan

Esta consulta cruza un calendario con las tablas que existen. Cambia el proyecto, el dataset y el rango:

WITH dias AS (
  SELECT d
  FROM UNNEST(GENERATE_DATE_ARRAY(DATE '2026-09-11', DATE '2026-11-02')) AS d
),
tablas AS (
  SELECT PARSE_DATE('%Y%m%d', REGEXP_EXTRACT(table_name, r'^events_(\d{8})$')) AS d
  FROM `proyecto.analytics_XXXXXXXXX.INFORMATION_SCHEMA.TABLES`
  WHERE REGEXP_CONTAINS(table_name, r'^events_\d{8}$')
)
SELECT dias.d AS dia_sin_tabla
FROM dias
LEFT JOIN tablas USING (d)
WHERE tablas.d IS NULL
ORDER BY dia_sin_tabla

La expresión regular deja fuera las tablas events_intraday_ y pseudonymous_users_. En mi caso, con datos hasta el 2 de noviembre de 2026, de 53 días en el rango 13 tenían tabla y 40 no.

Paso 2: contrasta con un segundo origen

Que falte una tabla no dice si fue pérdida o ausencia de visitas. Para saberlo necesitas otra fuente que registre actividad por su cuenta. Yo tengo un servidor de tagging propio en Cloud Run, así que conté las peticiones a /g/collect por día en sus logs:

gcloud logging read \
  'resource.type="cloud_run_revision" AND httpRequest.requestUrl:"/g/collect"' \
  --freshness=60d --format='value(timestamp)' \
  | cut -c1-10 | sort | uniq -c

Otras fuentes válidas son los logs del servidor web o las analíticas del CDN.

Lo que encontré

Los días con peticiones a /g/collect en el servidor de tagging coincidían uno a uno con los días con tabla en BigQuery. Ni un día con tráfico sin tabla, ni una tabla sin tráfico. Los huecos eran días sin ninguna visita medida.

Los “huecos” no eran un problema técnico: eran la medida correcta de días en los que no se había medido ninguna visita. El export había hecho exactamente lo que debía.

Cuándo sí es un hueco real

Sospecha de pérdida de datos si ocurre alguna de estas:

Hay tráfico en la segunda fuente un día que no tiene tabla.
Hay tabla, pero con muchos menos eventos que los días comparables.
Hay un corte brusco coincidente con un cambio (un despliegue, un cambio de CSP, un cambio de contenedor).

En esos casos, el siguiente paso es revisar qué se publicó ese día en GTM y si la consola del navegador muestra bloqueos.

Cómo dejarlo vigilado

No hace falta comprobarlo a mano. Una vez la lógica anterior funciona, puedes convertirla en un test programado que avise cuando falten tablas en días con tráfico conocido, o medir directamente el volumen diario de eventos frente a la media de los días previos. Lo he hecho en un modelo dbt sobre GA4.