Por qué el Seguimiento en el Servidor puede seguir perdiendo datos (y cómo lo soluciona el Enhanced Tracking Script)
Mariusz Brucki | 7 mayo 2026 | Última actualización: Puntos clave
- El Rastreo del lado del servidor por sí solo no protege contra los bloqueadores de anuncios que interceptan la petición del navegador al servidor antes de que llegue a tu contenedor servidor.
- Los scripts de seguimiento estándar del mercado no resuelven la laguna de datos en la capa del script.
- El Script de Seguimiento Mejorado TAGGS encripta la solicitud de evento completa (no sólo la URL del script GTM) haciéndola irreconocible para cualquier filtro de bloqueo.
- En audiencias muy bloqueadoras (desarrolladores, vendedores, profesionales de la analítica) el aumento generado por el script TAGGRS alcanza cerca de un 30% más de solicitudes medidas.
El Seguimiento en el Servidor resuelve un verdadero problema de medición. Aleja la recopilación de datos del navegador y proporciona a tu configuración un punto final de servidor de primera parte. Para muchos equipos, ése es el mayor paso hacia una mejor atribución.
Pero hay una capa que a menudo se pasa por alto.
Antes de que un evento llegue a tu contenedor servidor, el navegador todavía tiene que cargar el script de seguimiento y enviar la solicitud de evento. Si cualquiera de estas partes se bloquea, tu configuración del lado del servidor nunca tiene la oportunidad de hacer su trabajo.
El tablero de mandos todavía puede parecer sano. Los eventos siguen llegando. Tu contenedor de servidor está funcionando. Pero una parte de los datos puede filtrarse incluso antes de que se realice la primera petición del lado del servidor.
Para las agencias y los especialistas en seguimiento, esa brecha es importante. Puedes construir la arquitectura correcta del lado del servidor y aun así perder datos en la capa de script.
El Script de Seguimiento Mejorado TAGGRS cierra esa brecha. Sustituye tu fragmento GTM estándar por un script que cifra la solicitud completa del navegador al servidor, haciéndola irreconocible para los filtros de bloqueo. Este artículo explica dónde comienza la brecha de datos, por qué la encriptación supera a la codificación en la capa del script, y qué mejora mensurable pueden esperar las agencias.
El Seguimiento del Servidor no se inicia en el servidor
La mayoría de los equipos piensan que el Seguimiento en el Servidor es un problema del contenedor del servidor. Comprueban si el servidor de etiquetado está activo, si GA4 recibe eventos y si las etiquetas de conversión se disparan.
Esas comprobaciones son útiles, pero empiezan demasiado tarde.
Una configuración típica sigue dependiendo de un script de seguimiento del lado del navegador, normalmente Google Tag Manager. GTM se carga en el navegador, inicia el contenedor y envía solicitudes al punto final del lado del servidor. En la mayoría de las configuraciones, la carga del script ya está resuelta. El script GTM está enmascarado, por lo que se carga sin problemas.
El punto débil viene a continuación.
Cómo el script GTM crea un punto ciego
Después de que el script se cargue, todavía tiene que enviar eventos al contenedor del lado del servidor. Incluso cuando esas peticiones van a un dominio de origen, la ruta de petición puede contener marcadores reconocibles como /collect, /g/collect u otros patrones analíticos. Los bloqueadores de anuncios pueden detectar esos patrones y bloquear el evento antes de que llegue al contenedor del servidor.
Esto crea un modo de fallo difícil de detectar:
- el script GTM carga
- el punto final del lado del servidor es de primera parte
- la ruta de la petición sigue revelando cuál es la petición
- GA4 y las plataformas publicitarias reciben menos eventos
- los informes de campaña se siguen actualizando, pero con menos datos de los que deberían
Nada parece totalmente roto. Ves datos, pero no todos.
El resultado es un punto ciego de medición. El Seguimiento en el Servidor mejora la ruta después de que la petición llegue al servidor de etiquetado, pero no puede procesar un evento que se bloqueó en el navegador porque la petición seguía pareciendo de seguimiento.
Ahí es donde se hace visible la elevación. Si la capa de scripts y la ruta de petición se vuelven más difíciles de reconocer, llegan más eventos al contenedor del servidor.
La prueba: Entre un 0,8% y un 9,1% más de páginas vistas medidas
TAGGRS construyó el Script de Seguimiento Mejorado para eliminar la capa visible más débil del seguimiento moderno: la petición que sigue pareciendo analítica antes de llegar al contenedor del lado del servidor.
El objetivo es sencillo. Si un usuario da su consentimiento y se supone que se va a medir un evento, esos datos deben poder fluir hacia el contenedor del lado del servidor, en lugar de ser detenidos por un script reconocible o una ruta de solicitud.
En la práctica, eso convierte al Script de Seguimiento Mejorado en uno de los scripts de seguimiento más resistentes del mercado. TAGGRS lo probó con 30 socios pioneros y en el sitio web que estás leyendo ahora mismo. La diferencia era evidente.
El punto de referencia de elevación del Guión de Seguimiento Mejorado TAGGRS
| Configurar | Aumento de las páginas vistas medidas |
| Seguimiento estándar del cliente | Línea de base |
| Enmascaramiento de scripts GTM + dominio de origen | +0.8% |
| Script de seguimiento mejorado TAGGRS | +9.1% |
| Públicos muy bloqueadores (desarrolladores, vendedores) | Hasta ~30 |
Con el enmascaramiento gtm.js estándar y un dominio de origen, TAGGRS midió un aumento del 0,8% en las visitas a la página en comparación con el seguimiento típico del lado del cliente. Esa configuración ya resolvía parte del problema: el script GTM podía cargarse desde una ruta menos reconocible.
Tras implementar el nuevo Script de Seguimiento Mejorado, el aumento creció hasta el 9,1% de páginas vistas medidas. La diferencia se produjo al enmascarar toda la solicitud, no sólo la carga del script GTM. En lugar de enviar eventos a través de rutas reconocibles, el script hizo que la solicitud completa del navegador al servidor fuera más difícil de identificar para los bloqueadores.
Entre los socios pioneros, el efecto fue el mismo. En los casos más fuertes, el aumento alcanzó cerca de un 30% más de eventos medidos.
Un aumento del 9,1% no es una mejora cosmética de los informes. En una cuenta de alto gasto, puede cambiar la calidad de la señal que vuelve a Google Ads, Meta, GA4 u otras plataformas.
Una mejor señal no sólo mejora los informes. También proporciona a los algoritmos publicitarios una información más completa. Las campañas se optimizan en función de los eventos que sobreviven a la cadena de seguimiento. Si parte de esa cadena está bloqueada a nivel de script, el algoritmo aprende de una imagen incompleta.
Por qué es importante el perfil de la audiencia
El perfil de la audiencia influye mucho en la magnitud de la subida:
- Los sitios web orientados al consumidor pueden experimentar una modesta subida.
- Los productos utilizados por desarrolladores, vendedores, equipos de análisis o compradores de tecnología tienden a ver un porcentaje más alto. Es más probable que estos visitantes utilicen bloqueadores de anuncios o una configuración más estricta del navegador.
Para las agencias que gestionan sistemas de seguimiento para clientes centrados en el rendimiento, el efecto es siempre fuerte.
Por qué las trayectorias de seguimiento estándar son fáciles de detectar
Los bloqueadores de anuncios no necesitan comprender toda tu configuración de seguimiento. Buscan patrones.
Esos patrones pueden ser dominios, rutas, nombres de archivo, formas de solicitud o puntos finales de análisis conocidos. Una solicitud de seguimiento estándar da a los bloqueadores mucho con lo que trabajar. La ruta es familiar. La estructura de la consulta es familiar. El comportamiento de la red es familiar.
El Seguimiento en el Servidor cambia el destino de muchas peticiones, pero la ruta puede seguir revelando lo que ocurre. Una solicitud a un dominio de origen puede seguir conteniendo una ruta con forma de seguimiento.
Ese es el punto débil.
Piénsalo como el código limpio frente al código frágil. El código frágil funciona siempre que el entorno sea amigable. Cambia un supuesto, y se rompe. El código limpio se construye con menos patrones frágiles, por lo que resiste mejor cuando cambia el entorno.
El rastreo tiene el mismo problema. Una configuración puede funcionar perfectamente en una prueba de navegador limpio y aun así perder datos cuando un visitante utiliza uBlock Origin, Ghostery, un navegador de privacidad estricta o una lista de filtros que se dirige a rutas comunes como /collect.
La resiliencia no consiste en ocultar comportamientos turbios. Se trata de hacer que la medida consentida sea menos frágil.
Por qué otros no han resuelto la capa del guión
Muchas configuraciones de seguimiento se detienen en el enrutamiento del lado del servidor. Trasladan las peticiones de GA4 o de la plataforma publicitaria a un punto final de primera parte, y luego asumen que el problema está resuelto.
Eso ayuda, pero no protege totalmente la petición después de que el script se haya cargado.
Algunas herramientas de Seguimiento del Servidor ya reconocen este problema. Su documentación explica que las solicitudes GA4 utilizan patrones reconocibles como /g/collect, y los bloqueadores de anuncios pueden bloquear las solicitudes coincidentes incluso cuando la configuración utiliza el Seguimiento del lado del Servidor. La respuesta habitual es codificar las peticiones antes de que lleguen al contenedor GTM del lado del servidor, y descodificarlas después antes de la vista previa/depuración.
Éste es el problema que hay que resolver. Pero en nuestras pruebas anteriores, el enmascaramiento parecía débil porque la estructura de la petición aún podía descodificarse y entenderse con demasiada facilidad. Si la protección consiste sobre todo en una capa de codificación legible, como el enmascaramiento al estilo base64, es más difícil considerarla una resistencia a largo plazo. Las listas de filtros pueden adaptarse una vez que se conoce el patrón.
El enfoque más sólido no consiste sólo en ocultar la palabra "recopilar". La solicitud del navegador debe evitar patrones estables que los bloqueadores de anuncios puedan volver a coincidir el mes que viene.
Qué cambia el Script de Seguimiento Mejorado TAGGRS
El Script de Seguimiento Mejorado adopta un enfoque más fuerte: encripta la petición en lugar de sólo codificarla.
Esa diferencia importa. La codificación es como traducir una frase del inglés al español. La frase parece diferente, pero cualquiera que conozca el método puede volver a traducirla. Sigue siendo el mismo mensaje en un formato diferente.
La encriptación funciona de forma diferente. La solicitud se transforma con una clave, de modo que la ruta del lado del navegador ya no expone marcadores de seguimiento legibles como /collect o /g/collect. Antes de que la solicitud llegue al contenedor del lado del servidor, TAGGRS puede descifrarla y enrutarla correctamente.
El Script de Seguimiento Mejorado sigue siendo un sustituto directo del script estándar de Google Tag Manager. En lugar de colocar el fragmento GTM normal en el sitio web, añades el Script de seguimiento mejorado desde tu panel TAGGRS. Sigue funcionando con tu contenedor web GTM, pero el flujo de solicitudes cambia.
A alto nivel, el guión hace 4 cosas:
- sustituye el patrón de carga estándar de GTM por uno más resistente.
- encripta la petición completa del navegador al servidor, no sólo la URL del script.
- descifra y encamina la petición antes de que llegue al contenedor del lado del servidor.
- ayuda a mantener más eventos disponibles para GA4 y las plataformas publicitarias cuando están activos los bloqueadores o las restricciones del navegador.
El punto clave es dónde actúa. No sustituye al Seguimiento del Servidor. Protege el paso previo a que el Seguimiento del Servidor reciba el evento, donde muchas configuraciones siguen exponiendo rutas de análisis reconocibles.
¿Te preguntas cómo configurar el guión?
¿Es esto legal y ético?
Sí, si se utiliza con la finalidad adecuada y con los controles de privacidad adecuados.
La intención es solucionar las lagunas de medición, no rastrear secretamente a los usuarios en contra de sus deseos. Los equipos de análisis deben seguir siendo transparentes en su política de privacidad, respetar las opciones de consentimiento y dar a los usuarios el control sobre la recopilación de datos, tal como exige la ley.
Lo mismo se aplica a la calidad de los datos. Más datos sólo son útiles si se recopilan de forma responsable. Los especialistas en seguimiento deben seguir aplicando técnicas de anonimización, evitar el envío de IPI y comprobar que las solicitudes de los usuarios con bloqueadores de anuncios no contengan marcadores de datos personales que no deberían estar ahí.
El Script de Seguimiento Mejorado es una herramienta. Hace que la ruta de rastreo sea más resistente, pero no elimina la responsabilidad de utilizar una gestión adecuada del consentimiento, controles de privacidad y una gestión limpia de los datos.
También hay un segundo problema relacionado con el consentimiento que merece su propio artículo. Algunos bloqueadores de anuncios pueden bloquear o romper los propios banners de consentimiento. Con la configuración adecuada del contenedor del lado del servidor, el Script de Seguimiento Mejorado también puede ayudar a que el flujo de consentimiento sea más resistente. Este tema necesita una explicación más profunda, pero el principio es el mismo: la medición debe ser fiable sin eliminar la elección del usuario.
Comprueba la mejora en tu propio panel de control
Lo mejor de esta función es que el impacto es visible.
En el panel de TAGGRS Analytics, el gráfico Solicitudes puede mostrar categorías de solicitudes. Una de esas categorías es Script de seguimiento mejorado. Muestra las solicitudes activadas por el script, para que puedas ver si el nuevo script está activo y cuánto tráfico gestiona.
Eso es importante para la confianza.
La mayoría de las mejoras en el seguimiento son difíciles de demostrar. Un especialista cambia la configuración, los datos parecen un poco mejores, y todo el mundo tiene que deducir qué ha pasado. El Script de Seguimiento Mejorado ofrece a las agencias un punto de prueba más claro. Puedes mostrar a la cuenta lo que ha cambiado y dónde aparece la actividad medida adicional.
El panel de control también ayuda con la validación tras el despliegue:
- Utiliza la vista Últimas 24 horas para comprobar el efecto poco después de la aplicación.
- Utiliza las categorías de solicitudes para confirmar que están llegando solicitudes de Guión de Seguimiento Mejorado.
- Compara los datos del lado del servidor y del lado del cliente para ver cuántos datos extra capta tu configuración del lado del servidor.
- Observa si se producen caídas inusuales tras cambios en el CMS, ediciones de GTM o actualizaciones del filtro bloqueador de anuncios.
Para las agencias, esto es útil en las conversaciones con los clientes. En lugar de decir "hemos hecho la configuración más robusta", puedes mostrar la categoría en el panel de control y explicar la capa recuperada.
La configuración del cuadro de mandos se explica en la documentación del Cuadro de mandos de seguimiento del lado del servidor TAGGRS.
Un interruptor, no otro proyecto de infraestructura
La mayoría de las agencias ya saben lo pesados que pueden llegar a ser los proyectos de seguimiento.
Suele haber un desarrollador de sitios web, un especialista en GTM, un especialista en etiquetado del lado del servidor, una limitación del CMS y un cliente que quiere el resultado para ayer. Incluso los pequeños cambios de seguimiento pueden convertirse en un largo hilo de implementación.
El Script de Seguimiento Mejorado está diseñado para evitarlo.
Dentro del panel de TAGGRS, configura la función en Características → Optimizar → Script de seguimiento mejorado. Añade el ID del contenedor web GTM, activa Maximizar tu rendimiento, guarda la configuración y sustituye el antiguo fragmento GTM por el código generado.
Ese es el valor práctico. Sin nuevo servidor de etiquetado. Sin proyecto de proxy personalizado. Sin trabajo de infraestructura independiente para la agencia.
Sigues necesitando acceso al código del sitio web o CMS, porque el script tiene que sustituir al fragmento GTM existente. Pero para la mayoría de los equipos, es un cambio menor que reconstruir la configuración de seguimiento.
Para las agencias que gestionan muchas cuentas, la diferencia es aún mayor. Una función que se puede activar y validar en el panel de control es más fácil de vender, más fácil de implantar y más fácil de explicar.
Dónde encaja esto en una configuración de seguimiento resistente
El Script de Seguimiento Mejorado no sustituye a una estrategia de seguimiento adecuada.
Sigues necesitando una buena gestión del consentimiento. Sigues necesitando un contenedor de servidor que funcione. Sigues necesitando nombres de eventos limpios, deduplicación, mapeo de conversión correcto e integraciones de plataforma fiables.
Pero el guión resuelve un punto débil concreto que muchos equipos pasan por alto: la primera carga de la capa de seguimiento.
Una configuración resistente tiene varias capas:
- El script del sitio web se carga de forma fiable.
- Los eventos se envían a un punto final del servidor de origen.
- El contenedor servidor enriquece, controla y reenvía los datos.
- Las cookies y los identificadores se gestionan teniendo en cuenta la privacidad.
- El panel de control muestra si la configuración está produciendo realmente más datos utilizables.
Si la primera capa se rompe, el resto de la configuración no puede ayudar. El Guión de Seguimiento Mejorado refuerza esa primera capa.
Para un diagnóstico más amplio, descarga la guía ¿Cómo de resistente es tu configuración de seguimiento? Te ayuda a encontrar dónde se produce la pérdida de señal y qué solucionar primero.
PREGUNTAS FRECUENTES
¿Es el Script de Seguimiento Mejorado lo mismo que el Seguimiento en el Servidor?
No. El Seguimiento del lado del servidor traslada el procesamiento de los datos a un contenedor del servidor. El Script de Seguimiento Mejorado mejora el script del lado del navegador que inicia el flujo de seguimiento.
Funcionan juntos. El Seguimiento del Servidor se encarga de la ruta del servidor. El Script de Seguimiento Mejorado ayuda a que más peticiones lleguen a esa ruta.
¿Sustituye esto a mi script actual de Google Tag Manager?
Sí. El Script de Seguimiento Mejorado está diseñado como sustituto del script GTM estándar. No ejecutes ambos al mismo tiempo. Los scripts duplicados pueden crear eventos duplicados e informes inexactos.
¿Arreglará esto todas las lagunas de seguimiento?
No. Resuelve una laguna importante: la pérdida a nivel de script antes de que el contenedor servidor reciba la petición.
Todavía hay otros problemas que pueden afectar a la calidad de los datos, como los ajustes de consentimiento, las etiquetas rotas, los eventos duplicados, la falta de clientes contenedores de servidor, el mal mapeo de eventos y los límites de atribución del lado de la plataforma.
¿Por qué es importante un script de seguimiento del sitio web si ya utilizo el Seguimiento en el Servidor?
Porque la primera petición sigue iniciándose en el navegador. Si el script de seguimiento del sitio web está bloqueado, es posible que el contenedor del servidor nunca reciba el evento.
El Seguimiento del lado del servidor mejora lo que ocurre después de que se realice la solicitud. El Script de Seguimiento Mejorado mejora la posibilidad de que la solicitud se realice en primer lugar.
¿Puedo ver el impacto dentro de TAGGRS?
Sí. El panel de control de Analytics incluye categorías de solicitudes, incluido el Script de seguimiento mejorado. Eso te permite validar si el script está activo y ver cómo contribuye al volumen de peticiones.
Para un análisis más profundo, compara los datos del lado del servidor y del lado del cliente en el panel de control en un intervalo de fechas coherente.
¿Esto hace que los anuncios sean visibles para los usuarios con bloqueadores de anuncios?
No. El Script de Seguimiento Mejorado no desbloquea anuncios, banners, ventanas emergentes ni ubicaciones de anuncios en tu sitio web.
Se centra en la medición. Si un usuario con un bloqueador de anuncios visita tu sitio y da su consentimiento, el script ayuda a que la solicitud de seguimiento llegue a tu contenedor del lado del servidor. No cambia lo que el visitante ve en la página.
Así que los usuarios que bloquean los anuncios seguirán bloqueando los anuncios. La diferencia es que la analítica consentida y las señales de conversión tienen más posibilidades de llegar a tu configuración de medición.
