Un despliegue de GTM Server en Cloud Run está listo para producción cuando responde en un subdominio propio con certificado válido, corre con dos instancias como mínimo, lee el consentimiento en el servidor y tiene alertas de facturación activas. Si dudas de si te hace falta, está resuelto en cuándo merece la pena el server-side tracking en Madrid; desplegarlo y validarlo entra en los servicios de medición y analítica de Codezone.
Hasta que esos cuatro puntos estén verificados, el servidor funciona pero no es fiable, y el coste de darlo por bueno no se ve el primer día. Se ve cuando una campaña lleva dos semanas optimizando con datos incompletos porque el contenedor se quedó sin instancias en una punta de tráfico, o cuando llega la primera factura con el logging de peticiones activado a volumen alto.
Al terminar tendrás la lista con la que firmar el paso a producción. Si el servidor se montó para arreglar un descuadre de medición, conviene cerrar antes el diagnóstico del descuadre entre Google Ads y el CRM.
Qué significa estar en producción
Un contenedor de servidor está en producción cuando recibe tráfico real de usuarios y su caída degrada la medición del negocio. Eso obliga a tratarlo como cualquier servicio con dependencia de negocio: dominio propio, redundancia, control de gasto y monitorización con alguien al otro lado.
Infraestructura: lo que se configura una vez
- Subdominio propio y DNS: el servidor debe responder en contexto de origen propio, apuntando un subdominio por DNS o reenviando una ruta del dominio principal mediante CDN o balanceador. La segunda vía da acceso completo a las ventajas de cookies propias.
- Certificado: HTTPS válido en el subdominio, con renovación automática verificada. Uno caducado tira la medición completa sin avisar.
- Número mínimo de instancias: Google recomienda un mínimo de 2 instancias para reducir el riesgo de pérdida de datos si cae un servidor, y estima que entre 2 y 10 instancias se atienden de 35 a 350 peticiones por segundo, según la guía oficial de Cloud Run para server-side tagging.
- Región: la más cercana a tu tráfico. Con público internacional, el despliegue multirregión exige crear primero un balanceador de carga.
- Variables y secretos: `CONTAINER_CONFIG` y `PREVIEW_SERVER_URL` son las dos variables del servicio. Las claves de API de tus etiquetas van al gestor de secretos, nunca escritas en la configuración.
Contenedor: lo que se verifica etiqueta por etiqueta
Con la infraestructura en pie, el trabajo se mueve al contenedor. Hay un cliente de GA4 configurado y recibiendo, cada etiqueta de servidor tiene su disparador y sus parámetros revisados, y el consentimiento se lee en el servidor. Los parámetros que llegan en la petición son `ad_storage`, `analytics_storage`, `ad_user_data` y `ad_personalization`, y el cliente de GA4 los pone a disposición de las etiquetas. Esa lectura tiene que ser coherente con lo que promete el banner: la guía de cookies de la AEPD exige que rechazar sea tan fácil como aceptar y que el consentimiento no supere 24 meses de validez. El equivalente en Meta está en la arquitectura de deduplicación de Conversions API.
Validación antes de publicar
- Modo de vista previa: si la página de previsualización carga desde el espacio de trabajo, el servidor está bien apuntado.
- Endpoint de salud: añade `/healthy` a la URL del contenedor; debe devolver el texto `ok`.
- Pruebas de carga: lanza tráfico sintético por encima de tu punta histórica y comprueba que el autoescalado responde antes de perder eventos.
- Alertas de facturación: configúralas antes de abrir el grifo. Por encima de un millón de peticiones al mes, Google recomienda desactivar el logging de peticiones.
- Monitorización: latencia, tasa de error y número de instancias activas, con alerta a una persona concreta.
CodeZone Pro Tip: verifica con un solo comando que el endpoint responde, que la cookie se escribe en tu dominio propio y que un evento de prueba llega al contenedor, para no dar por bueno un despliegue a medias.
#!/usr/bin/env bash
# Verificacion minima de un despliegue de GTM Server antes de publicar.
set -euo pipefail
DOMINIO="${1:?uso: ./verifica-sgtm.sh metrics.tudominio.es}"
BASE="https://${DOMINIO}"
echo "1) Salud del contenedor"
# El endpoint /healthy devuelve el texto ok cuando el servicio esta levantado.
SALUD=$(curl -fsS --max-time 10 "${BASE}/healthy")
[[ "${SALUD}" == "ok" ]] && echo " ok" || { echo " FALLO: ${SALUD}"; exit 1; }
echo "2) Cookie escrita en el dominio propio"
# Guardamos las cookies de una peticion de recogida y comprobamos el dominio:
# si la cookie no se escribe en tu subdominio, no estas en contexto propio.
COOKIES=$(mktemp)
curl -fsS --max-time 10 -c "${COOKIES}" \
"${BASE}/g/collect?v=2&tid=G-XXXXXXXXXX&en=page_view&cid=test.$(date +%s)" \
-o /dev/null
if grep -q "${DOMINIO#*.}" "${COOKIES}"; then
echo " ok"
else
echo " FALLO: ninguna cookie en ${DOMINIO}"; exit 1
fi
echo "3) Evento de prueba aceptado"
# Un 2xx aqui solo confirma que el cliente de GA4 recoge la peticion.
# La llegada del evento se confirma despues en el modo de vista previa.
CODIGO=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 \
"${BASE}/g/collect?v=2&tid=G-XXXXXXXXXX&en=test_despliegue&cid=test.$(date +%s)")
[[ "${CODIGO}" =~ ^2 ]] && echo " ok (${CODIGO})" || { echo " FALLO (${CODIGO})"; exit 1; }
rm -f "${COOKIES}"
echo "Despliegue verificado en ${DOMINIO}"Este script convierte una revisión de diez minutos en una de diez segundos, y la hace repetible. Lánzalo tras cada publicación del contenedor y desde un cron: un certificado caducado o un cambio de DNS se detectan el mismo día, no cuando alguien note que faltan conversiones.
Lo Que Se Rompe Si No Lo Revisas Cada Trimestre
Cada trimestre toca repasar cuatro cosas: la versión de la imagen del contenedor, el gasto real contra el estimado, las etiquetas que ya no se disparan y la caducidad del consentimiento guardado. Un despliegue de medición en Madrid envejece como cualquier servicio, y aquí vale el mismo criterio de revisión periódica de la arquitectura del mantenimiento web.
Con la lista cerrada, el servidor deja de ser un punto de duda y pasa a ser infraestructura. A partir de ahí el trabajo útil está en lo que envías: conversiones offline del CRM a Google Ads y una arquitectura de datos propios que no dependa de cookies de terceros. Si la duda es quién mantiene esto, el criterio está en la decisión entre equipo interno y agencia de paid media; las bases de contenedor y disparadores, en Google Tag Manager avanzado.
Si tienes GTM Server levantado y no sabes si está bien montado, pídenos una revisión del despliegue y te devolvemos qué falta y en qué orden resolverlo.
