How To Deploy Google Tag Manager on Multiple Websites

Google Tag Manager is a comprehensive and flexible platform that allows you to create and test new events and tags before you publish them, but what if you want to test new tags in Google Tag Manager on multiple websites? Perhaps you have multiple pre-production environments, such as DEV, SIT and UAT or different subdomains. With some complex implementations, such as cookie policies, you may also want to publish tags in a non-production environment before publishing to the live environment.

A major advantage of migrating to GTM for Google Analytics is there should be no reason why you can’t configure and test tags in Google Tag Manager on multiple websites before new pages or functionality is released to the live environment. This means you can have data collection and reports built before release goes live.

Align testing implementation with organisation’s web development:

How you decide to set up Google Tag Manager on multiple websites needs to be aligned to your measurement plan, but also how your organisation’s web development is managed and deployed. Assuming you have already migrated from Google Analytics base to Google Tag Manager you may not want to have to reinstall new code or maintain different code in each environment. There are four options open to you here:

1. RegEx or Lookup tables
2. Blocking triggers
3. Separate containers
4. GTM Environments

Create your Google Analytics Properties:

Once you have all the URLs for your pre-production websites or other subdomains you wish to track you can create a Google Analytics property for each site. Normally I recommend using the same GA account for all subdomains so that your client has all of them together, even if you don’t report on testing environments. If you need more information, go to my guide on subdomain tracking.

The first option for managing Google Tag Manager on multiple websites we will cover is RegEx and Lookup tables. That’s because this method can meet the needs of many users and you may not need to investigate the other options if this is suitable to your circumstances.

1. RegEx and Lookup Tables:

When managing Google Tag Manager on multiple websites many users go for Lookup Tables to input the absolute URL to direct traffic to individual GA properties. This is one option, but a more flexible and scalable solution is the RegEx Table. We will initially cover a situation where each environment is on a separate domain and then I’ll explain how to change this for environments on the same domain (i.e. subdomains).

Go to your GTM container and create a new Workspace to save the changes you are going to make. We will begin by creating a new user defined variable as follows:

1. Name: GA Tracking ID
2. Variable Type: RegEx Table
3. Input Variable: Page Hostname (Where sites are on separate domains)
4. Pattern (Input): .*staging-examplesite.* (insert your root domain)
5. Output: Insert the GA property IDs for subdomains (e.g. staging sites)
6. Set Default Value: Enter the GA ID for your production website here.

We use Page Hostname so that GTM returns a string containing the hostname and ignores any protocols. The RegEx Table allows us to use basic regex of “.*” before and after the root domain. This tells GTM to send data provided the domain contains the specified URL name (for example ‘dev.examplesite.com’). If you have a ‘.’ between fragments of your domain you will need to use the backslash ‘\’ before the ‘.’ as this escapes it as it is a RegEx character.

By setting the ‘Default Value’ as our live site this means all data other than for the staging sites outlined in the RegEx Table will be sent to our live site’s GA property.

Tracking Subdomains:

If staging sites are subdomains on the live site’s domain, you can adjust the settings by changing the ‘Input Variable’ to ‘{{Page URL}}’ rather than ‘{{Page Hostname}}’. Then insert the unique part of the subdomain name (e.g. .*dev.* if your site is dev.examplesite.com) into the pattern field. GTM will then search for any URL which contains the unique subdomain name.

GA Settings Variable:

We now need to go to your GA Settings Variable (see below) and replace the GA property ID with our new RegEx Table variable – {{GA Tracking ID}}.

Preview Mode:

You can take this a step further by creating a separate GA property for GTM Preview Mode and using a Lookup Table to direct the data as required. Go to ‘Built-In Variables’ and select ‘Configure’ to check that you have already activated the ‘Debug Mode’ variable.

You can then scroll down to user defined variables and select new:

1. Name: Preview Mode
2. Variable Type: Lookup Table
3. Input Variable: Debug Mode
4. Select ‘+Add Row’
5. Lookup Table Input – Row 1 : true
6. Lookup Table Output – Row 1 : Insert the GA property ID for your new preview mode property.
7. Select ‘+Add Row’.
8. Lookup Table Input – Row 2 : false
9. Lookup Table Output – Row 2 : Search and select your new GA Tracking ID variable.
10. Set Default Value: Search and select your new GA Tracking ID variable.
11. Save the variable.

