¿Por qué los datos de analítica son cada vez menos fiables?

La analítica web lleva años bajo presión, y el problema se ha acelerado de forma significativa en los últimos dos años. Las restricciones de privacidad, el bloqueo de scripts por parte de navegadores y extensiones, y la implantación del Consent Mode en mercados europeos han erosionado progresivamente la cobertura de los sistemas de medición tradicionales.

Los ad blockers bloquean las peticiones a dominios de terceros como google-analytics.com o googletagmanager.com en un porcentaje relevante de usuarios, especialmente en audiencias técnicas. Safari aplica Intelligent Tracking Prevention (ITP), que limita la vida útil de las cookies de primera parte a siete días y bloquea las de terceros. Firefox bloquea rastreadores de terceros por defecto. Y en la Unión Europea, cuando el banner de consentimiento presenta las opciones de aceptar y rechazar con igual prominencia, los estudios del USENIX Security Symposium en colaboración con la CNIL francesa documentan tasas de rechazo de hasta el 60-70%.

El resultado es que muchas cuentas de GA4 están midiendo una fracción del tráfico real sin que los equipos de marketing lo sepan. Las decisiones de optimización de campañas, atribución y análisis de comportamiento se toman sobre datos incompletos. Entender cómo funciona la cadena de recogida de datos es el primer paso para saber dónde se rompe y cómo se puede reforzar. Si quieres entender también el impacto que tiene el tráfico de IA en estas cifras, te recomendamos leer nuestro artículo sobre cómo medir el tráfico de IA en GA4.

¿Qué es el tracking client-side y cuáles son sus limitaciones?

El tracking client-side es el modelo estándar de medición web. Un script JavaScript (GA4, GTM, píxeles de Meta, etc.) se carga en el navegador del usuario y, desde ahí, envía eventos directamente a los servidores de la plataforma de analítica o publicidad. Toda la lógica de recogida de datos ocurre en el dispositivo del visitante.

✔️ Implementación sencilla: cualquier tag se puede desplegar en minutos desde GTM sin tocar el código del servidor.

✔️ Cobertura amplia de comportamiento: al ejecutarse en el navegador, tiene acceso al DOM, clics, scroll, interacciones con formularios y todo lo que ocurre en la página.

✔️ Coste cero de infraestructura: no requiere servidor propio ni mantenimiento adicional.

❌ Vulnerable a ad blockers: las peticiones a dominios de terceros son bloqueadas fácilmente. En audiencias técnicas, la tasa de bloqueo puede ser significativa y afectar a una parte relevante del tráfico.

❌ Dependiente del consentimiento: en mercados con Consent Mode activo, una parte importante del tráfico no activa los scripts de medición.

❌ Limitado por ITP y restricciones de cookies: Safari reduce la vida útil de las cookies de primera parte y bloquea las de terceros, truncando la ventana de atribución.

❌ Sin control sobre los datos enviados: los datos fluyen directamente al proveedor (Google, Meta) sin posibilidad de filtrar, enriquecer o transformar la información antes de que salga.

💡 Tip: Un síntoma claro de degradación en el tracking client-side es un porcentaje de tráfico directo anormalmente alto en GA4 (por encima del 20–25% en sitios maduros). Parte de ese “direct / none” no es tráfico sin fuente sino sesiones de usuarios con bloqueadores o navegadores con ITP donde la cookie de atribución ya ha expirado.

¿Qué es el server-side tracking y qué ventajas ofrece?

El server-side tracking desplaza la lógica de recogida de datos del navegador del usuario a un servidor controlado por el propio anunciante. En la práctica, esto significa implementar un contenedor de servidor en Google Tag Manager (sGTM), alojado en Google Cloud, en un proveedor gestionado como Stape.io o Addingwell, y configurar el sitio para que envíe eventos a ese servidor en lugar de directamente a Google o Meta.

El flujo es el siguiente: el navegador envía una petición a un subdominio propio (por ejemplo, metrics.tudominio.com), el servidor la procesa y la reenvía a GA4, Google Ads, Meta u otros destinos. Desde la perspectiva del navegador, toda la comunicación ocurre con un dominio de primera parte, lo que evita la mayoría de los bloqueos. Para profundizar en cómo funciona GTM y su arquitectura, puedes consultar nuestra guía de Google Tag Manager para profesionales de marketing digital.

✔️ Resistente a ad blockers: las peticiones van a tu propio dominio, no a google-analytics.com. La mayoría de bloqueadores no filtran dominios de primera parte.

✔️ Control total sobre los datos: puedes transformar, filtrar o enriquecer eventos antes de enviarlos al destino. Útil para eliminar datos PII, normalizar parámetros o añadir contexto de servidor como precio real de pedido, margen o datos de CRM.

