In this article, we will look at how to configure your production website, pre-production and test environments from a single Google Tag Manager.
We will learn how to create a new version of your Tag Manager workspace, test on Staging and deploy to Production.
Indeed, we will speak about Quality Assurance with GTM.
If you are here you might know that most businesses and large entreprises have an established release process of changes on their website that involved several deployment environments.
A typical setup is made of:
- Test environment where the development team tests the new features for the website.
- Staging environment replicating your production website where final users can run acceptance tests (UAT).
- Production or Live environment for your public website.
Each new version of the website is be tested from one environment to another until it is fully validated and put online.
Familiar with this process? But do you know…. How to test your marketing tags with Google Tag Manager?
Google Tag Manager and the “environment” feature will allow you to test your marketing tags before deploying them in production.
At the end of this tutorial, you will
- Understand how to setup a Google Tag Manager staging environment and development environments.
- Have an advanced configuration of GTM.
- Know how to publish and validate your tags on different sites.
The quality workflow will no longer hold any secrets for you.
Table of Contents
What is the environments feature of Google Tag Manager?
Google Tag Manager offers a feature called Environments or simply GTM environments.
This feature let you create multiple environment and test new marketing technology integration in your test or staging server before going live.
It is critical to be able to test that different scripts or any other events or goals work properly before publishing them to Live.
To access the environment in Google Tag Manager, go to the Admin view and click on Environments.
As you can see you have already two environments, Live and Latest:
- Live is the one used by default for your production website
- Latest represents the Latest version of your container. For instance, when you save a draft version, the version is available in the Latest environment.
Set up Test Environment with Google Tag Manager
It is up to you to pick the right naming or the one compliant with your company policy. In the following example, I will name my environment Staging.
To create a new environment, follow these steps:
- Click on New from the environment panel
- Set a Name and a URL
- Click on Create Environment
- Then a window popup will invite you to publish.
- By doing this the new environment created will be exactly on the same level that the Live one (the one representing your Production website)
Congratulation, you have now three environments: Live, Latest, and Staging.
Now the last step is to install the snippet of the Staging Google Tag Manager environment on your staging website. The process is similar to what we’ve done previously:
- From the environment panel, click on the Actions link
- Copy the snippet of Staging and paste it to your staging website
Important note: as soon you create a new environment, you have to change as well the snippet install on your production. Get the snippet from the Live environment and replace it on your production site.
Great, now you have two different environments in Google Tag Manager.
So far, they have precisely the same configuration. Let’s test to add a change in Staging before releasing it to Production.
Quality assurance workflow with Google Tag Manager
Google Tag Manager let you set up a quality assurance process. It leverages the versioning and environment features.
Basically, the process is as follows:
- Create a new version of your workspace that contains the tags to be tested
- Publish the version on the pre-production environment and do some tests
- If everything works, release the version on the production environment
Create a dummy tag first
Create a new tag of type Custom HTML and copy the following code inside the HTML block:
<script> console.log("Hello"); </script>
Then a new version of the workspace
Once the tag is created, from the “Workspace” panel click on “Submit”, and this time do not publish the tag. We will only want to create a new version of the workspace.
We have two versions of the container or two different configurations available for the Tag Manager:
- The first version containing the initial Google Analytics tag
- And a second version with the Google Analytics tag and the “Hello” Tag
As you can see, only the version 1 is live and is at the moment applied to both Live and Staging environment.
Side note: As mentioned previously, Latest represents the last version of the container, which is now pointing to the version 2.
Now, our goal is to test the “Hello” tag on staging first.
Publish your changes to Staging
Go on the Version panel, and follow these steps:
- Click on the version you want to publish to the staging (in our case the version 2)
- Chose Publish To
- Select the Staging environment
- Click Publish
If you refresh the Version panel, you can see now that the version 2 is applied to Latest and Staging.
Let’s verify that the script is working and saying “Hello” to the staging site.
Go the staging website, reload the page and open the developer console. You will see a friendly “Hello” message.
Try the same test on your production site. You will not see a similar message. Indeed the production is still on the version 1 of the container.
The new tag is properly tested and works well. We will now publish to the “Live” or Production website.
Finally deploy your marketing tag to Production
Similar steps than previously:
- Go back to the Versions panel
- Click on the version 2
- Publish to and then select the Live environment.
The version 2 of the container is now available to all environments. Feel free to test on the production website.
Keep in mind, that you can as well move back to a previous version at any time.
Control the marketing tag deployments
Using the Environments and Version features of Google Tag Manager together deliver a powerful mechanism.
And as we’ve just seen, it’s not as complicated as we think.
The mechanism let you test new integrations before deploying them to production. And this is very important for any enterprises using several environments. You don’t want to mess-up the Prod!
Go further with Google Tag Manager
This article is part of on advanced tutorial of Google Tag Manager and Analytics.
In the following articles, we will look at the advanced concepts that are often necessary for the configuration of professional websites.
I invite you to continue configuring your site by taking advantage of the Google Tag Manager environments by configuring Google Analytics across multiple domains.
How do you handle a situation where one workspace is in staging, but you have another workspace that is ready to go to production without the staging workspace?
What do you try to achieve is tu push some changes directly to the live environment?
Then you can publish them directly.
The purpose of the staging is to be able to test before going live.
We have a live production environment with many versions deployed. Now I’d like to enable a test environment. Should I publish all the live tags to the staging environment before implementing the next tag in staging?
Another way of asking this is, is it problematic to have some but not all of the tags firing in both environments?
I could have only one version published to one environment. I assumed that you have the latest version published to the Live.If you have a staging environment and want to have the same tag that the Live. Go in the version panel and publish to staging the latest version.
About firing different tag in both environments. Indeed it could make sense that some tags are not fired in staging, for instance, if they collect data that could then pollute the system connected to the tag.
Which GTM code I should use for the Live/Production environment of the site? Default GTM tracking code or the code from the Live environment? I am confused on this.
Default tracking code does not contains the env id and authentication code.
If Im not mistaken, the default == the live. But take the Live and you will be fine.
I think this is a very clear explanation for setting up environments. However, it doesn’t seem to address for me an obvious question – if I’m adding the staging tracking code to my staging environment, isn’t that going to override the live tracking code when our developers push the next iteration of the staging environment live?
You should manage environment-specific files in your web project. Or the best is that the setup of the tag is not hardcoded but done via a plugin, then you can separate the configuration per environment and avoid overriding tag when deploying new code.
Hi, according to Google’s documentation (https://support.google.com/tagmanager/answer/6311518?hl=en#installContainerSnippets) you shouldn’t use environments in production, not even “Live”, it might decrease performance. Use the vanilla GTM snippet instead (without env parameters).
Thanks for the tip!
Hi Samuel, thanks for the explanation but for me, there is one problem left:
1. I have two Workspaces, for example for new marketing tags. Lets call the tags and the workspaces A and B
2. I have two environments: TEST and LIVE
3. Imagine Workspace A is publishes to TEST
4. While A is still not fully tested, Workspace B is also published to TEST (so now tags A and B are available for Testing on the TEST environment).
5. Tag B is very important and sucessfully tested. Now I only want to publish tag B to LIVE. Not A as it is still not fully tested.
–> Does it mean that I first have to create a new Workspace where A is deactived, pulish this to TEST and LIVE. Then activate A again and pulish only this to TEST to continue testing?
–> Maybe this is not a good example as according to the last comment, environments schould not be used on LIVE…. But the same problem might appear when there are there are different environments for DEVELOPMENT and TESTING
Looking forward to your thoughts.
thanks for your comment.
I will proceed this way and create a new version without the Tag A for your live environment. Keep in mind that a workspace in Tag Manager is a place to work on a set of changes that will become a version.
About the environment, to jump on the previous comment, Google says that the “standard snippet” must be used for the Live website. Google never said that you should not use the environment features… otherwise I missing the point.