Working on big projects with a lot of tracking can have a lot of challenges, but I think the biggest one is related to the architecture. That’s because we’re not talking about just a couple of tags and triggers, instead, we’re talking about hundreds.
In this post, I’ll be sharing one of the worst Google Tag Manager (GTM) errors that someone can have in a big and complex architecture, a solution for this error, and also some guidelines on how to design a good architecture.
When Is Size Limit a Problem in GTM?
A GTM container has its own size limit, which is 200kb. This is what the error looks like:
The worst part about this error is that to fix it, you need to delete tags, triggers, or variables, but these are only short-term solutions. Another related problem with having such a big container is that the page load timing is affected. When there is a page load timing issue, everyone’s first look is at analytics implementation to see how much it is affecting that. However, there is a solution to prevent this error from occurring.
Advantages of GTM 360
The solution provided can only be used if the GTM is the enterprise version, which is called GTM 360. This version provides a couple of new, unique features compared to the free version of GTM.
One of the improvements that comes with GTM 360 is the unlimited workspaces. The free version has only three workspaces, but the enterprise version no longer has this restriction.
The most important feature, and the reason why this solution can only be implemented with GTM 360, is zones. Basically, the new architecture that solves the size limit issue and improves the page load timing is based on this feature.
Another great improvement is the approval workflow, which can help create a better publishing process within GTM. With this feature, a new step is added in the publishing process, which is approval request.
This feature is a very good addition for a release process, which can be used to push the analytics engineer to ask for approval from a tester or another engineer who will make a code review.
Principles of Zone-Based Architecture
A zone allows you to link additional GTM containers when your main container loads, so that the linked containers are allowed to fire tags on your website. Zone boundaries can be configured to define which pages the zone is active on, and you can restrict the kinds of tags that a linked container can fire.
The main advantage of using zones is that with boundaries, you can choose which tags, triggers, and variables should be loaded in a specific page and which shouldn’t. This feature can also be a disadvantage if it is not used properly.
The principle of the zone-based architecture is to split tracking to reduce the tracking which is not used on the page to be loaded. Basically, one container will be integrated on the site and will have all the general tracking that is needed, but the tracking that is not global will be split in the other two containers and will be integrated via GTM 360 zones.
The first step in implementing the GTM 360 zones architecture is to create two new containers. Those containers will be used as zones and will be included in the general container via the GTM 360 zones feature.
Also, don’t forget that the containers were newly added and used as zones that were empty, so you may end up having the following issue on your site:
This issue will be solved when you make the first publish on the new containers, so that the containers won’t be empty anymore.
The most important step for this implementation is deciding how the actual tracking will be split into three containers. One suggestion is that one container should be general and not have boundaries. That container should contain tracking for the general elements like header, footer, and may also include all the pageviews from the site. The other two containers should have the tracking specifically for different sections from the site. The best case scenario is to split all the remaining tracking into two pieces and not have any overlap. The more overlap you have in those two containers, the more this feature is implemented as a disadvantage instead of an advantage.
General Guidelines for a Good Architecture
In the end of this post, I want to leave a couple of recommendations for you to think about when you are designing a new tracking architecture.
One of my first suggestions is to use folders. Every section of the site should have it’s own folder with all the events, and also a folder for all the pageviews and the variables should be split on folders based off the type. The only folder which should have zero items is the unfiled items folder.
Another suggestion is related to the naming of the items. Every item should use a naming convention that would be very easy to find. This is an example of how a naming convention can be applied:
Tag: Section E.1 Additional Info – UA
Trigger: Section E.1 Additional Info – Click
This way, you will know in which section the tag or trigger belongs, if it’s an event(E) or a pageview(P), every tag will be numbered and you will know the type of tag or trigger.
There are a lot of errors which may occur in a big analytics implementation, and we have solved a couple of those errors. A good way of using containers via GTM 360 zones can solve some of the worst problems that a big tracking architecture can have. For example, size (200kb limit) and page load timing. Every project is different, so there is no universal answer for a good architecture, but there are some guidelines, when used correctly, that can save you from a lot of headaches.