Agencia experta enGoogle Tag Managercon arquitectura, documentación y gobierno de contenedores.
Diseñamos y mantenemos contenedores GTM que se pueden auditar: naming coherente, carpetas por dominio, versionado con notas útiles, y una separación clara entre lo que dispara marketing y lo que dispara producto. Client-side, server-side, o ambos según convenga.
GTM es una herramienta poderosa que se convierte en pasivo tecnológico en cuanto deja de mantenerse. Un contenedor con doscientas tags sin dueño es peor que no tener GTM — porque nadie se atreve a limpiarlo, y todo el mundo añade "por si acaso". La disciplina no es opcional.
Estructura típica de un contenedor senior
Se adapta al stack, pero el patrón se mantiene.
Tags de analítica
GA4, Piwik, Matomo, Amplitude o el sistema que uses. Configuradas con parámetros documentados y triggers precisos, no genéricos.
Tags de marketing
Meta, LinkedIn Insight, Google Ads, TikTok, Pinterest. Con Consent Mode y Advanced Matching cuando aplican, y con eventos server-side donde tiene sentido.
Data layer estructurado
Definición formal del data layer con contrato entre desarrollo y medición. Lo que se puede leer, lo que se puede empujar, y quién actualiza qué.
Variables y lookup tables
Uso intensivo de variables y tablas de mapeo para no repetir configuración. Un cambio de dominio o de canal se hace en un sitio, no en cincuenta.
Consent Mode v2
Integración correcta con CMP (OneTrust, Cookiebot, Didomi, propia). Comportamiento distinto según categorías de consentimiento.
Server-side container
Cuando aplica: GTM Server en Cloud Run, Cloudflare Workers o similar. Con control fino sobre qué sale del contenedor y hacia dónde.
Cómo se construye un contenedor auditable
De la petición del negocio a la etiqueta en producción — sin atajos.
- L01
Contrato
Toda tag empieza por un requisito de negocio escrito: qué se mide, por qué y quién lo va a usar. Sin contrato no se implementa.
- L02
Data layer
La página empuja información al data layer con un esquema documentado. GTM sólo lee — no adivina — y así el equipo de producto controla qué se expone.
- L03
Contenedor
Tags + triggers + variables organizados en carpetas por dominio (marketing / producto / consent / debug). Cada elemento con dueño y descripción.
- L04
Server-side
Cuando existe, el contenedor server actúa como filtro y router: recibe eventos, los enriquece, decide a quién enviarlos y con qué transformaciones.
- L05
Publicación
Workflow con versionado, notas de cambio, testing en preview, aprobación y publicación. Cualquier cambio es reversible — nunca se toca producción a ciegas.
Entregables tangibles
Documentación y activos reutilizables — no confianza ciega en el consultor.
Contenedor exportado
JSON del contenedor con todas las tags, triggers y variables documentadas. Vuestro para siempre — sin dependencia de nosotros.
Especificación de data layer
Documento con el contrato entre web/app y GTM. Qué eventos existen, qué parámetros llevan, quién es responsable.
Naming convention escrita
Reglas de nomenclatura para tags, triggers y variables. Aplicables por cualquier persona nueva sin pedir permiso.
Playbook de publicación
Proceso escrito de cómo se hace un cambio: request → dev → preview → test → aprobación → publish. Con roles claros.
Monitorización de tags
Alertas cuando una tag crítica deja de disparar o cuando aparece una tag inesperada. GTM también se puede vigilar.
Handover formal
Sesión de traspaso al equipo interno (marketing, BI, IT) con casos prácticos. Sin "aprender leyendo el contenedor".
Principios de gobernanza de GTM
Un contenedor sano no es cuestión de suerte — es proceso.
- 01
Un dueño por tag
Cada tag tiene un responsable de negocio identificado. Cuando no lo tiene, la tag va a la carpeta "revisar" — y de ahí, a borrar si nadie la reclama.
- 02
Poda periódica
Cada trimestre se revisa qué tags no dispararon en 90 días. La mayoría se puede desactivar — y en la siguiente revisión, borrar.
- 03
Cambios reversibles
Toda publicación tiene notas y se puede revertir en un click. Nadie despliega "porque tenía prisa" sin dejar rastro.
- 04
Roles y permisos limitados
No todo el mundo publica. Marketing puede editar en preview y solicitar aprobación. Publicación en manos de un pequeño equipo con criterio.
- 05
Auditoría anual
Una vez al año, revisión completa: qué se dispara, hacia dónde, con qué consentimiento y para qué. Con acta.
Dudas honestas antes de contratar
¿Podéis auditar nuestro contenedor GTM actual antes de tocar nada?
Es lo primero que hacemos. Os entregamos un informe con: tags que se pueden borrar sin riesgo, tags que hay que revisar, tags críticas mal configuradas y estructura general. Sin propuesta de rehacerlo todo — solo lo que aporte.
¿Cuándo hace falta GTM server-side y cuándo es humo?
Server-side aporta en tres casos: conversiones críticas de negocio (queremos que lleguen aunque el navegador bloquee), control fino de datos que salen del sitio (RGPD, first-party data), y stacks muy heterogéneos donde queremos un router central. Fuera de esos casos, client-side suele bastar.
¿Cómo os coordináis con nuestro equipo de desarrollo?
Con contrato de data layer. Desarrollo empuja eventos con un esquema acordado; GTM sólo los consume. Nadie tiene que "esperar al de GTM" para desplegar la web, ni al revés.
¿Y si ya tenemos un partner que gestiona GTM?
Podemos entrar como segunda opinión, hacer auditoría independiente y devolver un informe al partner. O podemos tomar el relevo si el partner ya no da servicio. Sin conflicto — cada modelo tiene su lugar.
¿Trabajáis con Piwik PRO Tag Manager, Matomo Tag Manager u otros?
Sí. Tenemos experiencia con GTM (Google), Piwik PRO, Matomo Tag Manager y Tealium. El principio (contenedor limpio, data layer contractual, versionado) se aplica igual en todos.
¿Vuestro GTM está ordenado o es un contenedor que nadie se atreve a tocar?
Nos das acceso de lectura al contenedor y os devolvemos un mapa: qué se puede borrar, qué hay que arreglar y qué falta.
¿Hablamos?Auditoría GTM bajo NDA. Sin proponer rehacerlo todo por defecto.