✔️ Mejor señal para Smart Bidding: más conversiones registradas con mayor precisión mejora el aprendizaje de las pujas automáticas de Google Ads.

✔️ Compatible con múltiples plataformas: un solo contenedor de servidor puede distribuir eventos a GA4, Google Ads, Meta Conversions API, TikTok, LinkedIn y otros simultáneamente.

❌ Coste de infraestructura: un contenedor sGTM en Google Cloud tiene un coste mensual que oscila entre 30 y 150€ dependiendo del volumen de tráfico. Los proveedores gestionados como Stape reducen la complejidad pero mantienen un coste fijo.

❌ Mayor complejidad técnica: requiere conocimientos de configuración de servidor, DNS y depuración de eventos que van más allá de GTM estándar.

❌ No elimina el problema del consentimiento: el server-side mejora la cobertura técnica, pero no sustituye al Consent Mode. Sin consentimiento del usuario, el envío de datos sigue siendo una cuestión legal, no solo técnica.

💡 Tip: Si gestionas campañas de Google Ads con presupuestos superiores a 2.000€/mes, el ROI de implementar sGTM es claro. Más conversiones registradas se traduce directamente en mejor aprendizaje del algoritmo y menor CPA. Por debajo de ese umbral, evalúa primero si Google Tag Gateway cubre tus necesidades.

¿Qué es Google Tag Gateway y cómo implementarlo sin romper tu analítica?

Google Tag Gateway (GTG) es una solución intermedia que permite servir los scripts de Google (gtag.js, gtm.js) desde tu propio dominio a través de una CDN, sin necesidad de desplegar un servidor completo. A diferencia del sGTM, no procesa datos en un servidor propio, sino que actúa como proxy para las librerías de Google, sirviéndolas desde un subdominio de primera parte.

GTG es compatible con Cloudflare, Akamai, Fastly y Google Cloud CDN. Cloudflare es la opción más habitual para empezar, en parte por su capa gratuita. La configuración en Cloudflare se realiza desde el panel de GTM en Admin → Container → Google Tag Gateway, y el proceso completo lleva entre 5 y 10 minutos.

La restricción arquitectónica clave es que GTG solo funciona con tags de Google: GA4, Google Ads, Floodlight y Google Tag. No da soporte a plataformas externas como Meta, TikTok, LinkedIn ni ningún otro tag de terceros. Para esos casos, sGTM completo sigue siendo la única opción.

Riesgos de Cloudflare que pueden destruir tu analítica cualitativa

Cloudflare ofrece varias funciones de optimización de rendimiento que, si no se configuran correctamente, interfieren directamente con la ejecución de los scripts de analítica y producen datos completamente distorsionados.

Rocket Loader es el culpable más frecuente. Su función es mejorar el tiempo de renderizado cargando todos los archivos JavaScript de forma asíncrona, priorizando el contenido visible para el usuario. El problema es que puede retrasar la ejecución del script de GA4 lo suficiente como para que un visitante abandone la página antes de que el script haya podido dispararse. Cuando eso ocurre, la sesión nunca se registra. El síntoma en GA4 es una tasa de rebote artificialmente elevada y sesiones con duración de 0 segundos o cercana a cero, que no reflejan el comportamiento real del usuario sino un problema técnico de carga.

Las reglas de caché agresivas de tipo “Cache Everything” también pueden servir snapshots estáticos de HTML que nunca vuelven a ejecutar los scripts de GA. En sitios estáticos como los construidos con Astro, este comportamiento es especialmente relevante.

Auto Minify sobre JavaScript puede alterar el código de los scripts de GTM o gtag.js de formas impredecibles, causando errores silenciosos difíciles de diagnosticar.

Cómo diagnosticar y remediar el problema

El diagnóstico es sencillo. Activa el informe en tiempo real de GA4 y navega por tu propio sitio. Si las sesiones no aparecen o aparecen con duración cero, el script no está disparando correctamente. Complementa esto revisando la consola del navegador (DevTools → Console) en busca de errores de JavaScript durante la carga de la página.

Para remediarlo, las opciones son las siguientes en orden de preferencia:

✔️ Desactivar Rocket Loader en el panel de Cloudflare (Speed → Optimization → Content Optimization). Es la solución más directa y no tiene impacto significativo en el rendimiento real si los scripts están bien optimizados.

✔️ Desactivar Auto Minify para JavaScript en el mismo apartado de optimización.

✔️ Implementar Google Tag Gateway, que al servir los scripts desde tu propio dominio elimina la interferencia de Rocket Loader con los dominios de terceros de Google.

