BigQuery y GA4: por qué tus datos no cuadran desde 2026

BigQuery y GA4 no cuadran desde 2026 por una razón menos dramática de lo que parece y bastante más incómoda: no están enseñando exactamente la misma realidad. GA4 muestra informes procesados, con identidad de usuario, umbrales de privacidad, modelado, atribución y estimaciones estadísticas. BigQuery, en cambio, recibe el barro: eventos crudos, filas, parámetros, marcas de tiempo, identificadores seudónimos y todo ese material sin barniz que huele más a almacén que a escaparate. Dicho en cristiano: el panel de GA4 no es un espejo; es una interpretación.

La discrepancia no siempre indica una avería. De hecho, una diferencia moderada al comparar el recuento total de eventos de Analytics con las filas exportadas a BigQuery puede ser esperable, siempre que se hayan revisado enlace, zona horaria, exclusiones de streams y eventos. El problema empieza cuando se exige a BigQuery y GA4 una simetría que nunca prometieron. Como pedirle a una radiografía que salga favorecida. Una herramienta está pensada para reporting rápido y accionable; la otra, para análisis granular, auditoría, cruces con datos propios y una verdad más áspera, más cara y más difícil de consultar.

El dato crudo contra el dato maquillado

La primera grieta está en la naturaleza del dato. GA4 recibe eventos desde la etiqueta de Google, Google Tag Manager, SDKs, Measurement Protocol o importaciones, pero después los cocina. Los informes estándar pueden incluir señales de Google, modelado, atribución, predicciones, reglas de privacidad y agregaciones. BigQuery, por su parte, recibe lo recogido en la exportación, con menos poesía y menos intermediarios. Por eso, cuando alguien abre Looker Studio, ve una cifra; cuando tira una consulta SQL contra events_*, ve otra. No es magia negra. Es fontanería.

Este choque se nota más en 2026 porque muchas empresas ya no usan GA4 como una pantalla bonita para mirar visitas, sino como infraestructura de medición. Han conectado BigQuery, han montado dashboards, han metido costes de campañas, datos de CRM, ventas offline, leads, consentimientos, modelos de atribución propios. Y entonces aparece el pequeño monstruo: el director de marketing ve 100.000 usuarios en GA4 y el analista encuentra 106.000 user_pseudo_id en BigQuery. Luego vienen las reuniones. Luego el Excel. Luego alguien dice que “Analytics está mal”. No necesariamente. A menudo está haciendo otra cosa.

La interfaz de GA4 trabaja para ofrecer una lectura digerible. BigQuery trabaja para conservar trazas. Esa diferencia parece académica hasta que afecta a decisiones reales: inversión en campañas, atribución de ventas, bonus comerciales, presupuestos SEO o rendimiento de ecommerce. La interfaz agrupa, estima, oculta o modela cuando lo necesita. BigQuery enseña filas, y las filas no piden permiso para ser incómodas.

El matiz importante es que BigQuery no es la versión “más correcta” de GA4 en todos los escenarios. Es más granular, sí. También exige reconstruir métricas que en GA4 ya vienen calculadas. Un mal SQL puede producir un disparate con una seguridad ofensiva, como esos tertulianos que no dudan nunca. Contar sesiones, usuarios activos, conversiones o ingresos sin respetar el alcance de cada dimensión —evento, sesión, usuario, item— es una receta muy limpia para fabricar ruido.

Usuarios, sesiones y ese viejo vicio de contar dos veces

Una de las trampas más frecuentes está en los usuarios. En GA4, cuando un informe habla de “usuarios”, normalmente se refiere a usuarios activos, no a todos los identificadores que han disparado algún evento. En BigQuery, si se cuentan todos los user_pseudo_id distintos sin filtrar is_active_user, la comparación nace torcida. No es una diferencia menor: es la diferencia entre contar personas que han tenido actividad relevante y contar identificadores que aparecen en el almacén.

Aquí aparece otra capa: GA4 solo exporta a BigQuery datos basados en Device ID. Si la propiedad usa otra identidad de informe, la comparación con BigQuery será inexacta. La interfaz puede apoyarse en identidad mezclada, señales de Google o User-ID, según configuración y disponibilidad. BigQuery se queda con lo exportable. Más de una auditoría se ha torcido por olvidar este detalle, que no luce en una presentación pero pesa como una losa en los números. La opción sensata, cuando se quiere comparar, es revisar la identidad de informe y entender si se está mirando el mismo tipo de usuario. Parece aburrido. Lo es. También evita incendios.

Con las sesiones pasa algo parecido. En Universal Analytics había una memoria muscular muy instalada: sesiones que se reiniciaban con cierta lógica familiar, informes más rígidos, una arquitectura distinta. GA4 no funciona igual. La sesión estándar se calcula con combinaciones de identificadores y ga_session_id, no sumando alegremente sesiones diarias como si cada medianoche borrara la historia. Si una sesión cruza de un día a otro y se suman días por separado, el resultado puede duplicarse. Es un error pequeño en apariencia, pero suficiente para que un informe mensual parezca un acordeón.