The new Preview Mode variable should look like this.

You will now need to go back to your GA Settings Variable to replace the ‘GA Tracking ID’ variable with your new Preview Mode variable and Save.

You have now set up a new process for when a tag is triggered. This means that when a trigger on a tag is accepted the following will happen:

• The trigger will check the GA Settings value, which will be {{Preview Mode}}.
• This will then do the following checks:
• Is Debug Mode active?
• If so, send the data to the GA Property ID for Preview Mode
• If no, check the GA Tracking ID variable
• In the GA Tracking ID variable, GTM will do further checks:
• Does the domain that has triggered the tag contain one of the domains or subdomain fragment?
• If so, direct the data to the GA Property ID specified.
• If not, send the data to the GA Property ID defined in the ‘Set Default Value’.

2. Blocking Triggers:

Triggers are normally used to tell GTM when to fire a tag, but blocking triggers are used as exceptions to say when not to fire a tag. For example, you won’t want your advertising tags to fire on a staging environment. To prevent this from happening you could create a blocking trigger using the hostname to tell GTM not to fire if the hostname equals your staging site.

Alternatively, if you set version numbers for website updates you could create blocking triggers based upon the version number. Provided the version number is accessible somewhere on your website, you would just need to create a data layer variable to capture it. Your blocking trigger would then use the live version number to determine if a page is on the staging site or not.

For more details on how to create blocking triggers go to this excellent article by Jon Meck which explains how to use trigger exceptions in Google Tag Manager.

3. Containers:

It is feasible to maintain separate containers for different domains or subdomains. However, you would have to ensure you maintain identical tags etc in all containers once you make a change in your master container (e.g. UAT). This can easily be done importing the master container on a regular basis. It is a somewhat old-fashioned and manual method given we have other more efficient ways of managing Google Tag Manager on multiple websites.

4. GTM Environments:

It is possible to use GTM’s preview and debug mode to test most tags without having to publish changes into the live environment. However, for more complex tags there may be good reasons to want to do more extensive testing in a staging environment and not to rely on preview mode. In these instances, GTM Environments allow us to publish workspace changes to a specific environment.

Always use an environment as close to your live site as possible. For example, DEV sites are usually changing too frequently and are often very different from your live site and so are generally not suitable for testing. You may still want to use it for early stage development, but UAT is normally a better and more stable environment to test GTM.

To set up a new GTM Environment, go to Admin > New > Name your new Environment > Create Environment. At this point GTM gives you two options.

Share Preview Link:

This allows you to share the environment’s container configuration via a link. Select ‘Turn on debugging when previewing’ before copying the link as this will give users access to your container in Preview mode. Once you have created your new environment you will be able to test and share an individual environment and version of GTM to facilitate testing.

With a Snippet:

The second option involves adding a unique snippet of code to your staging site. You will notice the GTM ID is the same as your existing GTM script, but it has been modified to include an authentication token. You will need to remove the existing GTM script and replace it with this environment code instead.

Once you have implemented the GTM Environment snippet you will be able to publish changes directly to the new environment without the need to publish to your live site. Having different environments also allows you to create blocking triggers based upon the Environment Name variable. For more on setting up GTM environments see this blog by Samuel Schmitt.

Summary:

The ability to simultaneously deploy Google Tag Manager on multiple websites is one of the major benefits of GTM. The great thing about GTM is that you have multiple ways of doing this that can fit in with your organisation’s set up and release processes.

I recommend that you use RegEx and Lookup tables when appropriate as this method avoids any code changes and developer resource. It’s an agile and flexible way of deploying Google Tag Manager on multiple websites. It can be fully tested in Preview mode before being published to the live environment.

Blocking triggers should also be deployed for preventing environment sensitive tags from firing on subdomains. For example. user experience tags, such as for Hotjar, will often fire in pre-production environments because no one has thought to set a blogging trigger as an exception.

Separate containers are a less efficient method for deploying Google Tag Manager on multiple websites. I’d avoid this unless you have good reason to want to maintain separate containers.

Finally, GTM Environments are a valuable alternative method for deploying Google Tag Manager on multiple websites. The ability to either share a link to the environment or add a new snippet to the site gives you the flexibility which helps when developer resource is often scarce and getting into a release is time consuming and difficult for what are perceived to be low priority changes.