✔️ Excluir las URLs del script de GTM de las reglas de caché creando una Page Rule o Cache Rule que aplique “Bypass Cache” a las rutas */gtm.js y */gtag.js.

¿Por qué Cloudflare Analytics es más fiable que GA4 para medir tráfico real?

Cloudflare Web Analytics opera en una capa completamente diferente a GA4, ya que mide el tráfico a nivel de red, no de navegador. Esto tiene implicaciones directas sobre la fiabilidad del dato.

GA4 depende de que el script JavaScript se cargue y ejecute correctamente en el navegador del usuario. Como hemos visto, ad blockers, ITP, configuraciones de Cloudflare y falta de consentimiento pueden impedir esa ejecución. GA4 solo ve lo que el script ve, y el script no siempre llega.

Cloudflare Web Analytics, en cambio, registra las peticiones HTTP que llegan a su red antes de que lleguen al servidor. Un visitante que bloquea GA4, que rechaza las cookies o que usa Safari con ITP activo sigue generando una petición HTTP que Cloudflare registra. No hay script que bloquear porque la medición ocurre en la infraestructura, no en el navegador.

Además, Cloudflare Analytics no usa cookies ni almacena datos de identificación personal, lo que lo hace compatible con normativas de privacidad sin necesidad de consentimiento. No aplica sampling sobre los datos y al operar a nivel de red es capaz de distinguir mejor entre tráfico humano real y bots, dado que filtra gran parte del tráfico automatizado antes de que llegue al origen. Para un análisis más completo de herramientas de analítica que no dependen de cookies, puedes ampliar en nuestro artículo sobre alternativas a Google Analytics sin cookies.

La consecuencia práctica es que las cifras de Cloudflare Analytics serán superiores a las de GA4, y ese delta no es ruido sino tráfico real que GA4 no está capturando. Usar Cloudflare Analytics como referencia de tráfico total y GA4 para análisis de comportamiento y atribución es la combinación más robusta disponible hoy para la mayoría de sitios.

💡 Tip: Compara periódicamente las visitas únicas en Cloudflare Analytics frente a las de GA4. Si la diferencia es relevante y consistente en el tiempo, tienes un problema de cobertura en tu tracking que está afectando a tus decisiones de optimización. Ese delta es tu punto de partida para priorizar una mejora de implementación.

¿Qué solución de tracking encaja con tu caso?

No existe una solución única. La elección depende del volumen de tráfico, el presupuesto publicitario, la complejidad técnica disponible y los requisitos de privacidad.

✔️ Client-side estándar: adecuado si el tráfico es bajo, no hay inversión publicitaria significativa y la audiencia no es especialmente técnica. Fácil de implementar y mantener, asumiendo una pérdida de cobertura variable en función del perfil de la audiencia y el mercado geográfico.

✔️ Client-side + Google Tag Gateway: el siguiente nivel sin coste de infraestructura adicional. Reduce el bloqueo por ad blockers para el ecosistema Google, mejora la fiabilidad de los scripts en entornos con Cloudflare y no requiere servidor propio. Recomendable para cualquier sitio que use GA4 o Google Ads y ya esté en Cloudflare.

✔️ Server-side GTM (sGTM): necesario cuando se gestionan múltiples plataformas publicitarias (Google, Meta, TikTok), cuando el presupuesto en paid media justifica la inversión en infraestructura, o cuando se requiere control granular sobre los datos antes de enviarlos a terceros. Coste mensual de 30–150€.

✔️ Cloudflare Analytics como capa complementaria: recomendable en todos los casos como referencia de tráfico real. No sustituye a GA4 para análisis de comportamiento ni para atribución, pero ofrece una visión sin sesgos del volumen total de visitas.

Conclusiones sobre tracking y precisión en analítica

Los datos incompletos no son un problema de herramientas, son un problema de decisiones. Optimizar campañas, asignar presupuesto o evaluar el rendimiento de contenidos sobre una base de datos con cobertura parcial produce conclusiones sistemáticamente incorrectas.

Entender la diferencia entre client-side y server-side, saber cuándo Google Tag Gateway es suficiente y cuándo no, y complementar GA4 con Cloudflare Analytics son pasos concretos que mejoran la calidad de los datos sin necesidad de grandes inversiones en todos los casos.

En Vision by Data auditamos e implementamos arquitecturas de medición adaptadas a cada caso, desde configuraciones ligeras hasta implementaciones server-side completas. Si quieres saber qué porcentaje de tu tráfico real no estás midiendo y cómo solucionarlo, descubre cómo podemos ayudarte aquí.