BigQuery Export GA4: sesiones perdidas bajo la alfombra

BigQuery Export GA4 no es una versión más técnica, limpia y definitiva de los informes de Google Analytics 4. Es otra cosa: una salida de datos crudos, evento a evento, con menos maquillaje, menos cocina de interfaz y también menos ayudas automáticas. Por eso las sesiones que aparecen en GA4 pueden no cuadrar con las que reconstruye un analista en BigQuery. No siempre hay un fallo. A veces hay una diferencia legítima entre dato observado, dato modelado, atribución, retrasos de procesamiento, consentimiento y una consulta SQL escrita con demasiada fe.

La trampa está en confundir exportación granular con verdad absoluta. BigQuery permite auditar GA4 con bisturí, pero el bisturí no opera solo. El panel de Analytics aplica capas de procesamiento, modelado, identidad, estimaciones y reglas de atribución que no siempre viajan completas al export. En BigQuery aparecen filas, parámetros, marcas temporales, usuarios pseudónimos y eventos; en la interfaz de GA4 aparece una lectura más procesada. Parecen dos ventanas al mismo edificio, sí, pero no están en la misma planta.

El export no roba sesiones: enseña las costuras

La expresión sesiones perdidas suena bien para un titular, pero conviene bajar el volumen antes de convertirla en diagnóstico. En BigQuery Export GA4 no hay, por defecto, una tabla de sesiones ya peinada y lista para llevar al comité de dirección. Hay eventos, parámetros anidados, identificadores, timestamps y campos que a veces vienen completos, a veces llegan tarde y a veces no pueden existir porque el usuario no ha dado consentimiento. La sesión, esa unidad tan cómoda para el marketing desde los tiempos de Universal Analytics, en GA4 es una criatura reconstruida desde eventos.

Una sesión empieza cuando el usuario inicia interacción con una web o app sin una sesión activa previa. Por defecto, termina tras 30 minutos de inactividad. Cuando arranca, Analytics registra un evento session_start y genera un ga_session_id, que funciona como marca de inicio de sesión. Parece sencillo, hasta que se abre la caja. Ese identificador no basta solo, porque varios usuarios pueden iniciar una sesión en el mismo segundo. Por eso, para trabajar con rigor, hay que unirlo con user_pseudo_id o con user_id cuando la implementación lo permite.

Aquí aparece el primer charco. Quien cuenta solo eventos session_start puede quedarse corto. Quien cuenta solo ga_session_id puede duplicar, mezclar o perder contexto. Quien usa una lógica heredada de Universal Analytics puede estar midiendo un animal extinguido con una cinta métrica nueva. GA4 no reinicia sesiones por cambio de campaña a mitad de visita, y ese detalle rompe comparaciones históricas que muchas empresas siguen haciendo como si nada hubiera pasado. Qué bonito era mirar un dashboard y creer que todo obedecía.

La forma habitual de reconstruir sesiones en BigQuery pasa por contar combinaciones únicas de usuario e identificador de sesión. En la práctica, eso significa trabajar con user_pseudo_id y el parámetro ga_session_id dentro de event_params, o con user_id cuando el proyecto tiene login, CRM o algún sistema de identificación razonablemente estable. El matiz no es ornamental: dos usuarios pueden compartir el mismo ga_session_id porque ese valor nace de un timestamp. Sin el usuario al lado, el dato queda cojo.

Por qué GA4 y BigQuery no cuadran aunque todo funcione

La discrepancia entre GA4 y BigQuery nace de una diferencia filosófica bastante sencilla. La interfaz de GA4 intenta dar informes usables. BigQuery entrega materia prima. Una cosa es un plato; la otra, la cámara frigorífica. Ambas pertenecen al mismo restaurante, pero nadie sensato serviría una lubina sin limpiarla.

En los informes estándar, GA4 puede aplicar estimaciones, umbrales, reglas de atribución, integración con Google Signals, modelado por consentimiento y procesamiento interno. En BigQuery, el analista se encuentra con datos granulares exportados. La consecuencia es incómoda, pero muy real: no cabe esperar una reconciliación perfecta en todos los casos. La frase duele, pero libera. No todo descuadre es un incendio.

