Google Tag Gateway carga los scripts de Google desde tu propio dominio en lugar de los servidores de Google. Tus etiquetas pasan de terceros a first-party y vuelven a ser difíciles de bloquear. Es oficial, es gratis y ya está disponible. Pero de los dos sitios que audité, solo uno recuperaba de verdad sus conversiones: el otro mostraba un estado en verde y no devolvía ningún dato. Aquí tienes cómo activarlo y, sobre todo, cómo comprobar que el tuyo hace su trabajo.

Es uno de los frentes que trabajo como freelance Google Tag Manager, y el que da resultados más rápido cuando se hace bien.

Qué cambia exactamente

Antes, tu contenedor se cargaba desde googletagmanager.com. Ahora se carga desde tudominio.com/metrics/?id=GTM-XXXX.

Imagina un portero en la entrada. Tu script llegaba con el uniforme de una empresa externa: fácil de rechazar. Ahora lleva el tuyo.

  • La etiqueta no cambia de función, cambia de dirección de envío.
  • No es un truco en zona gris: Google lo documenta oficialmente, con dos vías de implementación, un CDN o un servidor de etiquetado.
  • La regla: un script servido desde tu dominio deja de ser un objetivo fácil para los bloqueadores y las restricciones del navegador.

Ya está disponible

Es la pregunta que más se repite, y parte de una premisa falsa. El gateway no está por llegar: la integración de un clic con Cloudflare funciona, la documentación de Google está publicada y mantenida, y hay sitios funcionando con él.

Cómo está cada integración, verificado en agosto de 2026:

  • Cloudflare: un clic, la vía más sencilla y la más extendida.
  • Google Cloud: disponibilidad general desde el 1 de junio de 2026. Ojo, exige el balanceador de carga de aplicaciones externo global: el clásico no está soportado.
  • Akamai y Fastly: entregados e integrados en la interfaz de Google desde mayo de 2026, pero todavía etiquetados como beta en la documentación.
  • Amazon CloudFront: soportado desde junio de 2026, con un flujo guiado en Tag Assistant.
  • Webflow y Duda: gateway activo por defecto en las etiquetas puestas mediante la integración nativa. Tres salvedades: incompatible con instalaciones en código personalizado, hace falta republicar el sitio si el identificador ya estaba puesto, y no está disponible si exportas tu sitio para alojarlo en otro lugar.

Shopify, Wix, Squarespace y WordPress tienen la integración del Google tag, pero no he encontrado activación por defecto del gateway en ninguno de ellos hasta hoy.

Lo que cuesta

La funcionalidad es gratis. Lo que puede costar es la infraestructura que la sostiene.

  • En Cloudflare: gratis, usas el plan que ya tienes. Coste marginal cero.
  • En otro CDN: gratis del lado del gateway, variable según tu CDN y tu volumen.
  • Con un servidor de etiquetado: gratis del lado del gateway, pagas el servidor cloud.

Si te compensa o no

Una sola pregunta lo decide: ¿estás perdiendo conversiones hoy?

  • Te afecta si una parte relevante de tu tráfico está en Safari o iOS, si tu audiencia es técnica y por tanto usa bloqueadores, o si la diferencia entre tus conversiones de plataforma y tus ventas reales se ensancha sin explicación.
  • Puedes esperar si tu medición tiene problemas más arriba: eventos mal declarados, consentimiento inestable, duplicados. El gateway transporta mejor una medición correcta. No repara una medición falsa.
  • En ecommerce, el efecto es inmediato: transacciones que habían dejado de atribuirse vuelven a atribuirse.
  • En generación de leads, el efecto es indirecto pero suele ser más rentable: una señal más completa alimenta mejor las pujas automáticas, así que tu coste por adquisición se estabiliza antes incluso de que se mueva el volumen.

Sobre las cifras que circulan, voy a ser franco. Google comunica una media de +14 % de conversiones, y ahora «hasta un 7 % menos de coste por adquisición». Las dos vienen de quien vende la funcionalidad, así que son argumentos comerciales, no una expectativa de resultado. Los casos publicados, una aseguradora en torno al 15 o 30 % de conversiones recuperadas, una marca de cosmética alrededor del 22 %, son casos seleccionados: demuestran que ese resultado es posible, nunca que sea probable en tu caso. Nadie publica los despliegues que no cambiaron nada.

La única cifra que vale algo es la que mides en tu cuenta, antes y después.

Qué vía elegir

