It can be reasonably said that there are two main aspects to Google Tag Manager: the tagging functionality itself, and the access control.
The tagging functionality tends to get more attention. After all, who doesn’t get excited using Auto-event Variables, the built-in Click Classes trigger and Fields to Set to generate Google Analytics virtual pageviews from an AJAX form flow and then configuring a corresponding goal funnel?
Equally important, however, is GTM’s controlled democratization of the tagging process in the enterprise. GTM allows non-technical roles to play an integral role in the tagging process while reserving the most sensitive privileges – Approve and Publish – for the most suitable individuals. With Container Zones, we now have even greater access control within Google Tag Manager 360.
Containers within a Container
First thing to understand about container zones: they’re actual standalone containers brought into another container for parallel processing on the page.
Beyond just a plain embed, two features allow greater control over how the embedded container behaves within the Container Zone of the main container: Zone Boundaries and Type Restrictions.
Zone Boundaries
As you’re setting up a Container Zone within a main container, you can specify Zone Boundaries.
Zone Boundaries serve as layer of triggering control beyond the triggers defined within the embedded container.
Let’s consider two scenarios, using a Hotjar heatmapping tag as an example.
Scenario A
Trigger in embedded container: Page View
Zone Boundary in Container Zone: Page View, Page Starts with /catalog
Scenario B
Trigger in embedded container: Page View, Page Starts with /catalog
Zone Boundary in Container Zone: Page View
In both cases, the tag will fire only on the catalog pages. The trigger conditions are successive, such that a narrower condition defined either in the embedded container or the Container Zone always prevails.
Type Restrictions
In your Container Zone setup, you can also specify the types of tags in the embedded container that the Container Zone in the main container will evaluate. If, for instance, you restrict Custom HTML in your Container Zone configuration, any Custom HTML tags in the embedded container will be overlooked within the main container.
Note, however, that the Custom HTML tags in the embedded container would still execute if that container was included directly on any other site. That is, the Type Restrictions don’t get baked into the embedded container. Instead, the restrictions apply only in the context of the Container Zone embed.
Access Rights
As a core benefit of Container Zones, you can provide different access levels to the embedded container and to the main container for a given individual. For instance, you might provide a member of your paid search team or an external team Edit access to the embedded container but only View access to the main container. In this way, you can essentially create subcontainers, with separate access rights, within a single container – Container Zones is a good name for this capability.
Access Rights Not Controlled in the Container Zone Configuration
How do Container Zones Relate to Other GTM Features?
GTM already boasted a range of access and workflow features, so how do Container Zones relate?
Approval Queue
The Approval Queue built into GTM 360 would apply separately to the main container and the embedded containers: different container, different queue. Note, however that the containers don’t need to be 360 to be embedded into a Container Zone, and so if you embed a free GTM container, an Approval Queue will not be available for it.
Workspaces
Workspaces operate independently within the main container and any embedded containers. As a reminder, workspaces disappear after publishing and need to be created as warranted, but Container Zones persist after publishing.
Folders
Folders are very useful for organizing your tasks, triggers, and variables, but you can’t control access at the folder (or the workspace) level, and you can’t publish a folder independently from the rest of a container.
Since you certainly can control access to an embedded container and publish it independently of the main container, Container Zones are in some sense the next generation of container folders.
Another Use Case: Centralized Management
A somewhat different – and perhaps more rare – use case for Container Zones would be straightforward replication of tags, triggers, and variables across multiple main containers, perhaps with less focus on Zone Boundaries and Restrictions.
Let’s say, for example, that the multiple websites that you manage for a parent company each has a separate container, but you’d like to deploy certain tagging across the multiple domains without manual replication. Container Zones could provide the mechanism for propagating your tags while continuing to manage them centrall in a single container.
Publishing Propagates to All Instances of the Embedded Container
As an alternative to Container Zones, you continue to have the option of deploying a single container across multiple hostnames, but Container Zones now enable a more hybrid central/local approach for managing tagging functionality and access rights as best suits your organization.
Even if you did deploy a single container across multiple sites, you could still use a Container Zone to isolate Custom HTML or any other tagging that needed special consideration.
Related Resources
- Tag Manager 360: From Approvals to Zones (Google Analytics Blog)
- Guide to Zones in Google Tag Manager 360 (Simo Ahava Blog)
- 8 Google Tag Manager Workflow and Security Features for Your Enterprise
- Process Control: Google Analytics and Google Tag Manager in Development and Live Environments