El caso de las sesiones es especialmente delicado porque GA4 puede utilizar aproximaciones estadísticas para algunos recuentos únicos. Ahí entra HyperLogLog++, un algoritmo pensado para estimar cardinalidades sin reventar recursos de cálculo. Suena a hechizo de mago con posgrado, pero la idea es terrenal: contar usuarios, sesiones o combinaciones únicas a gran escala sin tener que guardar y recorrer cada elemento como si fuera una lista de la compra. En BigQuery, en cambio, una consulta puede calcular una cardinalidad exacta a partir del dato granular, siempre que el planteamiento sea correcto.

Luego están los retrasos. Las tablas diarias events_YYYYMMDD no son una foto inmóvil en cuanto aparecen. Analytics puede actualizar esas tablas con eventos que pertenecen a esa fecha pero llegaron tarde, por ejemplo desde SDKs móviles o desde Measurement Protocol. El dato de ayer, tan fresco, tan irresistible, también puede estar verde. Comparar una tabla recién nacida con un informe ya procesado es como discutir el resultado de un partido en el minuto 63. Todavía quedan goles, tarjetas y alguna torpeza arbitral.

Y falta el detalle de la zona horaria, ese clásico administrativo que destroza informes con la discreción de un funcionario aburrido. En BigQuery, event_date responde a la fecha de la propiedad, mientras que event_timestamp trabaja en microsegundos y en referencia temporal distinta. Si una consulta mezcla fechas sin ajustar bien el huso horario, las sesiones cercanas a medianoche pueden caer en el día equivocado. No es épico. Es peor: es contable.

Consent Mode: cuando el usuario entra, pero no deja huella completa

El gran agujero moderno de la analítica no está en BigQuery. Está en el consentimiento. En Europa, con banners, CMP, navegadores más duros y usuarios bastante menos ingenuos, la medición digital se parece más a mirar una ciudad con niebla que a contar coches desde un puente soleado. El usuario puede visitar, navegar, convertir incluso; pero no siempre deja identificadores persistentes que permitan coser sus eventos en una sesión reconocible.

Con Consent Mode activado, el esquema de BigQuery puede incluir campos como privacy_info.ads_storage, privacy_info.analytics_storage y privacy_info.uses_transient_token, vinculados al estado de consentimiento. Esos valores ayudan a interpretar si el almacenamiento publicitario o analítico estaba permitido, denegado o sin configurar. Dicho de otra manera: no todos los usuarios llegan con la misma matrícula. Algunos entran con luces, otros con niebla, otros pasan casi como sombras técnicas.

Aquí la palabra importante es modelado. En los informes de GA4, cuando falta consentimiento, Analytics puede utilizar datos modelados para estimar comportamiento de usuarios que rechazan cookies a partir de patrones observados en usuarios que sí aceptan. Ese mecanismo no debe confundirse con una fila mágica añadida a BigQuery. La exportación puede contener señales limitadas, pings sin almacenamiento tradicional y eventos parciales, pero no replica de forma idéntica todo lo que la interfaz presenta como dato modelado.

En la práctica, un informe de GA4 puede mostrar sesiones que responden a estimaciones y reconstrucciones internas, mientras que una consulta en BigQuery ve eventos con identificadores ausentes, débiles o no enlazables. La alfombra no esconde polvo: esconde incertidumbre estadística. Y esto cambia mucho la lectura de caída de tráfico, conversión o rendimiento de canal.

El impacto se nota especialmente en webs de contenido, ecommerce, comparadores, medios, proyectos con mucho tráfico móvil y campañas donde conviven SEO, SEM, remarketing y navegación directa. Si una parte importante de usuarios rechaza cookies analíticas, una consulta basada en user_pseudo_id y ga_session_id puede dejar fuera eventos relevantes o clasificarlos de forma que no encaje con la interfaz. El analista mira BigQuery y cree que faltan sesiones. GA4 mira sus modelos y dice que no, que están ahí, solo que bajo otra lógica. Una conversación magnífica para empezar la semana.

Streaming, tablas diarias y el peligro de mirar demasiado pronto

Otro malentendido frecuente llega con las tablas intradía. BigQuery puede recibir datos mediante exportación diaria y mediante streaming export. La diaria genera tablas events_YYYYMMDD; la de streaming crea events_intraday_YYYYMMDD, que se alimentan durante el día y desaparecen cuando la tabla diaria queda consolidada. La diferencia parece burocrática, pero no lo es. Es una frontera entre dato provisional y dato relativamente estable.