Luego está el algoritmo. GA4 usa HyperLogLog++ para estimar cardinalidad en métricas comunes como usuarios activos y sesiones en la interfaz o la API. BigQuery, al trabajar con datos granulares, permite calcular cardinalidad exacta. Esa diferencia puede mover cifras en porcentajes pequeños, pero molestos. En analítica digital, un 1,6% parece poco hasta que alguien lo multiplica por inversión, ingresos o bonus. Entonces ya no parece tan simpático.

Consent Mode cambió la conversación

El factor que más ha ensuciado la comparación entre BigQuery y GA4 es el consentimiento. Y no porque la privacidad sea un capricho administrativo, sino porque la medición moderna ya no observa a todos los usuarios de la misma manera. En el Espacio Económico Europeo, Google reforzó las exigencias de consentimiento para medición, personalización de anuncios y remarketing; además, actualizó Consent Mode con parámetros como ad_user_data y ad_personalization. Quien mida tráfico europeo con etiquetas de Google debe transmitir a Google las elecciones de consentimiento del usuario.

En Consent Mode básico, las etiquetas de Google no cargan hasta que el usuario interactúa con el banner. Si no consiente, no se envía dato alguno a Google, ni siquiera el estado de consentimiento. En Consent Mode avanzado, las etiquetas cargan con el consentimiento denegado por defecto y pueden enviar señales sin cookies, conocidas como cookieless pings, hasta que el usuario decide. Cuando acepta, se envía medición completa; cuando rechaza, se envían señales limitadas, sin almacenamiento de cookies. Parece una sutileza técnica. No lo es. Es el suelo entero moviéndose bajo la medición.

GA4 puede usar esas señales para modelar comportamiento y cubrir parte de los huecos que deja la falta de consentimiento. El modelado conductual estima actividad de usuarios que rechazan cookies a partir del comportamiento de usuarios similares que sí consienten. Pero —y aquí está el diente— esos datos modelados no están disponibles en la exportación de eventos de BigQuery. En la interfaz se puede ver una realidad estimada; en BigQuery, una realidad observada o señalizada, pero no completada con el mismo modelo.

Por eso desde 2026, en muchos proyectos europeos, BigQuery y GA4 se separan más justo donde más importa: usuarios, sesiones, conversiones y atribución de campañas. GA4 puede intentar recomponer el vaso roto con modelado. BigQuery enseña los cristales en la mesa. Si la implementación es avanzada, aparecerán señales sin cookies; si es básica, puede haber directamente ausencia de datos de usuarios no consentidos. Y si el banner está mal configurado, el asunto deja de ser una discrepancia razonable para convertirse en una fuga silenciosa.

El campo privacy_info en la exportación de BigQuery existe precisamente para guardar información relacionada con el estado de consentimiento cuando Consent Mode está habilitado, como ads_storage, analytics_storage o el uso de tokens transitorios en determinados escenarios. Es un dato de lectura obligatoria para cualquier análisis serio en 2026. Mirar conversiones sin mirar consentimiento es como mirar una playa sin mirar la marea. Algo falta, aunque la postal salga bonita.

Atribución: el campo donde nadie sale inocente

La atribución es otro jardín. Y de los espesos. GA4 aplica modelos y reglas de atribución en sus superficies de reporting. BigQuery almacena datos de tráfico en varios niveles: fuente recogida en el evento, fuente de adquisición del usuario, campos de última interacción de sesión cuando están disponibles. La propia lógica del esquema distingue entre datos presentes en los eventos, fuente que adquirió inicialmente al usuario y última interacción atribuida a la sesión en determinados contextos. Todo parece llamarse parecido. Nada significa exactamente lo mismo.

Esto explica una escena muy común: el informe de adquisición de GA4 atribuye más conversiones a google / cpc, mientras una consulta en BigQuery basada en UTMs del evento reparte más peso entre referral, organic o direct. No es que una tabla se haya vuelto antisistema. Es que se están mezclando capas. Fuente de usuario, fuente de evento y fuente de sesión no son la misma criatura. Comparten apellido, pero no casa.

La exportación intradía complica aún más el panorama. Las tablas events_intraday_YYYYMMDD se rellenan durante el día y se eliminan cuando la tabla diaria completa está lista. Para un conjunto estable, lo normal es consultar events_YYYYMMDD, porque la exportación streaming puede contener huecos y no siempre incluye de inmediato ciertos datos de atribución. Además, algunos datos de usuarios existentes pueden necesitar horas para completarse. Nada grave si se sabe. Bastante grave si se presenta como verdad cerrada antes de tiempo.

A partir de ahí, cualquier dashboard que compare hoy en BigQuery con hoy en GA4 puede convertirse en una máquina de fabricar alarmas. La cifra de la mañana no es la de la tarde; la de la tarde no es siempre la del día siguiente; la del día siguiente puede no estar cerrada si entran eventos retrasados. En marketing digital se ha vendido durante años la fantasía del dato en tiempo real, pero el dato en tiempo real suele ser eso: un dato con el abrigo puesto, entrando todavía por la puerta.

Exportaciones, retrasos y límites: la parte menos sexy

