¿Qué cambia respecto al tagging tradicional?
En una implementación client-side con múltiples tags, el navegador puede comunicarse directamente con varios proveedores. El alcance depende de los tags instalados y del consentimiento.
En una implementación server-side, las solicitudes configuradas van al contenedor server. Ahí puedes validar, transformar o bloquear datos antes de reenviarlos; otros tags que sigan instalados en el navegador aún pueden llamar directamente a proveedores. Google describe los clients y el procesamiento.
| Aspecto | Contenedor web (client-side) | Contenedor server (sGTM) |
|---|---|---|
| Dónde corre | En el navegador del usuario | En un servidor separado del navegador |
| Destino de las solicitudes | Endpoints configurados en cada tag | Endpoint server para eventos encaminados; otros tags pueden seguir enviando desde el navegador |
| Control sobre el payload | Configuración en el cliente | Filtros y transformaciones posibles antes de los envíos salientes |
| Carga en el navegador | Depende de scripts y tags instalados | Puede reducir envíos o scripts de terceros si se migran; requiere medición |
| Contexto de cookies | Depende de cada implementación | Dominio propio puede habilitar cookies de servidor; la URL predeterminada no ofrece esos beneficios |
| Ventaja | Menos infraestructura propia | Más control sobre datos y destinos configurados |
| Desventaja | Menor control sobre peticiones directas de terceros | Complejidad de configuración, privacidad y operación |
| Costo de infraestructura | Sin servidor de tagging propio; pueden existir otros costos | Servidor, red, observabilidad y posible CDN/balanceador |
La pregunta no es cuál gana siempre: define qué envíos quieres controlar, qué beneficio puedes verificar y cuánto cuesta sostenerlo. Un cambio de transporte por sí solo no garantiza mejoras de rendimiento, atribución o privacidad.
Recupera señal sin montar complejidad innecesaria
Medimos dónde se pierde información en tu operación y te decimos si server-side tagging es la respuesta o si hay una prioridad anterior.
- 1
Diagnóstico gratuito de tu stack GMP
Un especialista revisa tu implementación actual (GA4, GTM, DV360, Ads) y te dice qué priorizar primero.
- 2
Plan de acción a medida
Sales de la llamada con next steps concretos para tu cuenta, no con una plantilla genérica.
- 3
Sin compromiso, sin venta forzada
Hablas con un especialista técnico, no con un vendedor. Si no encajamos, te lo decimos.
Respuesta a la brevedad
Diagnosticar mi pérdida de señal
Completa el form y coordinamos una asesoría sobre tu caso.
Cargando el formulario seguro de HubSpot…
No pudimos cargar el formulario. Puedes escribirnos a hola@leadaki.com .
Este formulario lo provee HubSpot y los datos que envíes se procesan allí. Consulta nuestra política de privacidad .
Sin compromiso · Google Marketing Platform Sales Partner
sGTM no reemplaza la captura: GTM web no es obligatorio
El contenedor server necesita una fuente de solicitudes, no necesariamente un contenedor web de GTM. Puedes configurar el Google tag con gtag.js directo o dentro de GTM web para enviar a la URL del servidor; también pueden entrar solicitudes de app o backend mediante un protocolo y client compatibles. Para el ejemplo directo, Google documenta server_container_url; para otras fuentes, explica cómo configurar clients y envío de datos en la guía de envío.
Es decir: sGTM complementa la instrumentación de origen, sea GTM web, gtag.js u otra fuente. Si el origen tiene eventos o conversiones duplicados, el servidor no los corrige automáticamente. Inventaria las rutas activas antes de migrar.
¿Por qué durabilidad es el argumento más fuerte?
El argumento de durabilidad tiene condiciones: un endpoint first-party y cookies configuradas por el servidor pueden aportar beneficios frente a una URL predeterminada ajena al sitio; las restricciones del navegador y el consentimiento siguen aplicando. El contenedor te permite inspeccionar y transformar las solicitudes que recibe, no todos los datos que alguna vez recolectó el sitio. Opciones y alcance de cookies según Google.
Enhanced Conversions y Consent Mode pueden coexistir con esta arquitectura, pero requieren configuración y consentimiento adecuados; sGTM no los activa ni garantiza modelado o recuperación de señal por sí solo.
El requisito de dominio
Para servir el tagging en contexto first-party, Google describe dos opciones: una ruta del mismo origen, como https://www.example.com/metrics (recomendación de Google), o un subdominio como https://metrics.example.com. La ruta en el mismo origen requiere configurar una CDN o un balanceador de carga que reenvíe solicitudes; el subdominio requiere ajustes de DNS, pero no necesariamente ese proxy. El dominio predeterminado del proveedor funciona en contexto de terceros. Compara las tres opciones en la guía oficial de dominio propio.
No es un detalle de implementación: el dominio predeterminado ajeno al sitio no ofrece el mismo acceso a cookies escritas por el servidor; tanto la ruta en el mismo origen como el subdominio propio figuran entre las opciones first-party documentadas por Google. Comprueba las cookies y las solicitudes en tu despliegue. Es también el punto donde sGTM se cruza con el Google Tag Gateway, una solución distinta de transporte que puede compartir infraestructura de CDN.
¿Cuáles son los beneficios reales?
Google agrupa los motivos en tres:
1. Mejores controles de privacidad
El contenedor server puede actuar como filtro para los envíos que pasan por él: decide qué parámetros y encabezados se reenvían a cada destino. Comprueba cada solicitud saliente; otros scripts del navegador pueden seguir transmitiendo datos directamente y un endpoint first-party no implica anonimización automática. La vista previa permite inspeccionar requests entrantes y salientes.
Esto no reemplaza la gestión de consentimiento. Sigues necesitando Consent Mode v2 correctamente implementado.
2. Mejor performance del cliente
Si retiras scripts y envíos client-side redundantes, el navegador puede hacer menos trabajo. Compara carga y solicitudes antes/después: añadir sGTM sin retirar nada no mejora automáticamente el rendimiento.
3. Mejor calidad de datos
Puedes enriquecer eventos con datos permitidos del backend cuando exista una integración y una base de tratamiento adecuada. Define qué datos recibe cada destino y verifica la paridad; el enriquecimiento no implica por sí solo mejoras en Smart Bidding.
¿Cuánto cuesta la infraestructura?
Aquí es donde muchos proyectos se caen. El contenedor server no es gratis: corre en tu nube y factura como cualquier servicio.
Como referencia de configuración, no cotización, Google documenta para Cloud Run aproximadamente USD 45 al mes por instancia de 1 vCPU y 0,5 GB con CPU siempre asignada. Recomienda 2 instancias para reducir el riesgo ante una caída, aunque permite menos o más; estima 35–350 solicitudes por segundo con 2–10 instancias según los tags. Precio final y capacidad dependen de región, carga, escalado, configuración y tarifas vigentes: calcula con tu volumen en la guía y calculadora que enlaza Google.
A esa base hay que sumarle:
- CDN o balanceador, si eliges servir el endpoint bajo una ruta del mismo origen; otras topologías tienen costos distintos.
- Tráfico de red saliente hacia cada proveedor.
- Logging y monitoreo: evalúa retención y volumen; Google advierte de posibles cargos importantes por request logging a gran escala y propone desactivarlo cuando no se necesita. Conserva la observabilidad exigida por tu operación. Detalle de costos e infraestructura.
El aprovisionamiento automático desde Tag Manager crea un proyecto de Google Cloud y un servidor sobre Cloud Run, pero esa configuración inicial está pensada para pruebas: Google aclara que para tráfico real hay que actualizar la infraestructura. Si vienes de un despliegue viejo sobre App Engine y ya migraste a Cloud Run, deshabilita la aplicación de App Engine para evitar cargos inesperados.
¿Cuándo conviene implementarlo?
Antes de decidir, Google sugiere evaluar cinco dimensiones: estabilidad (poder de cómputo necesario y estacionalidad del tráfico), costo (presupuesto real para el entorno), mantenimiento (si tienes conocimiento de Google Cloud in-house o necesitas contratarlo), políticas de la organización (si ya existe una cuenta de GCP con reglas propias) y DNS (para mover el tracking a contexto first-party con tu dominio).
Conviene avanzar cuando:
- Tienes un volumen de conversiones relevante y la pérdida de señal por restricciones de navegador te está afectando el Smart Bidding.
- El contenedor web ya acumula muchos tags de terceros y la performance del sitio se resiente.
- Necesitas enriquecer eventos con datos de servidor que el navegador no puede exponer.
- Tienes requisitos de gobernanza de datos que exigen inspeccionar o filtrar qué sale hacia cada proveedor.
No conviene cuando el volumen es bajo, el equipo no tiene capacidad de operar infraestructura en Google Cloud, o cuando la implementación client-side todavía tiene errores básicos sin resolver. Arregla primero lo simple.
Orden de implementación recomendado
- Inventariar emisores (
gtag.js, GTM web, app y backend), destinos y eventos; corregir duplicados en el origen y definir consentimiento antes del primer envío. - Aprovisionar el contenedor server y su client compatible; probar primero en un entorno o destino de pruebas aislado. Configurar dominio propio para producción según el caso.
- Configurar una sola ruta activa por evento y destino: si GA4 pasa por el servidor, el envío anterior al mismo destino no debe permanecer activo en producción. Probar en staging o con tráfico de prueba segregado; nunca duplicar conversiones reales para comparar.
- Validar extremo a extremo con un evento de prueba: confirmar en la red del navegador el endpoint y el consentimiento; en Preview server, la solicitud entrante, el client que la reclama, el evento, los tags y las solicitudes salientes; en el destino de prueba, recepción y parámetros. Guía oficial de depuración.
- Publicar el cambio con retirada o desactivación simultánea de la ruta antigua, observar paridad agregada posterior y revisar costos, min/max instances y logging según tráfico real.
El límite de sGTM para datos proporcionados
sGTM puede inspeccionar, filtrar y enriquecer una solicitud que ya recibió; no captura datos proporcionados por el usuario por sí solo. El dato debe entrar desde el Google tag, GTM web, una app o un backend, con su consentimiento y propósito definidos. Mover el procesamiento al servidor no autoriza a recolectar más ni convierte un email hasheado en una identidad de reporting.
Antes de migrar, dibuja emisor → endpoint → client → tag → destino y marca qué campos salen en cada salto. Si el origen es un formulario web, compara gtag, GTM, sGTM y Measurement Protocol; si el origen es el CRM, revisa medición de leads offline. Luego valida la cobertura y la paridad con la secuencia de QA sin PII.
Próximo paso
Antes de invertir en infraestructura, mide cuánta señal estás perdiendo hoy: ejecuta la auditoría de tagging y Consent Mode y proyecta el impacto en presupuesto con la calculadora de presupuesto de medios. Si el costo o la complejidad operativa del contenedor server te frenan, el Google Tag Gateway es una alternativa de infraestructura mínima que también mueve el tagging a contexto first-party. Si el caso de sGTM completo cierra, mira cómo abordamos la recuperación de señal y la activación de datos propios para dimensionar el despliegue sobre tu volumen real de tráfico.