Cómo verificar que tu GTM del lado del servidor (sGTM) está funcionando

"Configuramos GTM del lado del servidor (sGTM), pero no estoy seguro de que realmente esté midiendo a través del servidor." Esta es una preocupación muy común en los equipos que adoptaron sGTM. A diferencia de la configuración tradicional, donde los tags se disparan directo desde el navegador, sGTM agrega un salto de servidor en el medio, lo que hace mucho más difícil ver dónde se rompe el flujo. Puedes creer que lo configuraste bien, pero si el servidor nunca recibe la solicitud, no se registra nada en GA4 ni en Ads.

¿Te suena alguno de estos síntomas?

• Después de migrar a sGTM, tus eventos de GA4 cayeron o dejaron de llegar
• Al revisar el tráfico del navegador, las solicitudes no van a tu propio dominio del servidor de tagging
• Ni una sola solicitud aparece en la vista previa de sGTM
• GA4 funcionaba antes, pero la medición desapareció justo al configurar transport_url

Esta guía organiza cómo verificar que sGTM está funcionando, qué revisar y las fallas más comunes, todo desde una perspectiva práctica y operativa.

Principio básico: ¿por dónde pasa realmente sGTM?

La razón más frecuente por la que la verificación de sGTM sale mal es no visualizar el flujo de datos como una sola línea. Con sGTM, el navegador no envía directo a GA4: un servidor en tu propio dominio (el servidor de tagging) se ubica en el medio. Empieza por internalizar este flujo.

Etapa	Qué sucede	Error típico
① Envío	El navegador envía a un servidor de tagging first-party (por ejemplo gtm.example.com)	transport_url no configurado, así que va directo a Google
② Recepción	El contenedor en el servidor (Cloud Run, etc.) recibe la solicitud	Contenedor no desplegado / URL incorrecta
③ Reenvío	El servidor distribuye y reenvía a GA4, Ads, Meta	El mapeo de cliente/tag está mal configurado

El punto clave: sGTM tiene dos contenedores, un "contenedor web" (lado navegador) y un "contenedor servidor" (lado servidor). Aunque un tag se dispare del lado del navegador, si su destino no apunta al servidor, simplemente va directo a Google como antes; eso no es "pasar por sGTM". El objetivo completo de sGTM es hacer que las cookies sean first-party a través de tu propio dominio, para que se vean menos afectadas por el ITP (la prevención de rastreo de Safari) y los bloqueadores de anuncios. Por eso mismo necesitas verificar si realmente se está pasando por el servidor.

Paso 1: revisa el destino del navegador (transport_url)

Primero, observa hacia dónde está enviando el navegador. Si esto no apunta a tu propio servidor de tagging, sGTM ni siquiera comienza.

1. Abre la página que quieres revisar y abre la pestaña "Network" en las DevTools
2. Filtra por collect
3. Observa la solicitud /g/collect que se dispara con la interacción en la página y revisa su dominio de destino
4. Confirma que el destino sea un dominio first-party tuyo, como gtm.example.com (si sigue siendo google-analytics.com o analytics.google.com, no está configurado)

Lo que apunta al navegador hacia tu propio dominio es el parámetro transport_url en el tag de configuración de GA4 (o Google tag). Si está vacío o mal escrito, el navegador sigue enviando directo a Google.

Error común: pusiste la URL de tu contenedor de servidor en transport_url, pero el DNS de ese subdominio no apunta al servidor, así que la solicitud nunca llega y falla. Aunque el dominio de destino se vea correcto, que ese dominio realmente resuelva al servidor es un asunto aparte.

Paso 2: ¿el contenedor del servidor está desplegado y recibiendo?

Aunque el destino sea tu propio dominio, si el contenedor del servidor detrás de él no está corriendo, no se recibe nada.

