Las zonas en Google Tag Manager son la función que permite conectar un contenedor adicional al principal para que un equipo publique sus propias etiquetas sin acceso al resto del contenedor. Sirven cuando una empresa reparte marketing, IT, recursos humanos o varias sedes sobre el mismo GTM: sin límites por página y por tipo de etiqueta, cualquiera con permiso de publicación puede sobrescribir el trabajo de otro departamento. Esta pieza explica qué restringen las zonas, cómo se combinan con los permisos por contenedor y las áreas de trabajo, y qué error evita cada capa en la práctica.
Las zonas en Google Tag Manager son contenedores vinculados que restringen, por página y por tipo de etiqueta, activador o variable, lo que un equipo puede publicar dentro del contenedor principal. Combinadas con los cinco niveles de permiso por contenedor y con las áreas de trabajo, evitan que un departamento sobrescriba o duplique el etiquetado que otro ya tiene en producción.
Zonas en Google Tag Manager, el límite que faltaba
Un contenedor de GTM nace único: cualquiera con permiso de publicación puede tocar cualquier etiqueta, en cualquier página. Eso funciona mientras solo lo gestiona una persona o un equipo pequeño. En cuanto entran una agencia externa, el departamento de recursos humanos para la sección de empleo o una tienda con marketing e IT separados, el mismo contenedor se convierte en un punto de conflicto: cualquiera puede pisar el trigger que otro acaba de publicar.
Las zonas de Tag Manager resuelven justo eso: son contenedores vinculados al principal que se activan solo en las páginas que se les indique y que restringen los tipos de etiqueta, activador y variable que pueden usar. Por defecto excluyen las variables de JavaScript personalizado, así que un tercero con acceso a una zona no puede ejecutar código arbitrario en el resto del sitio.
Una zona, en la terminología de Google, es un contenedor vinculado con sus propias reglas de página y de tipo de etiqueta: el administrador del contenedor principal no necesita acceso a ella ni lo obtiene por defecto.
Permisos por contenedor, de leer a publicar
Antes de repartir zonas hace falta repartir permisos, y Tag Manager distingue el nivel de cuenta del nivel de contenedor. A nivel de cuenta solo hay usuario o administrador; el reparto fino ocurre contenedor a contenedor, con cinco niveles:
- Sin acceso: el contenedor ni se ve.
- Leer: consulta etiquetas, activadores y variables sin poder tocarlos.
- Editar: crea áreas de trabajo y cambios, pero no publica.
- Aprobar: crea versiones a partir de un cambio, tampoco publica.
- Publicar: el único nivel con acceso completo, incluida la publicación en producción.
Riesgo de tener menos de dos administradores
Google Tag Manager exige mantener activos al menos dos administradores de cuenta. No es una recomendación de buenas prácticas: es un requisito técnico pensado para que la baja o el bloqueo de una sola persona no deje el contenedor sin nadie que pueda modificar permisos. En una empresa donde el contenedor lo montó una agencia y quedó un único responsable interno, perder esa cuenta —una baja, un despido, un simple olvido de contraseña sin recuperación— significa quedarse sin forma de añadir usuarios nuevos ni de revocar el acceso a quien ya no debería tenerlo. Mantener dos administradores activos, y no uno con un segundo de repuesto olvidado, es la parte de esta gobernanza que menos se revisa y más se lamenta cuando falla.
Áreas de trabajo para no pisarse encima
Zonas y permisos limitan quién puede tocar qué; las áreas de trabajo resuelven un problema distinto: que dos personas con el mismo permiso editen el contenedor a la vez sin que una borre el trabajo de la otra. Cada contenedor trae un área predeterminada y admite hasta dos adicionales en una cuenta estándar; en Tag Manager 360 no hay límite. Cada usuario trabaja en la suya, con su propio conjunto de cambios, y nadie ve los cambios a medias de otro hasta que se publican.
Los colores que resuelven un conflicto de versión
Cuando dos áreas de trabajo tocan el mismo elemento y una de las dos ya se publicó, Tag Manager marca el conflicto con un código de colores antes de dejar publicar la segunda, en vez de sobrescribir en silencio. Al publicar un área se registran su nombre, sus notas y los cambios incluidos, y el sistema crea automáticamente una nueva área predeterminada para seguir trabajando. Es la diferencia entre enterarte de un pisotón por un código de color en pantalla o por una campaña que deja de medir conversiones un lunes por la mañana sin que nadie sepa por qué.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
La combinación entre zonas, permisos y aprobaciones
Ninguna de las tres capas resuelve sola el problema de un contenedor compartido. Las zonas acotan el territorio, los permisos deciden quién entra en cada nivel y las aprobaciones obligan a que alguien revise antes de que un cambio llegue a producción. Juntas permiten, por ejemplo, que una agencia externa solo active etiquetas de una campaña concreta, que recursos humanos publique en la sección de empleo sin tocar el carrito de compra, y que marketing edite casi todo el sitio salvo las páginas donde una etiqueta mal puesta rompería una conversión que ya funciona.
Tres sedes, un contenedor y ninguna sorpresa
Una clínica dental con tres centros, una inmobiliaria con oficinas en varios barrios o un despacho de abogados con áreas de práctica distintas comparten el mismo patrón: varias personas necesitan publicar en su propia sección sin depender de que una sola persona centralice cada cambio. Con una zona por sede o por área, un permiso de edición acotado a esa zona y una aprobación antes de publicar, cada equipo mueve sus propias etiquetas de contacto o de formulario sin arriesgar la medición de las demás sedes. El contenedor principal queda para lo que de verdad es transversal: el píxel de analítica, el gestor de consentimiento y las conversiones que se comparan entre sedes.
Errores que evita esta gobernanza en la práctica
El caso más repetido es la etiqueta de conversión duplicada: dos personas, sin visibilidad entre sí, añaden la misma etiqueta de Google Ads o de Analytics en momentos distintos y el negocio empieza a contar el doble de leads o de ventas sin que nadie active nada a propósito. Otro clásico es el disparador que depende del estado de consentimiento: si quien edita esa zona no sabe qué exige la normativa sobre cookies de analítica sin consentimiento, publica una etiqueta que se dispara antes de que el usuario acepte, y ese fallo no se detecta hasta una revisión legal o una auditoría.
También aparece en negocios con varios dominios o subdominios, donde la medición entre dominios en GA4 depende de una configuración que vive en el contenedor principal: si un equipo con permiso de editar la toca sin saberlo, las sesiones se cortan al saltar de un dominio a otro y el informe de atribución deja de cuadrar. Ninguno de estos tres fallos se corrige revisando código: se evita repartiendo permisos antes de que ocurran. Cuando el contenedor ya arrastra meses de cambios sin este reparto, lo más rápido suele ser partir de una auditoría de analítica web que documente qué etiqueta pertenece a quién antes de tocar nada.
Preguntas frecuentes sobre zonas en Google Tag Manager
¿Cuántas áreas de trabajo adicionales permite una cuenta estándar?
Dos, además de la predeterminada que trae cada contenedor: tres en total antes de tener que cerrar una y liberar hueco. Tag Manager 360, la versión de pago, elimina ese límite para equipos que necesiten trabajar en paralelo con más frecuencia.
¿Qué diferencia hay entre los permisos de editar y de aprobar?
Editar deja crear áreas de trabajo y modificar etiquetas, activadores y variables, pero no publicarlas. Aprobar permite crear una versión a partir de esos cambios, revisándolos antes de que lleguen a producción, pero tampoco publica: solo el nivel de publicar tiene esa capacidad.
¿Puede una zona ejecutar variables de JavaScript personalizado?
No por defecto. Las zonas excluyen las variables de JavaScript personalizado salvo que se habiliten expresamente, precisamente para que un contenedor vinculado —de una agencia o de otro equipo— no pueda ejecutar código arbitrario en el resto del sitio.