Restrict tag deployment

Although it's not recommended to restrict the types of tags deployed using Google Tag Manager, for various reasons it might be necessary to restrict the tag types deployed on a site. For example, some site owners might not want Google Tag Manager users to be able to add certain tags to their site for code stability or data collection reasons. This document describes how to restrict tag deployment in Tag Manager.

To control which tags, triggers, and variables are allowed on a page, use the gtm.allowlist and/or gtm.blocklist keys in your data layer. These keys will override any and all configuration in the container. When properly blocklisted, tags, triggers, and variables won't fire even if they have been configured to fire in Google Tag Manager.

The following example demonstrates how to initialize the data layer with both an allowlist and a blocklist. Both lists are optional, and you can use them separately or together (as shown). Both lists must be of type Array, and the values in the list must be of type String. These values should be pushed to the data layer before any tags fire:

<script>
window.dataLayer = window.dataLayer || [];
dataLayer.push({
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['<id>', '<id>', '<id>', ...]
});
</script>

Each ID in the list corresponds to a specific tag, trigger, or variable type, or to a class of types. Classes represent groups of tags, triggers, and variables that have the same capabilities. For example, all tags that can send pixels to non-Google domains will have the class nonGooglePixels. Classes are useful for blocking capabilities in current and future tags, triggers, and variables.

It's important to understand the rules that govern allowlists and blocklists:

1. Allowlists When an allowlist has been set, relevant tags, triggers, and variables will only execute if they are in the allowlist, either explicitly (by type ID), or implicitly (by having all of their classes in the list).
2. Blocklists When a blocklist has been set, tags, triggers, and variables will only execute if they are not in the blocklist, either explicitly (by type ID), or implicitly (by having any of their classes in the list).
3. Blocklists override allowlists When both have been set, blocklists take precedence. You can use an allowlist for a class of tags and a blocklist for a specific tag in that class, but the reverse is not true. You cannot use a blocklist for a class of tags and an allowlist for a specific tag in that class.
4. Classes have relationships Some classes have relationships with other classes. For example, tags that can run non-Google scripts can (by definition) send non-Google pixels. For this reason, blocking nonGooglePixels will also automatically block nonGoogleScripts. All tags, triggers, and variables that belong to either group will be blocked.

The following table provides a listing of the available tags, triggers, and variables, their types, and the classes that they belong to:

The following table provides a listing of the available classes and their relationships to other classes. The Allowlisted Automatically column represents the list of classes that will be implicitly allowlisted when the class from that row is also allowlisted. Likewise, the Blocklisted Automatically column represents the list of classes that will be implicitly blocklisted when the class from that row is blocklisted.