El sitio medía todo en el navegador: sin capa server-side, los hits de GA4 quedan expuestos a bloqueadores, ITP y cookies de terceros, y no hay forma de demostrar la habilidad sin un cliente que la pida primero.
Dos caminos: pagar un SaaS intermediario como Stape, o montar el contenedor server-side directo sobre la propia cuenta de Google Cloud, la misma que ya sostiene el pilar de GEO/AEO.
Contenedor GTM tipo servidor en Cloud Run con dominio propio, certificado gestionado y escalado a cero. Un bug de CSP que bloqueaba la conexión en silencio, encontrado y corregido ya en producción.
Tráfico real confirmado de extremo a extremo, desde el navegador hasta GA4 pasando por sgtm.cristhianvelasquez.com, verificado en los logs de Cloud Run y en GA4 en tiempo real.
Contexto
Vender server-side tagging sin tener uno propio verificable en producción no es defendible. Se decidió montarlo en la infraestructura de Google Cloud en vez de un SaaS intermediario como Stape, por coste (0€ indefinido en el free tier de Cloud Run frente a un plan de pago que crece con el tráfico) y por argumento técnico frente a un cliente que audite el montaje.
Cómo se resolvió, en detalle
Por qué Cloud Run directo y no Stape
Stape simplifica el panel y el mantenimiento, pero cobra según el tráfico y añade un proveedor externo más a gestionar. Cloud Run con aprovisionamiento automático de GTM da 2 millones de peticiones al mes gratis, corre en la misma cuenta de Google Cloud que ya sostiene el pilar de GEO/AEO, y con facturación por solicitud y escalado a cero el coste real se queda en 0€ mientras el tráfico no se dispare muy por encima del actual.
El bug que no aparecía en ningún log de servidor
Con el certificado emitido, el contenedor publicado y el cliente GA4 configurado, seguía sin llegar tráfico real, solo peticiones de prueba manuales. La causa nunca apareció en los logs de Cloud Run porque la petición nunca salía del navegador: el Content-Security-Policy del sitio no incluía sgtm.cristhianvelasquez.com en connect-src, así que el navegador bloqueaba el fetch antes de enviarlo. gtm.js cargaba con 200 con toda normalidad, lo que hacía parecer que todo funcionaba. Solo la consola del navegador mostraba el error real.
Coste real: qué lo mantiene en 0€ y qué lo rompería
Con mínimo de instancias en cero y facturación basada en solicitudes, el servicio no cobra nada en reposo y consume una fracción mínima del free tier al tráfico actual. Lo único que lo rompería: subir el mínimo de instancias a uno o más (instancia siempre encendida, unos 35-40€ al mes), o un pico de tráfico anómalo sin tope de escalado. Por eso el máximo de instancias queda capado y hay una alerta de presupuesto activa.
Un servidor de tagging que responde 200 a cada prueba directa contra su API puede seguir sin recibir un solo evento real si el navegador bloquea la conexión antes de que salga. Verificar un montaje server-side tiene que incluir tráfico real de navegador con DevTools abierto, no solo pings sintéticos a la API.
Preguntas frecuentes
¿Por qué Cloud Run y no un proveedor gestionado como Stape?
Por coste y por argumento técnico: el free tier de Cloud Run cubre con holgura el tráfico de un sitio de este tamaño, sin plan de pago al que crecer, y demuestra manejo directo de la infraestructura en vez de depender de un SaaS intermediario.
¿Qué es lo que más falla en este tipo de montaje?
No el certificado ni el propio contenedor de GTM, sino la capa que casi nadie revisa al montarlo: el Content-Security-Policy del sitio. Si connect-src no incluye el dominio del servidor de etiquetado, el navegador bloquea la conexión en silencio y no aparece ningún error del lado del servidor.