El streaming export funciona como una entrega rápida, no como una promesa solemne de completitud. Puede contener huecos por eventos tardíos, cargas fallidas o procesamiento pendiente. También puede mostrar registros de una sesión repartidos en varias operaciones de exportación. Para análisis serio del día cerrado, conviene usar events_YYYYMMDD. Para vigilancia casi en tiempo real, events_intraday_YYYYMMDD puede servir, pero con casco. Y sin venderlo como verdad definitiva.

Hay más. El streaming no siempre incluye información completa de atribución para nuevos usuarios, como fuente, medio o campaña. La atribución de usuarios existentes también puede necesitar procesamiento posterior. Si alguien monta un panel en tiempo real y lo compara con GA4 al día siguiente, encontrará diferencias. No porque BigQuery sea malo. Porque se le está pidiendo a un borrador que se comporte como acta notarial.

En propiedades estándar, además, la exportación diaria tiene límites de volumen. Para proyectos grandes, con mucha medición, eventos personalizados, scrolls, clics, formularios, compras, pasos de checkout, pruebas A/B y etiquetas alegres como confeti, ese límite puede importar. Si se supera de forma sostenida, la exportación puede fallar o quedar incompleta. La analítica también se rompe por fontanería, no solo por teoría de atribución.

También existen fallos menos glamurósos: cuentas de servicio eliminadas, problemas de permisos, cambios de facturación, políticas de organización, streams no seleccionados, errores en el enlace con BigQuery o modificaciones de zona horaria. La mayoría de grandes misterios de la medición digital acaban oliendo a detalle técnico. A tornillo flojo. A “esto lo cambió alguien el jueves”.

La atribución de sesiones, ese sótano con poca luz

Si las sesiones ya son complejas, la atribución es el cuarto donde se guardan las cajas sin etiqueta. Durante años, muchos equipos intentaron reproducir en BigQuery los informes de adquisición de GA4 usando traffic_source, collected_traffic_source o parámetros UTM extraídos de eventos. El resultado solía parecerse a la interfaz… hasta que dejaba de parecerse. Direct inflado, google / organic donde se esperaba google / cpc, campañas ausentes, conversiones que cambiaban de canal según la dimensión elegida. Nada como una reunión de marketing para descubrir que una dimensión tiene más personalidad que algunos directivos.

El motivo es que traffic_source representa la fuente que adquirió por primera vez al usuario y no cambia con cada nueva interacción posterior. Sirve para análisis de primera adquisición, no para explicar cada sesión. Si un usuario llega por Google Ads, vuelve por tráfico orgánico y luego entra directo, la lectura depende mucho de qué campo se use, en qué evento se lea y qué ventana de atribución esté detrás. El dato está ahí, pero no siempre dice lo que el informe cree que está preguntando.

collected_traffic_source contiene datos de fuente de tráfico presentes en los eventos recogidos: UTM, gclid, dclid, srsltid y otros parámetros capturados. Es útil, pero no equivale automáticamente a la atribución de sesión de la interfaz. En una visita con UTM solo en la landing, por ejemplo, muchos eventos posteriores no cargan esos mismos parámetros. Si se consulta evento a evento sin elevar la lógica al nivel sesión, el canal se deshilacha.

La mejora relevante llegó con session_traffic_source_last_click, un registro del esquema de BigQuery que contiene datos de fuente de tráfico atribuidos a la sesión por último clic cuando están disponibles. Puede incluir campaña manual, campañas de Google Ads y datos vinculados a entornos como SA360, DV360 o CM360. Es un avance importante porque acerca BigQuery a la adquisición por sesión de GA4, aunque no borra todos los problemas históricos ni rellena mágicamente periodos anteriores.

La diferencia práctica es sencilla. Para analizar campañas actuales, conviene mirar primero si session_traffic_source_last_click está disponible y poblado. Para periodos antiguos, habrá que reconstruir con reglas propias, asumir más margen de discrepancia o documentar un corte metodológico. Lo que no conviene es mezclar traffic_source de primera adquisición con sesiones de campaña y luego acusar a GA4 de mentir. GA4 hace muchas cosas discutibles, cierto. Pero tampoco hace falta ayudarle.

Cómo leer BigQuery Export GA4 sin fabricar fantasmas

Un enfoque serio empieza con una idea incómoda: no hay un único número universal de sesiones. Hay sesiones según interfaz de GA4, sesiones exactas reconstruidas en BigQuery, sesiones con consentimiento completo, sesiones con identificadores parciales, sesiones atribuidas por último clic, sesiones por canal observado y sesiones apoyadas en datos modelados. Cada una sirve para algo. El desastre llega cuando se mezclan en la misma tabla como si fueran monedas iguales.

