Google Tag Manager 360: A New Approach to Zones

by Ricardo Cristofolini

Google Tag Manager (GTM) can have many applications and it can save you a lot of headaches when properly utilized. From a single place to add all the necessary scripts, to site performance and user advantages, GTM can help developers and marketers from all sides. However, a specific structure that is only available within GTM360 – one not many people talk about – is Zones. Now, you may find a lot of information on how to implement and configure Zones in GTM360, but I’m going to try a different approach, the article focuses on what you can do with Zones to help your IT department and company to grow.

Now, I’m assuming you have already read about Zones, have implemented or even seen a container with them and its structure. I may touch briefly on these topics, but my main objective is to get into the different approaches you can have with them.

Zones Objectives

When talking about architecture, we usually think of a final plan or construction. You may have read the Zones structure is to have multiple containers firing in the same page, that the master container should hold all the common structure of the site, and zones are for specific areas. Well, these aren’t wrong ideas, but remember all companies are different and, because of that, a single recipe won’t fit for everyone.

That being said, there is no correct or incorrect architecture for the Zones. The applications of it and the Master Container can be implemented and used in a variety of ways. Furthermore, what seems right for a specific scenario may not be the best fit for another. Therefore the architecture must provide guidance based on what is best for your company in general.

Some companies may be looking to expand the IT team and divide the site into smaller sub-departments, or have a third party marketing company taking care of specific pages. Others are looking to decentralize the Master Container as it grew so much it’s hard to keep up with the expansion.

Zones Hierarchy

The main understanding of zones heavily relies on linked containers or more specifically, a master container and individual zones. Designing your tagging deployment with this hierarchy allows for improved governance as well as scalability. Furthermore, the Master Container allows for cross-domains functionalities to be loaded within one single location. One of the benefits of this method is that developers do not have to recreate all of the tags, triggers, and variables across all of the Zones.

Well, that’s not wrong, but let’s keep an open mind about the Master Container. This container can also act as a delegator where it will provide guidance on which Zone should load and what type of tags and scripts should be authorized to load. This specific approach would allow the main development team to assign responsibility to individual teams, whether internal or external, while still maintaining control over all containers.

Keep in mind that owners of the Master Container are responsible for identifying what rules should be set and what boundaries should be established based on a macro understanding of the tagging and domain architecture.

Zones Applications – Use Cases

Before we dive into use cases, it’s important to understand that every application of the Zones will come with Pros and Cons. A single and perfect structure that solves all your problems won’t exist. If you think Zones will solve all your problems, think again.

Now that we are clear on that, let’s imagine that Company XYZ has a website and has been using GTM for a while. The website is growing and with it, the number of tags that GTM holds. The current IT team is delaying the deployment of new tags and variables updates and the marketing team keeps pushing them because they need the reports to make better decisions.

Here are a couple of ways the IT Team can tackle this problem in order to avoid delays and future problems.

First Approach

Thinking in the long term, the main approach here is scalability. Keeping in mind that new pages will be developed, new tags will have to be updated and implemented and there’s no time to waste. One option is to leverage the Master Container as a delegator of individual zones and their respective boundaries. All measurement is executed through the individual zones.

Pros:

  • 100% autonomy for the Zones: Page views, events, custom dimensions, marketing tags, etc, will be handled by the zone itself. The specific team delegated for that Zone (which loads in a specific part of the site) will be doing all the work.
  • Individual container configuration: No more mix of tags and variables with other teams and/or fighting over which configuration is correct.
  • Reliability on the specific team: This is focused on less work and more quality. Instead of having 20 tags for a single team, now we have 5 tags for 4 teams, for example.
  • Master Container control: The master container is still in control of all the boundaries and rules for the zones. That’s the beauty of them.

Cons:

  • Duplicate configuration: It’s true that all the Zones will have to have the same GA tag, for example, and that can be considered work duplication.
  • Reliability on the specific team: No, it’s not a mistake. The same can be applied here if your company relies on a third-party marketing agency, for example, they may have an implementation schedule different from yours. And that can be a problem.
  • Mutually exclusive: This is a bit tricky and only applies to specific scenarios where roll-up properties are in play. The problem here lies in having a Master Container with a page view that loads a Zone also with a page view. Now if each of these page views reports back to different GA properties, if you roll-up them, you may have duplicate counting due to the URL where the containers fired.

Second Approach

This option focuses on diving the measurement requirements from ad-tech and on-site experiments. All GA measurements are executed within the master container, while tertiary tags and triggers are handled by the respective zones.

Following the same scenario above, unfortunately, company XYZ do not want to give full autonomy to the Zones and teams as they are still in training and have little experience. Within this approach, the main IT team will be responsible for the overall authority in the Master Container, page views, custom dimensions, and events will all be handled by them.

Pros:

  • Consistency of general events: Like the Zones, the approach for tags, variables and triggers can vary depending on the team dealing with it. In this case, no more different approaches in order to reach the same objective.
  • Control over GA configuration: Having each team increases the risk of missing tags or data if they miss a configuration.
  • No duplications: As mentioned before, giving 100% of autonomy to the Zones will come with the duplication of tags. Here, everything will live in the Master Container so, no duplications.

Cons:

  • 90% Zones autonomy: If a Zone team is looking to implement a new custom event, it will have to rely on the main development team to do so.
  • Specific Role required: Because the main structure of GA will live in the Master Container, it will require someone or a team that understands measurements, to have report consistency.

A Third New Approach

It can happen that none of the previous approaches will satisfy the objectives of your company. While it’s important to give 100% autonomy to the Zones, you can’t always rely on the teams to know how to properly implement tags and triggers. Some teams may use a single trigger for custom events based on the Data Layer, others will create specific tags for each of the custom events in the page. These approaches, while not wrong, can cause the paths to deviate from implementation consistency and practicality.

To tackle that situation, one we suggest using Templates.

Google Tag Manager gives you the ability to export and import containers so company XYZ can have a Model Container (not the master one) that will hold all the updates and consistencies. That model can be exported and sent to all of the team leaders responsible for the Zones, imported and merged into the default workspace – or a new one. With that, whenever a new update needs to happen in the general content, the Model Container can be sent to the teams with the updates.

Going even further, if the main IT team wants to have consistency over all the Zones, but still give them autonomy to work individually, Model Containers could be created for each Zone. Rarely will all the Zones need an update at the same time, so that gives even more control to the main IT team to keep things in order.

Future of Zones

Google keeps improving its tools and there’s a lot of functionalities where we don’t need to follow all the rules in order to get what is best for our company. That’s why dealing with Zones, for example, is so amazing. It gives you the option to delegate, to control, to keep everything in one place, to have separate teams – or external companies – all helping you grow your website.

Using Zones is highly recommended in terms of scalability, controlled decentralization, external marketing teams that deal with different tools, or simply because of privacy, this GTM tool can help you. Remember that is not a matter of the company to adapt to the tool, but the tool to adapt to the company. The goal is to land on that balance between Pros and Cons and what works best for you.

Ricardo Cristofolini

Implementation Specialist

I’m passionate about what I do. If you meet my manager or co-workers, they would say I’m a team player, engaged and always excited to learn something new. Like everyone else I have some flaws. However I’m not afraid to work around those to bring the best in myself and for the company.

See more posts from Ricardo