For some reason, you might run into a situation where you need to add multiple Google Tag Manager containers on the same page. Usually this is because of poor governance or an inflexible organization. My recommendation is to fix things in your projects first, and only resort to multiple containers if you can’t seem to resolve your governance issues using your vocal cords (or your fists).
Officially, Google Tag Manager introduced support for adding multiple containers earlier in 2015. It’s still not a recommended process, however, and rightfully so. Personally, I hope that development efforts in GTM would be directed towards making a single container more manageable by different parties, rather than adding support for hacks like this.
In any case, this tip post is to remind you of how multiple containers can be implemented on a single page.
The Simmer Newsletter
Follow this link to subscribe to the Simmer Newsletter! Stay up-to-date with the latest content from Simo Ahava and the Simmer online course platform.
Tip 37: Multiple containers use the same dataLayer
As you can see, the implementation is simple. Just add your containers as you would normally, but remember to use the same name for dataLayer
across the container snippets. This is an important thing to note, because the unofficial recommendation before this support surfaced was to rename the dataLayer
objects across the different containers.
GTM takes care of the rest. Triggers should not have any conflicts, and even though the gtm.js event is pushed into dataLayer
multiple times (by each container snippet), your All Pages and Page View Triggers should still just fire once per container.
One place where potential conflicts can surface is with Data Layer Variables. When you push a key-value pair into dataLayer
, it’s registered just once, but each container will have access to this value, even if you pushed it “for one container” only.
This means that with stuff like Enhanced Ecommerce tracking you might run into a situation where Tags in container B are inadvertently sending Ecommerce data, when you only intended Tags in container A to send them.
The best way to mitigate this is to send an ‘event’ key with each Enhanced Ecommerce push, and then purge the key from the data layer after the Tag has fired. You can use hitCallback or eventCallback for that.
Adding multiple containers is definitely not optimal, and there are many things to take into account, but it’s doable if you devote some time to the implementation. Naturally, I would suggest you devote this time to making the organization work with just one container, but sometimes inflexibility takes precedence.