El tráfico de ChatGPT Atlas llega sin referente y cae en el agujero negro: aparece como «Directo» y Google Analytics 4 (GA4) no lo rescata del lado cliente. Pero hay una capa donde sí queda una señal — el servidor.
En el post sobre Atlas y Comet dejamos ese cabo suelto: lo que el navegador borra necesita otra capa. Y el problema de raíz es el mismo de siempre — el referrer stripping (eliminación del referente). Este post desarrolla la respuesta: medir del lado del servidor.
Dónde se pierde la señal: cliente vs servidor
Del lado cliente, el navegador decide qué propaga. Referente, cookies, parámetros de la dirección — el navegador elige qué viaja en cada clic, y tú no lo controlas. Según MDN, el contenido del encabezado Referer lo define la política de referente del propio navegador, que puede recortarlo o, con no-referrer, omitirlo entero.
Los navegadores de IA aprovechan justo eso: recortan el referente antes de que GA4 lo vea. Para tu analítica, la visita nace sin un origen definido.
Del lado del servidor, el orden es distinto. Tu infraestructura ve la petición HTTP (request) cruda — agente de usuario (user-agent), dirección IP, encabezados, dirección completa — antes de cualquier recorte que el navegador imponga después. Según la documentación de Google, la medición del lado del servidor (server-side) mueve la recolección desde el navegador hacia un entorno que tú controlas.
Esa diferencia de orden es la tesis de este post. El cliente te muestra lo que el navegador quiso contar; el servidor ve lo que de verdad llegó.
Qué es el tracking server-side
El tracking server-side mueve la recolección de datos del navegador a tu propio servidor o borde (edge). En vez de que el navegador habla directo con Google, los datos pasan primero por una capa tuya — donde los ves, los enriqueces y decides qué reenviar.
No es una técnica nueva. Según Simo Ahava, el etiquetado del lado del servidor (server-side tagging) consiste en correr un contenedor de Google Tag Manager en un entorno servidor. Existe desde mucho antes de la crisis de atribución de IA.
Lo nuevo es el caso de uso. La medición server-side se diseñó para rendimiento, seguridad y control del dato; hoy gana un nuevo motivo de valor — recuperar la señal que los navegadores de IA recortan del lado cliente.
El cambio mental es de propiedad. En el modelo cliente, Google recibe el dato y tú lo consultas después; en el modelo servidor, el dato pasa primero por ti. Esa inversión es la que abre la puerta a ver lo que el navegador, por su cuenta, decidió no propagar.
Las tres rutas para medir del lado servidor
No hay una sola forma de medir en el servidor. Hay tres rutas, y cada una sirve para un caso distinto según tu stack.
La primera es server-side GTM: un contenedor de Google Tag Manager que corre en tu servidor. Según la documentación de Google, los hits pasan por tu contenedor — alojado en una infraestructura que tú gestionas — antes de llegar a Google.
La segunda es el protocolo de medición (Measurement Protocol) de GA4. Según la documentación de Google Analytics, tu servidor envía eventos directo a la API de GA4 por HTTP, incluyendo interacciones de servidor a servidor que el JavaScript del navegador nunca registró. Otro caso de uso a este tipo de medición se usa para eventos que ocurren fuera de línea y necesitan enriquecer los datos, pero eso será tema de otro post.
La tercera es la medición en el borde (edge). Según la documentación de Cloudflare, un Worker recibe la petición entrante en el borde de la red y expone sus metadatos crudos antes de que el navegador entre en juego.
Tabla 1 — las tres rutas de medición server-side. La última columna, «Cuándo usarla», es la decisión que tomas según tu stack.
| Ruta | Cómo funciona | Qué recupera | Cuándo usarla |
|---|---|---|---|
| Server-side GTM (contenedor en servidor) | GA4 envía los hits a tu contenedor antes que a Google | Control y enriquecimiento del dato, des-duplicación | Cuando quieres control total y ya tienes infraestructura |
| Measurement Protocol de GA4 | Tu servidor manda eventos directo a la API de GA4 | Eventos y sesiones que el JS del navegador nunca registró | Cuando el hit nace en el backend — un pago, un webhook, sin navegador |
| Medición en el edge (Cloudflare Workers / similar) | Registras la petición en el borde antes del navegador | La petición HTTP cruda — user-agent, IP, dirección — antes del recorte | Cuando ya operas en el edge o quieres la señal más temprana posible |
La lectura rápida: GTM server-side te da control, el Measurement Protocol captura lo que nace sin navegador, y el edge ve la señal cruda antes que nadie. No compiten — muchas configuraciones combinan dos.
Un ejemplo concreto lo aterriza. Registras la petición cruda en el edge para capturar el user-agent del navegador de IA, y usas el Measurement Protocol para enviar a GA4 el evento de conversión que nace en tu backend. El edge ve quién llegó; el Measurement Protocol reporta qué hizo, y server-side GTM limpia el dato en medio.
Qué recupera de verdad — y qué no
El server-side recupera la señal que el cliente recorta — el user-agent del navegador de IA, los parámetros de la dirección, la petición cruda — y te deja enriquecer y des-duplicar antes de reportar.
Enriquecer significa añadir contexto que el navegador no manda — geolocalización por IP, una categoría de campaña, un identificador de tu CRM. Des-duplicar significa cerrar la doble cuenta cuando un mismo evento llega por dos caminos. Las dos cosas ocurren en tu capa, no en la de Google.
Que la unión a nivel servidor funciona a escala no es teoría. Según Attrifast, su benchmark 2026 unió 41,2 millones de sesiones con 168.000 pagos de Stripe a nivel servidor, emparejando cada sesión con su origen para atribuir ingresos que el lado cliente habría perdido.
Pero hay un límite que ningún proveedor debería esconder. Si el agente no manda ninguna señal, el servidor no la inventa — según MDN, una política no-referrer omite el referente por completo, y lo que nunca se envió no se reconstruye.
Por eso decimos «ayuda a recuperar», nunca «garantiza el 100%». El servidor rescata lo que el navegador recortó en tránsito; no resucita lo que el agente decidió no mandar. La diferencia entre las dos cosas es el user-agent y demás señales que el borde ve crudas, las mismas que usamos para distinguir tráfico no humano en crawlability para bots de IA.
Madbotz en el edge
Madbotz ya opera lógica en el edge para su propio rastreador, el MadbotzVisibilityBot. Según la documentación de Cloudflare, el Worker expone los metadatos de cada petición en el borde — y ahí es donde nuestro bot se identifica y registra su paso, como documentamos en su página de identidad.
Aún seguimos en proceso, no un producto cerrado. Corremos la capa edge para nuestro propio bot y el blog que estás leyendo; no vendemos una caja mágica que rescata cada sesión.
Lo decimos para fijar la expectativa correcta: el server-side es una capa de ingeniería, no un interruptor. Quien te prometa recuperación total te está vendiendo humo.
Una nota sobre privacidad
Mover la medición a tu servidor te da más control sobre el dato, no menos responsabilidad legal. Según la documentación de Google, el server-side tagging protege mejor los datos del visitante en un entorno que el cliente gestiona — pero «mejor protegido» no es lo mismo que «cumplido».
Más control implica más decisiones: qué guardas, cuánto tiempo, qué reenvías a terceros. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en México y el Reglamento General de Protección de Datos (GDPR) en Europa aplican igual, y el equipo legal del cliente debe validar el setup antes de enviar nada.
La privacidad del lado servidor merece su propio post — aquí solo dejamos la advertencia, no el manual.
Preguntas frecuentes
¿El tracking server-side recupera el tráfico de ChatGPT Atlas?
Recupera la señal que el navegador recorta antes de que GA4 la vea, no lo que el agente nunca envió. Si la petición llega con user-agent y URL completa, el servidor los ve crudos; si el agente no manda nada, el servidor no lo inventa.
¿Necesito server-side GTM o me basta el Measurement Protocol?
Depende de tu stack tecnológico. Server-side GTM te da un contenedor con control y enriquecimiento del dato; el Measurement Protocol manda eventos directo a la API de GA4 desde tu backend. Si solo necesitas registrar eventos que nacen en el servidor, el Measurement Protocol basta.
¿El tracking server-side rompe la privacidad?
Te da más control sobre el dato, no menos responsabilidad legal. El equipo legal del cliente debe validar el cumplimiento con la LFPDPPP en México y el GDPR en Europa antes de enviar nada.
¿El tracking server-side reemplaza al canal de tráfico de IA de GA4?
No, lo complementa. El canal del lado cliente clasifica el tráfico que sí deja rastro; el server-side recupera parte de lo que el navegador recorta. Son dos capas, no una alternativa a la otra.
Cierre
El server-side es la capa que el post anterior dejó pendiente: donde el canal de tráfico de IA clasifica lo que deja rastro, el servidor recupera parte de lo que el navegador borró en tránsito.
Tres ideas para llevarte:
- El cliente muestra lo que el navegador quiso contar; el servidor ve lo que de verdad llegó — esa es la señal que se recupera.
- Hay tres rutas: server-side GTM para control, Measurement Protocol para lo que nace sin navegador, edge para la señal más temprana.
- El server-side ayuda a recuperar, no garantiza el 100% — lo que el agente nunca mandó no se reconstruye.
Empieza por la causa, no por la medición: el tráfico de IA nace de tu visibilidad. Antes de armar la capa servidor, asegúrate de que la IA te ve y te cita — eso lo mides con el AI Visibility Score, el mismo motor de 130+ check items con el que evaluamos nuestro propio sitio, y que vigila si los modelos te mencionan con el monitoreo multi-LLM.