GTM 360 Expands Enterprise Security and Workflow Features with Container Zones

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.

Container zones allow you to embed one or more containers within a main container for parallel processing.

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

While you can dictate which types of tags are recognized and when they can fire, the Container Zone configuration in itself does not provide any control over access rights. If an individual has Publish access to an embedded container, that individual can publish within the container, whether it is standing alone or embedded as a Container Zone. There may very well be instances in which you would want to provide some individuals with Publish access to an embedded container but lower access to the main container, but you’d need to be very clear on the publishing process. Publishing the wrong tags – or the right tags at the wrong time – can wreak havoc. Greater flexibility requires greater caution, so always be judicious when assigning and exercising access rights.

You can assign higher access rights to the embedded container than to the main container.

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.

As another pattern for Container Zones, you can centrally manage a set of tagging functionality for replication across many containers.

Publishing Propagates to All Instances of the Embedded Container

Keep in mind that once you publish a container, all embeds of that container are updated. If you have a container embedded in four other containers, and also standing alone, published changes will become live in all instances of the 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.