Restricting Tag Deployment in Google Tag Manager

There are plenty of reasons to put the brakes on deploying tags, triggers, and variables in your Google TagManager container. Sure, the Google Consent Mode (GCM) takes care of most scenarios, but that's not our focus here. We're zooming in on the specific case where 3rd parties have access to the web resource, and we want to prevent unchecked deployment of tracking code.

There are numerous examples of 3rd parties co-administering a web resource and being able to roll out tracking code.

3rd parties in Tag Management

? Teams managing different language versions or sections of the website or shop

? Marketing and Analytics agencies

? Data Scientists

? UX/UI Experts

? Other Developers

Even with strict regulations, regular security checks, and centralized website management, unwanted tracking-code can sometimes slip onto the scene.

While it's not exactly recommended to limit the tag types provided by Google Tag Manager, sometimes you might need to do it for various reasons. Picture this: some website owners don't want GTM users adding certain tags to their site, either to keep the code stable or because they're wary of their data being collected. This article dives into how to tighten the reins on tag deployment in Tag Manager.

With the magic gtm.allowlist and gtm.blocklist in your data layer, you can decide which tags, triggers, and variables are fair game on a page. These keys override the entire configuration in the container. If you've got a solid blocklist set up, tags, triggers, and variables won't fire, even if they're configured to do so in Google Tag Manager.

Showcasing the gtm.blocklist

In my scenario, I want to block Google tags, including the GA4 tag and GA4 event tag.

To pull this off, we utilize the gtm.blocklist - either directly in the website's code or during the initialization of the data layer. I execute the command via custom HTML, even before any other tags are fired.

<script>

window.dataLayer = window.dataLayer || [];

dataLayer.push({

'gtm.blocklist': ['ga', 'gcs', 'gtm', 'gaawc', 'gaawe', 'ts']

});

</script>        

You can find the IDs for all common tags, triggers, and variables here: https://developers.google.com/tag-platform/tag-manager/restrict

What else? gtm.allowlist, tag classes and more

Similarly, we handle the gtm.allowlist. Here, it's the reverse. Only tags listed on it will be fired. By the way, the same goes for triggers and variables. Any variables not on the gtm.allowlist won't work. This way, we could, for instance, prevent credit card data or other sensitive information from being intercepted.

By the way, it's good to know that blocklists take precedence over allowlists. When both are in play, blocklists rule the roost. You can set an allowlist for a category of tags and a blocklist for a specific tag within that category, but you can't flip it around. In other words, you can't have a blocklist for a category of tags and an allowlist for a specific tag within that category.

Here's the scoop: Classes of tags have relationships. Some are tied to others. Take, for instance, tags capable of running non-Google scripts—they inherently send non-Google pixels. So, blocking "nonGooglePixels" will also automatically block "nonGoogleScripts". This means any tags, triggers, or variables belonging to either group will be blocked.

Conclusion

I get it, this article delves into a niche topic. Ideally, there should be centralized management for the GTM container and website tracking, while on the flip side, users can decide through GCM which data they truly want to disclose.

However, in special circumstances, gtm.allowlist and gtm.blocklist can swiftly and easily rein in third parties, putting control back in our hands where it seems to have slipped away.