Integrations, Google Tag Manager

Google Tag Manager es el segundo de los dos slots de analítica en Settings → Integrations. Pega tu container ID, reconstruye el site, y cada página lleva el loader estándar de GTM de Google más un consent gate garantizado-seguro, sin tags corriendo antes de que tu visitante realmente haya interactuado (o dado el consent, si tu cookie banner está encendido).

Configurarlo

1. En Google Tag Manager, crea el container de tipo web y anota su ID; se ve como GTM-XXXXXXX.
2. En Chinaski, ve a Settings → Integrations → Analytics, pega el container ID en GTM container ID, guarda y reconstruye.

Listo. Desde el siguiente build en adelante, el script estándar de bootstrapping de GTM (gtm.js?id=<your-container>) es parte del <head> de cada página construida, inicializado con el dataLayer vacío estándar. Los tags, triggers y variables viven todos en el container: el CMS meramente lo carga.

Deja el campo en blanco y no se emite nada: el output del site libre de scripts incluido se queda tal cual (y la hint "Injected into every page at build time" del campo es el contrato entero).

Cómo se comporta el loading

El loader inyectado se difiere deliberadamente, por privacidad y velocidad de página:

• Sin carga en visitas en reposo: el script del container hace fetch solo cuando el visitante hace algo: clicks, scrolls, presiona una tecla, o toca la pantalla. El listener es de un solo disparo; después de la primera interacción todo sigue normal.
• Respeta la cookie notice: con el cookie banner del site activo, el loader espera cookie_consent=1 antes de contactar a Google, y también honra una cookie de rechazo explícita incluso cuando el banner está deshabilitado. Un consent ya dado al cargar la página arranca el loader de inmediato.
• Como el loader está en <head>, el dataLayer se crea antes de cualquier script de cuerpo; los tags del container que leen los datos que se push (un nombre de idioma, un nombre de sección) funcionan como siempre.

Consecuencia práctica que vale la pena conocer: los hits de "page view" para un trigger del container se disparan en la primera interacción (o inmediatamente para los visitantes recurrentes con consent), no en la descarga inicial del HTML. Ajusta tus expectativas de reporte de GA/GTM a eso.

La relación con GA4

Un loader de analítica por página, siempre:

• GTM ID lleno → GTM es el tracker. El loader de gtag.js se omite incluso si también hay un ID de GA4 presente; la duplicación de tracking por dos caminos no puede ocurrir. Gestiona tus tags de GA4 dentro del container y deja el otro campo en blanco.
• Los campos existen como switches separados a propósito: GTM es para equipos que gestionan tags en el container; GA4 directo es la ruta rápida. Ambos en blanco = ningún script de Google en absoluto.

De qué no necesitas preocuparte

• Sin round-trip del server. El tráfico llega a Google solo desde el navegador del visitante; el CMS nunca hace proxy, almacena ni valida el payload.
• No necesitas escapar nada de tu lado: el container ID se sanea cuando se escribe en la página construida, y el loader nunca trackea a nadie antes de un consent event aceptado.
• Los demás tags se quedan fuera del loader. Este campo carga un solo container; cualquier otra cosa que puedas querer (Meta, Plausible, JSON custom) pertenece al sistema de Snippets, el cual también maneja las reglas de order de casos y de privacy-server.

Modo air-gap

En un host aislado, este panel se apaga con un banner de explicación ("External analytics scripts (GA4, GTM) are disabled and will not be emitted in builds"), el input pasa a read-only, y el build mismo hace drop del container ID de la memoria así ningún build, programado o manual, puede llamar a Google, consistente con la garantía sin-salida de CHINASKI_AIRGAP. El ID almacenado se queda en los settings para cuando reactives.

Solución de problemas

• Sin script de GTM en la página construida: el campo está en blanco, el modo air-gap está encendido, o no has reconstruido desde que guardaste. Revisa el page source buscando gtm.js?id=.
• Los tags no se disparan aunque el loader está presente: recuerda que el loader espera la primera interacción (o el consent). Prueba haciendo clic en cualquier parte de la página y observando gtm.js en el network tab.
• El loader de GA4 carga pero la analítica va por GTM después: configuraste ambos IDs; según la regla de precedencia, GTM gana. Mueve tus tags de GA4 al container, o limpia el campo de GTM y usa el campo directo de GA4 en su lugar.
• Container ID de apariencia incorrecta: el campo es texto libre. Pega exactamente GTM- + tu container ID; no hay chequeo de formato, y la única compensación es una petición de script faltante inofensiva.

La versión corta

Pega el container ID en Settings → Integrations, reconstruye, y cada página envía silenciosamente el bootstrap de GTM, cargado solo después de la primera interacción (y después del consent, si corres el cookie banner), con el campo de GA4 ignorado mientras un container es dueño del tracking, y nada en modo air-gap.