• ¿El servidor de tagging (Cloud Run u otro hosting) está desplegado y en funcionamiento?
• Al acceder a la URL del servidor de tagging (por ejemplo https://gtm.example.com), ¿devuelve una respuesta saludable?
• ¿El dominio de destino del Paso 1 coincide con el dominio donde realmente desplegaste el servidor?

Lo que esto te dice: si el servidor existe y puede aceptar solicitudes (②). Lo que no te dice: si luego reenvía correctamente a GA4 o Ads (el ③ viene en el siguiente paso).

Error común: el contenedor puede estar desplegado, pero si olvidaste el Container Config ID requerido, el servidor arranca vacío: recibe solicitudes pero no procesa nada. "Está corriendo" no significa "tiene la configuración cargada."

Paso 3: rastrea de recepción a reenvío en la vista previa de sGTM

sGTM tiene un modo de vista previa dedicado al lado del servidor. Este es el corazón de la verificación.

• Abre "Preview" en el panel de administración de sGTM (contenedor de servidor)
• Abre el sitio en otra pestaña, interactúa con él y observa si llegan solicitudes a la vista previa
• Para cada solicitud que llegue, confirma que el tag de GA4, el tag de Ads, etc. se disparen, y que los destinos (Outgoing HTTP Requests) sean los que esperas

Lo que esto te dice: que el servidor está recibiendo la solicitud y reenviándola a cada destino (la cadena completa ② → ③). Solo cuando puedes ver esto puedes afirmar que "pasa por sGTM."

Error común: si no llega ninguna solicitud a la vista previa, el problema está más arriba (Pasos 1–2), no en el servidor. Por el contrario, si llegan solicitudes pero el tag de GA4 no se dispara, sospecha de un cliente, trigger o mapeo mal configurado. "No llega" y "llega pero no se reenvía" te llevan a lugares completamente distintos.

Paso 4: verifica el comportamiento de las cookies first-party y la resistencia a bloqueadores de anuncios

El modo de vista previa confirma el flujo de datos, pero dos de los beneficios principales de sGTM (cookies con mayor vida útil y menor impacto de los bloqueadores de anuncios) necesitan sus propias verificaciones.

Revisa la expiración de cookies en Safari

Abre Safari en el sitio que quieres revisar y ve a Develop > Show Web Inspector > Storage > Cookies. Busca tus cookies de tracking (_ga, _gcl_aw, o cualquier cookie personalizada que configure tu sGTM). Revisa la fecha de expiración:

• Si muestra 1 a 2 años desde hoy, la cookie se está configurando correctamente como first-party por parte de tu servidor.
• Si muestra 7 días desde hoy, el ITP de Safari la está limitando; esto suele significar que la dirección IP del subdominio de tu servidor de tagging no coincide con la IP de tu dominio principal, por lo que Safari lo clasifica como un "CNAME cloak" y acorta la vida útil.

Esto es fácil de pasar por alto porque Chrome no muestra el mismo comportamiento. Relacionado: cómo el ITP de Safari provoca la pérdida de conversiones.

Prueba con un bloqueador de anuncios activo

Activa un bloqueador de anuncios popular (uBlock Origin, AdGuard) en tu navegador, carga tu sitio y revisa la pestaña Network:

• ¿Las solicitudes /g/collect siguen llegando a tu dominio first-party?
• ¿La vista previa de sGTM sigue mostrando solicitudes entrantes?

Ten en cuenta que las principales listas de filtros (EasyPrivacy, AdGuard) ahora incluyen reglas que apuntan a patrones comunes de subdominios de sGTM, como los prefijos sgtm. o gtm.. Si tu subdominio está siendo bloqueado, considera elegir un nombre de subdominio menos obvio. Para más información sobre cómo los bloqueadores de anuncios afectan el tracking, consulta cómo los bloqueadores de anuncios bloquean píxeles y qué hacer al respecto.

Revisa los logs de Cloud Run para detectar fallas silenciosas en producción

La vista previa es una herramienta de depuración: no te dice qué pasa en producción cuando no estás mirando. sGTM no tiene un panel de salud integrado, así que las fallas en producción son silenciosas a menos que las monitorees activamente.

En la consola de Google Cloud, ve a Cloud Run > tu servicio de tagging > Logs (o usa Logs Explorer) y busca:

• Entradas de nivel Error o Warning: suelen indicar que un tag no se está reenviando, una variable mal configurada, o un timeout al alcanzar un endpoint de destino.
• Caídas en el volumen: una disminución repentina en el volumen de solicitudes puede indicar un cambio de DNS, un certificado vencido o un problema de escalado del contenedor, ninguno de los cuales aparece en el modo de vista previa.
• Salida de logToConsole: si usas un tag Logger o plantillas personalizadas que llaman a la API logToConsole, su salida aparece en los logs de stdout. Filtra con logName: "stdout" en Logs Explorer.

Configura una alerta de Cloud Monitoring sobre la tasa de errores o el conteo de solicitudes para que te notifiquen cuando algo falle, en lugar de descubrirlo días después cuando caigan los números de conversión.

Fallas comunes con sGTM

Cuando no estás pasando por sGTM, la causa suele reducirse a lo siguiente. Sospecha de ellas en este orden.

1. transport_url no está configurado

La más frecuente. Si no agregas transport_url al tag de configuración de GA4 (Google tag) en el lado del contenedor web, el navegador sigue enviando directo a Google y el servidor nunca se toca.

2. El contenedor del servidor no está desplegado / está detenido

Cuando no has desplegado el contenedor en el hosting (Cloud Run, etc.), o está detenido. El Paso 2 verifica si la URL responde.

3. El DNS del subdominio first-party no está configurado

Aunque prepares un subdominio como gtm.example.com, las solicitudes no llegarán a menos que el DNS apunte al servidor. Revisa la configuración de DNS y la validez del certificado (HTTPS).

4. Mapeo o cliente mal configurado

Casos en los que el servidor recibe pero no reenvía: el cliente de GA4 no está habilitado, o las condiciones del trigger del tag no coinciden. Rastrea el reenvío en la vista previa del Paso 3.

Lo que revisar en tu propia máquina no te puede decir

Todos los pasos anteriores son útiles, pero verificar una sola vez en tu propia máquina tiene dos limitaciones estructurales.

1. Tu entorno no es el entorno de tus visitantes. Uno de los propósitos principales de sGTM es reducir el impacto del ITP (cómo el ITP de Safari provoca la pérdida de conversiones) y de los bloqueadores de anuncios. Sin embargo, si el navegador con el que verificas es Chrome sin extensiones, no puedes reproducir las mismas condiciones que intentabas sortear. Las pérdidas que aparecen en Safari real u otro entorno no se mostrarán en tu única prueba local.
2. Las conversiones que involucran un clic en un anuncio son difíciles de verificar. Para ver correctamente si "realmente se rastrea a través del servidor vía un anuncio", necesitarías hacer clic en un anuncio activo para recrear la ruta, lo cual conlleva el riesgo de una violación de política publicitaria por autoclick.

Como sGTM inserta un salto de servidor, es estructuralmente propenso a que "funcione en mi máquina, pero desaparezca bajo las condiciones reales de los visitantes." Por eso es tan importante verificar en la ruta real de producción.

Un checklist para verificar con confianza

Empieza por lo que es gratis y fácil, y ve resolviendo estos puntos en orden.

• ¿El destino del navegador (/g/collect) es un dominio first-party tuyo (transport_url)?
• ¿El DNS de ese subdominio apunta al servidor, con HTTPS válido?
• ¿El contenedor del servidor (Cloud Run, etc.) está desplegado y en funcionamiento?
• ¿El Container Config ID está ingresado correctamente?
• ¿Llegan solicitudes a la vista previa de sGTM?
• Para las solicitudes que llegan, ¿los tags de GA4/Ads se disparan y reenvían?
• ¿Los destinos (propiedad de GA4, ID de conversión de Ads) son los que esperas?
• ¿Falta algo bajo condiciones reales de visitantes, como un Safari real?
• En Safari, ¿las fechas de expiración de las cookies de tracking son de 1 a 2 años (sin estar limitadas a 7 días por el ITP)?
• Con un bloqueador de anuncios activo, ¿las solicitudes siguen llegando a tu dominio de tagging first-party?
• ¿Los logs de Cloud Run están libres de entradas de Error/Warning y caídas de volumen?

Preguntas frecuentes

P. ¿Por qué cayeron mis eventos de GA4 después de configurar sGTM? R. Un caso común: en el momento en que configuraste transport_url, el destino del navegador cambió a tu propio servidor, pero ese servidor (despliegue del contenedor, DNS) no estaba listo, así que la solicitud llega a un callejón sin salida. Recorre los Pasos 1–3, revisando destino, recepción y luego reenvío en orden.

P. Si los tags se disparan del lado del navegador, ¿significa que sGTM está funcionando? R. No. Aunque el tag del contenedor web se dispare, si el destino sigue siendo Google (transport_url no configurado), es el envío directo tradicional y el servidor no está siendo utilizado. Solo puedes juzgarlo después de confirmar que el destino es tu propio dominio y que el servidor está recibiendo.

P. No llegan solicitudes a la vista previa de sGTM. R. Es muy probable que sea un problema anterior al servidor, no del servidor mismo. Revisa ① la configuración de transport_url, ② el DNS del subdominio, y ③ el estado de despliegue del contenedor. "No llega nada a la vista previa" aísla el problema en "no está llegando al servidor."

P. GA4 está funcionando, pero solo las conversiones de Google Ads no llegan. R. Un caso clásico de brecha de aislamiento: en el contenedor de servidor de sGTM, GA4 reenvía correctamente pero el tag/mapeo de Ads no está configurado. En la vista previa, confirma que la solicitud saliente para Ads realmente se esté enviando. Relacionado: qué revisar cuando las conversiones de Google Ads no se registran.

P. ¿También puedo verificar Meta y las conversiones mejoradas a través de sGTM? R. El enfoque es el mismo: rastrear el reenvío hacia cada destino en la vista previa. Para verificaciones individuales, consulta cómo verificar la Meta CAPI (Conversions API) y cómo verificar que las conversiones mejoradas se envían correctamente, y para el panorama completo, la guía de tracking de conversiones de GA4.

Conclusión: no te quedes solo en el disparo, verifica que pase por el servidor y se reenvíe

Verificar sGTM no se completa solo con el disparo de tags del lado del navegador. Lo que importa es ir más allá: confirmar que el destino apunta a tu propio dominio (①), el servidor recibe (②), y reenvía correctamente a GA4 y Ads (③), es decir, que toda esta cadena está conectada en producción. Si se detiene antes de llegar al servidor, no importa cuán saludable se vea el disparo del lado del navegador: los datos no se registran.

ConversionOK ejecuta tu página real en un navegador independiente y aislado, e intercepta las solicitudes que efectivamente se envían a tu servidor de tagging, para luego verificarlas, sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Comienza con una verificación estática gratuita para confirmar el punto de entrada de tu medición del lado del servidor.