A Revolution of Multi-Server Testing by Google Tag Manager âEnvironmentsâ

GTM QA challenges

One big challenge for tag manager solutions (and for digital marketing workflow in general) is to keep a good balance between efficient implementation and best practice QA process. If you have multiple testing servers holding different testing sites that are managed by different teams, how do you create a safe and effective system for all teams to be able to edit and test the container versions independently on each server, but also be able to share the versions and collaborate easily?

Traditionally, you can create multiple GTM containers running independently on all environments. The QA work for each environment can be carried out on site once a version is published live in a container. You will have to either duplicate the work or import the container to share the changes across containers.

Alternatively, you can use the same GTM container across all environments. Because only one version can be live at a time, the testing site will never have a standalone “live” version that is different from the actual “live” version on the production site. Therefore, you can only debug testing sites, but cannot run “real site” QA on any of the testing sites before the changes go live. You will have to be very careful with version control especially if you have multiple teams working on testing and tagging.

For both methods, you can only share a preview link for a version at a time. If you move onto the next version, you will have to share a new link again.

Meet GTM “Environments”

GTM's ‘Environments’ feature allows you to publish any version onto any of your environments within one GTM container. Once you have published a version onto an environment, that version is “live” in that environment. You can QA each environment on the testing site directly, only this time you don’t have to export and import containers to share the changes because you are working on the same container.

If the GTM preview and debugging tools are required during the QA process, you can share the environment preview link to trigger the preview window in the browser.

You can also use a new built-in variable “Environment Name” to fire tags or to set certain values dynamically depending on the environments. For example, you can create a look up table to set up Google Analytics property ID, AdWords account ID or Floodlight advertiser ID for each environment.

Now, let’s take a close look at GTM and learn what exactly you should do to set it up.

Configurations

The “Environments” settings can be found in the container column in ‘Admin’:

First of all, click the ‘New’ button to start creating a new environment:

Add the name, description and URL for this environment, for example:

Continue to set up all the environments. The details will be listed in the ‘Custom Environments’ section:

Then you have to replace the current GTM snippet in each site with a new GTM snippet. You can find the snippet for each environment by clicking onto ‘Actions’ of the environment and selecting ‘Get Snippet’ in the dropdown menu.

Place the snippet below into the correct site.

The highlighted gtm_auth parameter in the snippet above is the key identifier of the environment. This identifier is also used in the shared preview link of the environment. It is worth clarifying several important points of the environment preview options.

Environment Preview Options

Once the environments are set up, you can start publishing versions into the environments and testing the sites directly. In some cases, you may want to use the GTM preview and debugging tools during the tests. The only way to trigger the tools in the browser for the ‘live’ version of an environment is to share the preview link.

Select ‘Share Preview’ in the ‘Action’ dropdown menu of the targeting environment.

The preview link can be found in the popup window below. As mentioned before, this link contains the same ‘gtm_auth’ identifier as the one in the snippet.

This can be used as a standalone substitute for updating the GTM container snippet codes on the testing servers. However, the standard hard-coded solution is probably the preferable option in most use cases.

The gtm_auth identifier ties the container with the whole enviroment. Instead of giving the access to any paticular container version, this link gives you the access to the ‘live’ version in the environment. Therefore, you only need to share this link once, it always leads you to the current ‘live’ version of the environment.

If you want to revoke the access of the preview window, you can use “Reset Link” to invalidate the current gtm_auth value and get a new preview link and a new GA snippet. Bear in mind that this action is irreversible, permanent and global. Once you have reset the link, the current snippet will be invalid for the environment for all users permanently. You will have to contact your developers to replace the GTM snippet every time you reset the link. Therefore, this should really be the last thing to consider. For a standard testing task, you can simply turn off the preview tools if they are no longer required.

To turn off the preview and debug tools, you have to click onto ‘Exit preview and debug mode’ in the interface that the preview link provided.

Therefore, for temporary use of the preview tools, it is worth pasting the link into a secondary tab and keeping that open until testing has completed and then click on the link above to turn the tools off.

Publish a version to an environment

There are two ways of publishing a version into an environment. In the environment list, select “Publish To…” in the “Actions” dropdown menu

And then select which version you wish to publish into this selected environment.

Alternatively, in the version list, select “Publish To…” in the “Actions” dropdown menu:

And then select which environment you wish to publish this version to

Example QA Workflow

Here is an example of a QA workflow with ‘Environments’ set up

As illustrated above, the QA process is run independently in each environment, however the handover is clear and smooth between environments. You can develop your own models that fit your site development procedure better.

Summary

In summary, GTM “Environments” has some powerful key capabilities:

1. Keep all the configurations and tags in the same container;

2. Manage tagging preview on different sites separately;

3. Create dynamic tags depending on the environments;

4. Selectively share environments preview with responsible teams; and

5. Revoke user access to the preview window for any environment.

If you are managing a big web project, with various teams and agencies are involved with the different tagging tasks, then it is time to start transforming your QA implementation using GTM “Environments” to benefit from those powerful capabilities.

To view this blog written by Yikai Wang on Periscopix's website, please click here.