It’s with great enthusiasm that we at E-Nor witness the steady rollout of new features in Google Tag Manager, in relation to the tags, triggers, and variables themselves as well as to workflow, security and overall governance.

In this post, we review eight GTM workflow and security features, both new and long-standing, and all useful as we incorporate GTM and GTM 360 into our enterprise-level tagging and development strategies.

1) Edit vs. Publish Rights

At a basic level, let’s consider Edit vs. Publish rights. One of the value propositions of GTM is, of course, greater involvement of marketing and analytics teams in the tagging process. We can provide Edit rights to several individuals to enable them to add tags, triggers and variables to the container.

Where there is greater flexibility, however, we must enforce greater control. By assigning Publish rights to only one individual or a very small team who understands the purpose and the status of every tag, trigger, variable, workspace, and environment in your GTM container, you can minimize the chance of unwanted surprises.

When multiple people have Edit access to a container, it’s highly recommended to provide access rights only to those users who understand the purpose and status of everything in the container.

2) Workspaces

You can create separate workspaces for different individuals or teams (such as a department or even an outside agency) to isolate their work and to approve/publish separately. In the free version of GTM, you can create two workspaces in addition to the Default Workspace; in GA 360, workspaces are unlimited.

For a full walkthrough, see Google Tag Manager Workspaces on our blog.

You can create separate workspaces within your container for individuals, departments, and outside agencies.

3) Environments

GTM environments allow us to first publish a container/workspace to a development or staging server instead of immediately publishing to a live server.

For a discussion of GTM Environments, see Process Control: Google Analytics and Google Tag Manager in Development and Live Environments on the E-Nor blog.

You can create separate environments to test your new GTM tagging before publishing to your live Web server.

4) Blocking Triggers

Want to be absolutely sure that your tags won’t fire in your live environment until you’re ready? Apply a trigger exception (also referred to as a blocking trigger) to your tags, and remove them only when you’re ready to publish live.

If you’re using separate GTM Environment snippets on your actual development and live Web servers, a blocking trigger based on hostname can provide an extra level of protection in that it would prevent a tag from firing in on your live server even if you accidentally overwrote the GTM Live Environment snippet with the Environment snippet for your development or staging environment.

If, instead, you’re using just one container version in all environments, a blocking trigger would be especially useful for making sure that the tag doesn’t fire on your live server until you want it to.

You can define a trigger based on hostname and apply it as a blocking trigger until you’re ready for your tag to fire in your live environment.

5) Approval Queue

The Approve role has been present in GTM as far back as we can recall. It was previously related only to a very specific AdWords tagging approval, but it has recently taken on a much bigger role in GTM workflow management.

Essentially, the new approval queue explicitly breaks approval out as a separate step preceding publishing and formalizes the process of requesting, rejecting, and approving changes within the GTM UI.

Note that this functionality is available in GTM 360 only. For the full scoop, check out New Approval Workflow In GTM 360 on Simo’s blog.

The new Approval Queue in GTM 360 formalizes an approval process before publishing in GTM 360.

6) Versions

Every time you publish a workspace in GTM, you create a new version of the container within which the workspace resides. You can also create a version anytime you want to save a specific state of the changes you have made to your container.

In this way, each version serves as a snapshot of your container. Apart from providing a scannable timeline of your container’s evolution, versions allow you – critically – to republish an older, functional snapshot of your container in case you need to roll back from a more recently published version.

If you need to roll back your most recently published container, you can restore to a previous version.

7) Two-Step Verification

You can require Google two-step verification for the sensitive/error-prone actions in GTM, specifically: creating Custom HTML tags and JavaScript variables, and editing access rights.

Two-step verification requires an additional authentication step before can users can make potentially sensitive changes in GTM.

8) Blacklisting and Whitelisting

As an especially stringent measure, you can add code-level restrictions against publishing certain types of tags, triggers, and variables (again, such as Custom HTML tags and JavaScript variable); no GTM user could override these restrictions through any changes in the GTM UI.

For more details, see Restricting Tag Deployment in the Google Tag Manager Developer Guide.

dataLayer = [{
  ...
  'gtm.blacklist': ['html', 'j',];
}];

This code would prevent Custom HTML tags and Custom JavaScript variables from firing on the page.

Stay tuned: more workflow and security features in GTM will likely appear as the tool’s capabilities continue to unfold.