Si ya utiliza server-side GTM, no cree un segundo canal de medición de Google competidor solo para agregar Google Tag Gateway. El patrón combinado recomendado por Google separa dos rutas del mismo origen: una ruta de script reenvía solicitudes gtm.js o gtag.js a Google, mientras que una ruta de colección reenvía eventos de medición a su servidor de etiquetado. El contenedor del servidor sigue siendo el lugar donde se procesan y enrutan los eventos.
La arquitectura combinada
Una configuración del mismo origen puede utilizar rutas como www.example.com/scripts para la carga de scripts de Google propios y www.example.com/metrics para el contenedor del servidor. La CDN o el equilibrador de carga enruta cada prefijo a un origen diferente. Google advierte que ambas rutas deben estar sin usar y no deben contener /gtm.
El navegador carga el contenedor web o la etiqueta de Google a través de la ruta del script. Luego, la etiqueta de Google se configura para enviar mediciones a la ruta de recopilación. El cliente sGTM reclama esa solicitud, produce un evento y activa las etiquetas de servidor apropiadas.
Cuando ejecutar ambos es útil
La combinación es útil cuando desea los beneficios de resistencia del navegador de la carga de scripts propios y también necesita las transformaciones, la minimización de datos, los destinos que no son de Google o la observabilidad de sGTM. Google recomienda explícitamente la carga de scripts propios junto con el etiquetado del lado del servidor para una configuración duradera.
Es menos útil cuando GTG solo duplicaría la funcionalidad ya proporcionada por un cargador sGTM de origen y una ruta de recopilación correctamente configurados. Audita las rutas actuales antes de agregar otra regla. La arquitectura debería volverse más clara después del cambio, no simplemente contener más productos.
La trampa del evento duplicado
El patrón peligroso es enviar la misma conversión de Google directamente a través de una ruta de reenvío GTG y también enviarla a través de sGTM, donde una etiqueta de servidor la envía nuevamente. Ambas solicitudes de red pueden tener éxito, lo que deja conversiones infladas que parecen una recuperación mejorada.
Define un propietario de entrega para cada evento y destino. Los ID de transacciones estables o los ID de eventos siguen siendo útiles, pero la deduplicación debe ser un mecanismo de seguridad, no la arquitectura principal. Obtenga una vista previa de los contenedores del navegador y del servidor juntos y cuente las solicitudes de destino salientes.
El mismo origen es mejor que un subdominio de seguimiento aleatorio
Google documenta el mismo origen como la mejor práctica para la seguridad y durabilidad de las cookies configuradas en el servidor. Una ruta en el host del sitio web, como www.example.com/metrics, tiene el mismo origen. Un subdominio como metrics.example.com es propio pero no tiene el mismo origen.
El enrutamiento del mismo origen normalmente requiere una CDN o un balanceador de carga y una cuidadosa precedencia de ruta. Reenvíe todas las cookies y cadenas de consulta requeridas por el servidor de etiquetado, enrute todas las rutas del cliente, incluida la subruta documentada /_/*, y verifique el endpoint de estado antes de cambiar las etiquetas de producción.
El consentimiento y la privacidad aún controlan el flujo
La notificación por parte de primera persona es una decisión de transporte, no un permiso. Inicialice los valores predeterminados de consentimiento antes de la medición, pase el estado de consentimiento a la solicitud de recopilación y configure las etiquetas del servidor para que las opciones de publicidad o almacenamiento denegadas se manejen según lo diseñado.
Minimizar los datos en el límite del servidor. Revisa qué cookies, encabezados, parámetros de consulta y campos de eventos ingresan al contenedor del servidor y luego permita solo los campos que cada destino necesita. GTG coloca cookies propias que no son de Google en su propia ruta de reenvío, pero su ruta de recopilación sGTM tiene sus propias responsabilidades de manejo de datos.
Una regla de decisión clara
Si no tiene un sGTM y solo necesita mediciones compatibles con Google, el GTG por sí solo puede ser suficiente. Si tiene sGTM, habilite el script de Google propio que sirve como parte de esa arquitectura y mantenga la recopilación de mediciones apuntando al contenedor del servidor.
Si dos equipos poseen GTG y sGTM, publica una hoja de ruta y una matriz de propiedad del evento antes del lanzamiento. Una regla CDN, una configuración de contenedor web y una etiqueta de servidor pueden cambiar el destino del mismo evento; la superposición no documentada es la fuente habitual de duplicación.
Usa dos rutas, no dos propietarios de mediciones
La ruta del script y la ruta de la colección son intencionalmente diferentes. La ruta del script carga el código de Google propio; la ruta de recopilación envía eventos a sGTM. No permita que ambas rutas proporcionen de forma independiente la misma conversión.
Configurar GTG con server-side GTM
Los menús exactos varían según la CDN, pero las responsabilidades y la secuencia de validación siguen siendo las mismas.
- 01
Confirma que el contenedor del servidor esté listo para producción
Usa una implementación de etiquetado de producción, un servidor de vista previa funcional, controles de acceso, monitorización y un dominio personalizado antes de cambiar la ruta del navegador.
- 02
Reserve dos rutas del mismo origen no utilizadas
Elige una ruta de script como /scripts y una ruta de colección como /metrics. Ninguna ruta puede entrar en conflicto con el sitio ni contener /gtm.
- 03
Dirija la ruta de recolección a sGTM
Configura la CDN o el equilibrador de carga para reenviar el prefijo de colección completo, las cookies y las cadenas de consulta al servidor de etiquetado, incluidas las rutas requeridas por los clientes del servidor.
- 04
Añade la URL de la colección en la configuración del contenedor del servidor
Configura la URL del contenedor del servidor en la URL del mismo origen, incluido su prefijo de ruta, luego confirme que el cliente esperado reclama una solicitud de vista previa.
- 05
Dirija la ruta del script para GTG
Reenvíe el prefijo de secuencia de comandos reservado al origen del gateway de Google y actualice la fuente gtm.js o gtag.js para cargar a través de esa ruta.
- 06
Apunte los eventos de Google a la ruta de recopilación
Configura server_container_url o la configuración de etiqueta de Google equivalente en el endpoint /metrics para que la medición ingrese a sGTM en lugar de ir directamente al mismo destino dos veces.
- 07
Configurar clientes, etiquetas y consentimiento
Verifica la prioridad del cliente, las transformaciones de eventos, las comprobaciones de consentimiento, las etiquetas de destino y los identificadores de eventos estables dentro del contenedor del servidor.
- 08
Prueba la ruta completa
Confirma que el script se carga desde /scripts, una solicitud llega a /metrics, el cliente del servidor la reclama y sale exactamente una solicitud esperada para cada destino.
- 09
Monitorear después del lanzamiento
Alerte sobre fallos de salud y volúmenes inusuales, revise los diagnósticos de destino y concilie compras o clientes potenciales con la verdad del sistema de origen.
Ejecuta capas complementarias, no tuberías paralelas
GTG y sGTM funcionan bien juntos cuando el gateway maneja la entrega de scripts propios y sGTM posee el procesamiento de eventos. El patrón de dos caminos hace que ese límite sea visible y comprobable.
La configuración fallo cuando la misma conversión tiene dos propietarios de entrega. Documenta rutas, preserve la identidad de un evento, pruebe los estados de consentimiento y cuente las solicitudes que realmente salen del servidor.
GTG más sGTM: preguntas comunes
¿Todas las configuraciones de sGTM deberían usar también Google Tag Gateway?
Google recomienda el servicio de scripts propios, pero primero audita tu cargador y tus rutas actuales. Algunas configuraciones de sGTM ya ofrecen dependencias propias y es posible que solo necesiten una actualización de configuración.
¿Pueden GTG y sGTM utilizar la misma ruta?
El patrón CDN de Google utiliza rutas separadas: una para scripts y otra para recopilación de eventos. Las rutas separadas previenen conflictos de origen y aclaran las responsabilidades.
¿Cómo evito conversiones duplicadas de Google?
Elige un remitente para cada conversión. Si sGTM envía la solicitud de destino de Google, no envíe también una solicitud de navegador directa equivalente. Verifica el recuento de solicitudes salientes en la vista previa y en el diagnóstico de destino.
¿Es un subdominio lo mismo que una publicación del mismo origen?
No. Un subdominio es propio, pero mismo origen significa el mismo esquema, nombre de host y puerto que el sitio web. Google enumera ambas como compatibles con cookies establecidas en el servidor, pero considera que las del mismo origen son la mejor práctica.
¿Qué ruta debería enviar eventos Meta o TikTok?
Esas solicitudes de destino deben crearse mediante etiquetas de servidor en sGTM u otra integración de servidor. La ruta del script de Google de GTG no es una ruta API de conversión general que no sea de Google.