Para reporting ejecutivo, la prioridad debería ser la consistencia metodológica. Si el negocio toma decisiones de inversión con GA4, BigQuery no debe usarse solo para gritar que GA4 no cuadra, sino para explicar qué parte del descuadre procede de consentimiento, atribución, latencia, límites de exportación o consulta mal definida. El dato crudo tiene prestigio porque parece menos manipulado, pero también puede ser más torpe si se interpreta sin contexto.

En análisis de tráfico orgánico, el problema se vuelve especialmente fino. El SEO convive con sesiones directas, visitas recurrentes, Discover, referencias opacas, navegación desde apps, campañas de marca, enlaces internos, tráfico desde newsletters y usuarios que no aceptan medición. Si el analista usa mal traffic_source, puede atribuir a orgánico sesiones que en realidad pertenecen a otra interacción posterior, o al revés. Si mira streaming demasiado pronto, verá huecos. Si ignora Consent Mode, confundirá privacidad con caída de tráfico. Y si compara datos de las últimas 24 horas con alegría de tertuliano, tendrá titulares, no diagnóstico.

En SEM, BigQuery permite una auditoría más profunda de gclid, campañas, conversiones, ingresos y recorridos, pero exige reconciliar Google Ads, GA4 y el propio warehouse. Un clic puede existir en Ads, un evento puede aparecer en GA4, una sesión puede reconstruirse en BigQuery y una conversión puede atribuirse de forma distinta según la ventana, el consentimiento y la fuente elegida. Es pesado. También es la realidad.

La lectura más útil de BigQuery Export GA4 no consiste en buscar una coincidencia exacta con la interfaz, sino en construir una capa de datos propia, documentada y repetible. Una tabla intermedia de sesiones, otra de adquisición, otra de conversiones, reglas claras para consentimiento, exclusión de intradía en informes cerrados, comparación solo con datos maduros cuando toque, tratamiento separado de usuarios con analytics_storage denegado y una convención honesta para periodos anteriores a nuevos campos de atribución. No suena sexy. Funciona.

También conviene vigilar la implementación. Eventos enviados por Measurement Protocol sin ga_session_id, cambios de etiquetas, dominios cruzados mal cosidos, consentimientos que se disparan tarde, tags duplicadas, parámetros UTM inconsistentes, redirecciones que se comen el gclid, subdominios con cookies mal configuradas, propiedades con streams no seleccionados en el enlace de BigQuery. La mayoría de grandes misterios de la analítica digital acaban oliendo a detalle técnico. A tornillo flojo. A “esto lo cambió alguien el jueves”.

El dato limpio no existe, pero el dato útil sí

BigQuery no es la alfombra bajo la que GA4 esconde sesiones. Es más bien levantar la alfombra y descubrir que debajo hay cables, polvo, una moneda antigua y una etiqueta que nadie documentó. BigQuery Export GA4 sirve para recuperar control, auditar, cruzar datos propios, construir modelos internos y dejar de depender solo de una interfaz. Pero no convierte la medición en una ciencia exacta ni devuelve por arte de SQL lo que el navegador, el consentimiento o el procesamiento de Google no pueden entregar igual.

La madurez analítica en 2026 pasa por aceptar esa tensión. GA4 ofrece informes rápidos, modelados y útiles para muchas decisiones. BigQuery ofrece profundidad, trazabilidad y libertad, con el coste de tener que definirlo casi todo: sesiones, usuarios, canales, ventanas, conversiones y excepciones. Quien espera que ambos números coincidan al decimal está pidiendo contabilidad de notaría a un ecosistema hecho de cookies rotas, móviles, banners, campañas, latencias y modelos estadísticos.

La sesión perdida no siempre está perdida. A veces está modelada en GA4 y no exportada como fila equivalente. A veces llegó tarde. A veces quedó sin identificador. A veces fue contada con una consulta pobre. A veces nunca debió compararse. Y a veces sí, hay un fallo real en la exportación, en el enlace, en la cuota o en la etiqueta. La diferencia entre una alarma y una investigación empieza ahí: en dejar de tratar BigQuery como oráculo y empezar a tratarlo como lo que es, una sala de máquinas. Ruidosa, poderosa, incómoda. La verdad digital casi siempre suena así.