La exportación diaria crea tablas events_YYYYMMDD; la exportación streaming crea events_intraday_YYYYMMDD; y las tablas diarias pueden actualizarse durante varios días para incorporar eventos retrasados con la marca temporal correcta. Los eventos que llegan demasiado tarde pueden quedarse fuera. Este detalle basta para explicar diferencias en propiedades con apps, Measurement Protocol, tráfico offline, conexiones inestables o implementaciones que envían eventos tarde.

También hay límites. Las propiedades estándar de GA4 tienen un límite diario para exportaciones batch a BigQuery; las propiedades 360 cuentan con márgenes más amplios. La exportación streaming no se comporta igual, pero opera como servicio de mejor esfuerzo y puede tener costes asociados. Si una propiedad estándar supera de forma consistente el límite diario, la exportación puede pausarse y los días anteriores no se reprocesan. Una frase seca, casi administrativa, pero con consecuencias muy carnales para quien descubre tarde que le faltan datos.

La zona horaria es otra piedra pequeña que rompe zapatos grandes. event_date se registra según la zona horaria de la propiedad, mientras event_timestamp está en microsegundos UTC. Si se consulta por timestamp sin ajustar a la zona horaria de reporting, se comparan periodos distintos. Un día de GA4 puede no ser el mismo día de una consulta SQL mal construida. No suena heroico, pero muchas discrepancias nacen ahí: en una medianoche desplazada, en una tabla consultada con prisa, en un filtro que parecía inocente.

Y luego están las exclusiones. Al configurar el enlace con BigQuery se pueden excluir streams o eventos. Si GA4 muestra toda la propiedad pero BigQuery solo exporta parte, la comparación no tiene valor. Conviene revisar si todos los streams están incluidos y si hay eventos excluidos antes de declarar la guerra al dato. A veces el villano era un ajuste olvidado por alguien que ya ni trabaja en la empresa.

Cuándo una diferencia es normal y cuándo huele mal

Una diferencia pequeña en eventos totales, usuarios o sesiones puede ser normal si se comparan superficies distintas, fechas recientes, identidades de informe no equivalentes, datos con Consent Mode, cardinalidad alta o consultas exactas frente a estimaciones. El dato no está roto por no coincidir al céntimo. BigQuery y GA4 no son dos básculas calibradas para el mismo tipo de peso. Una mide materia prima; la otra sirve platos.

Pero hay señales de alarma. Si faltan días completos en BigQuery, si el recuento de filas cae de golpe sin una caída de tráfico comparable, si los eventos clave desaparecen solo en la exportación, si una propiedad estándar roza o supera su límite diario, si la configuración de consentimiento cambia sin anotación, si analytics_storage pasa masivamente a “No” o “Unset”, ahí ya no estamos ante una diferencia filosófica. Estamos ante un problema operativo.

La forma sensata de leer el dato en 2026 empieza por renunciar a una obsesión infantil: que todo cuadre siempre. Hay que definir una fuente de verdad según uso. Para reporting ejecutivo rápido, GA4 puede bastar, con sus límites conocidos. Para auditoría, modelos propios, atribución avanzada, CRM, LTV, cohortes o análisis de comportamiento, BigQuery es el terreno serio. Pero serio no significa automático. Exige diccionario de métricas, queries versionadas, control de consentimiento, revisión de zona horaria, trazabilidad de cambios y cierta humildad. Esa palabra tan poco de dashboard.

También hay que explicar internamente que el dato modelado no es mentira y el dato crudo no es dogma. El modelado intenta compensar una pérdida de observación en un entorno más respetuoso con la privacidad; el dato crudo conserva lo que efectivamente llegó a la exportación. Ambos tienen utilidad. Ambos tienen sesgos. El error es mezclarlos sin decirlo, como quien mete vino tinto y café en la misma copa y luego pregunta por qué sabe raro.

El nuevo pacto con la medición

BigQuery y GA4 no cuadran desde 2026 porque la medición digital ha dejado de ser una contabilidad simple de visitas y conversiones. Ahora intervienen consentimiento, identidad, señales incompletas, privacidad, modelado, retrasos de exportación, cardinalidad, atribución y SQL. Menudo banquete. La buena noticia es que la discrepancia se puede entender; la mala es que ya no se puede despachar con un “Analytics falla” mientras alguien mira el móvil.

El dato fiable no nace de elegir ciegamente entre GA4 o BigQuery, sino de saber qué representa cada cifra. GA4 ofrece lectura procesada, útil para decisiones rápidas y comparaciones de negocio dentro de su propio marco. BigQuery ofrece granularidad, memoria y posibilidad de construir una medición propia, más transparente y también más exigente. Cuando ambos no coinciden, la pregunta seria no es cuál miente. La pregunta adulta es qué capa del dato se está mirando, qué se ha modelado, qué se ha exportado, qué se ha perdido por consentimiento y qué se ha calculado mal en la consulta.

En 2026, medir bien ya no consiste en perseguir una cifra única como si fuera una reliquia. Consiste en saber de dónde viene cada número, qué cicatrices trae y para qué sirve. Lo demás es decorar informes. Y de decoración, sinceramente, el marketing digital ya va sobrado.