Sitúate en tres preguntas.

  • ¿Ninguna etiqueta instalada? Pon el Google tag y un CDN, el gateway se activa a continuación. Nada que deshacer, es el escenario más simple.
  • ¿Una etiqueta client-side clásica? Todo depende de tu CDN. En Cloudflare, integración de un clic. En otro CDN, implementación manual pero documentada. Sin CDN, eliges entre pasarte a un CDN gratuito o montar un servidor de etiquetado.
  • ¿Ya tienes un servidor de etiquetado? No instalas nada nuevo, pasas tu servicio de terceros a first-party. Es el camino más corto al mejor resultado.

Mi opinión, y es clara: si estás en Cloudflare y dudas, coge hoy la integración de un clic. El servidor de etiquetado es mejor herramienta, pero es un proyecto. Un beneficio real vale más que un plan perfecto que sigue esperando.

Activarlo con Cloudflare

Unos clics, sin tocar el código: la reescritura de las etiquetas ocurre en el edge.

Primero un punto contraintuitivo. Google precisa que el código fuente de tu página mostrará la URL first-party correcta aunque tus ficheros de origen sigan apuntando a googletagmanager.com. No te preocupes si tu HTML de origen no ha cambiado: lo que cuenta es lo que recibe el visitante.

Lo contrario, en cambio, sí es un fallo real. Si la página entregada al visitante sigue referenciando googletagmanager.com, la reescritura no se ha disparado. Está documentado en la comunidad, sobre todo con snippets en protocolo relativo (//www.googletagmanager.com/...). En ese caso, revisa la configuración de la zona.

Activarlo reetiquetando a mano

Sustituyes el origen de cada script de Google por tu ruta de medición. La sintaxis oficial usa una ruta relativa, sin nombre de fichero:

  • Para Google Tag Manager: j.src='/metrics/?id='+i+dl;
  • Para gtag: <script async src="/metrics/?id=G-XXXXXXX">

Tres detalles que ahorran tiempo:

  • Evita /metrics/gtm.js?id=.... Funciona, pero conserva patrones (/gtm.js, .js?id=GTM-) que las reglas de bloqueo reconocen. Pierdes parte del beneficio para nada.
  • Deja el iframe <noscript> tal cual. No lo sirve el gateway y su impacto es despreciable.
  • No reetiquetes tus etiquetas una a una. El contenedor servido por tu ruta de medición ya lleva esa ruta, así que las etiquetas dependientes, conversión de Google Ads y GA4 igual, la siguen automáticamente.

Activarlo con un servidor de etiquetado

Si ya tienes uno, pasas tu servicio de terceros a first-party. Es más pesado, y ganas el control completo de los datos antes del envío: modificación, enriquecimiento, anonimización, y cookies gestionadas en servidor cuya duración ya no depende de las restricciones del navegador.

La trampa: activo no significa que transporte

Aquí está el núcleo del asunto.

Los scripts y los hits de medición son dos ejes independientes. Un gateway puede servir tus scripts en first-party sin enrutar ni un dato. Ves un estado en verde, tus etiquetas cargan, y tus conversiones siguen saliendo directas hacia Google. Así que siguen siendo bloqueables.

Cargar el script es dejar entrar al repartidor. Enviar los hits es dejarle salir con tu pedido. Un gateway que hace lo primero sin lo segundo te ha hecho instalar una puerta para nada.

En los dos sitios que audité en julio:

  • Una cuenta de cliente: scripts en first-party y hits de Google Ads en first-party. La señal de conversión sobrevive al bloqueo. Es el caso nominal.
  • Mi propio sitio: scripts en first-party, ningún hit. Gateway activo, beneficio cero.

Sí, mi propio sitio. Descubrí el problema construyendo la herramienta de auditoría.

Desde entonces lo he corregido, y la nueva auditoría muestra exactamente lo que eso cambia: mis hits de conversión de Google Ads ahora salen desde mi propio dominio y sobreviven al bloqueo. Una cosa no se ha movido, y es instructiva: mis hits de GA4 siguen saliendo directos hacia Google. Encaja con la documentación, que dice que «una parte» de las peticiones pasará por tu dominio. El gateway no es un interruptor, es una configuración destino por destino.

Y la primera vez que la ejecuté, me equivoqué. Buscaba los scripts por patrón de URL, filtrando por gtm.js. Resultado: diecinueve cargas first-party contadas como cero, un diagnóstico de «scripts no funcionales» completamente falso, y una recomendación de reetiquetado que no tenía ninguna razón de ser. El motivo es interesante: el gateway sirve sus scripts bajo rutas aleatorias, del tipo /metrics/OvgO--ioXpMMINbFsRy..., precisamente para escapar a las reglas de bloqueo por patrón. Ninguna búsqueda por nombre de fichero las ve.

La trampa que nadie menciona: tu geolocalización

Esta no la vi escrita en ningún sitio hasta que di con la documentación.

Cuando tus peticiones pasan por tu CDN, Google deja de recibir la IP de tu visitante y recibe la del CDN. Sin configuración adicional, tus informes muestran una geografía falsa, y los valores por defecto del consent mode, que dependen del país, se descolocan.

  • En Cloudflare, las cabeceras de geolocalización se transmiten automáticamente. Nada que hacer.
  • En CloudFront y Azure Front Door, es manual: si te lo saltas, cambias un problema de bloqueo por un problema de datos.

Otros dos límites que conviene conocer antes de enrutar tráfico:

  • En Akamai solo se soporta un Google tag. Varias etiquetas exponen el gateway a inyección de scripts y pueden romperlo. La solución documentada es consolidarlo todo en un único contenedor.
  • El gateway solo transporta cookies de Google. Las cookies que no son de Google y pasan por ahí se descartan.
  • La configuración manual de Cloudflare exige un plan Enterprise. Sin Enterprise, usa la integración desde la interfaz.

Leer el panel de Google sin alarmarse

El gateway muestra un estado en la administración de tu cuenta. Tres valores, y el tercero preocupa sin motivo.

  • Propietario (o first-party): el gateway está activo en ese dominio. No dice nada de los hits.
  • Sin empezar: no hay nada activado.
  • Incompleto: al menos un dominio detectado no está cubierto. Suele ser cosmético. El caso típico: Google detecta tu dominio sin www además del www, cuando el primero redirige de forma permanente al segundo y no sirve ni una página. Comprueba la redirección antes de montar un proyecto.

Dos señales falsas que conviene conocer:

  • gtg_health=1 no es un fallo. Una petición a googletagmanager.com con ese parámetro es la sonda de salud del gateway. Sale aunque todo funcione.
  • No todas las peticiones se enrutan, por diseño. La documentación oficial dice que «una parte» de las peticiones de medición pasará por tu dominio. Unas cuantas peticiones directas no significan que esté roto. Cero peticiones first-party, eso sí.

La comprobación en cinco minutos

  1. Abre la pestaña Red de tu navegador en una página de conversión.
  2. Filtra por tipo de recurso «Script», no por nombre de fichero, acabas de ver por qué.
  3. Después mira de dónde salen las peticiones de medición, las que contienen collect o conversion: ¿tu dominio, o un dominio de Google?

Si los scripts están en tu dominio pero todas las peticiones de medición salen hacia Google, tu gateway carga sin transportar. Normalmente los destinos no están bien declarados en el panel.

Dos detalles para leer bien lo que ves:

  • Coexisten dos formas de URL y las dos son válidas. El reetiquetado manual produce /<ruta>/?id=XXX, la reescritura de Cloudflare produce más bien /<ruta>/gtag/js?id=XXX. Ver la segunda cuando creías haber hecho la primera no es un error: es el edge que ha tomado el mando.
  • La ruta de medición por defecto no es /metrics. Google genera una de cuatro caracteres alfanuméricos, del tipo /a7x2. Si buscas /metrics y no encuentras nada, busca más bien una secuencia de cuatro caracteres sin significado.

Y el consentimiento

El gateway no cambia nada de tus obligaciones.

  • Consent mode avanzado: ninguna configuración adicional.
  • Consent mode básico: hay que restringir la transmisión de datos publicitarios, lo que equivale al bloqueo de etiquetas.

Transporta mejor los datos que tienes derecho a recoger. No te autoriza a recoger más.

Lo que no te puedo prometer

Ninguna tasa de recuperación frente a los bloqueadores es verificable a día de hoy. Las cifras que circulan son casos aislados u órdenes de magnitud sin metodología publicada. He buscado y no he encontrado nada sólido.

Quedan además dos puntos ciegos que ninguna inspección del navegador cubre:

  • Ver salir una petición de tu dominio no prueba que Google la haya ingerido. La confirmación se hace del lado de la plataforma, en el informe en tiempo real de GA4 o en el panel del gateway.
  • La configuración exacta de tu zona CDN es invisible desde la página. Si la reescritura no se dispara, la causa está ahí.

Veredicto

  • Actívalo ya si estás en Cloudflare: coste cero y unos pocos clics.
  • Comprueba los hits, no los scripts. Un estado en verde y unas etiquetas que cargan no prueban nada. La única prueba que cuenta es de dónde salen tus peticiones de medición.
  • Mide en tu propia cuenta: una línea base en un periodo limpio, la activación, y después una comparación sobre volúmenes comparables. Y vuelve a comprobarlo tras cada cambio, esta funcionalidad se mueve rápido.

Si quieres saber qué está perdiendo de verdad tu medición hoy, antes de tocar nada, es exactamente el tipo de diagnóstico que hago en una auditoría de cuenta.