8 Google Tag Manager Workflow and Security Features for Your Enterprise

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.

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.

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 Cardinal Path blog.

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.

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.

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.

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.

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.