Simple tracking testing with Google Tag Manager Environments

Google Tag Manager Environments is a GTM feature that allows you to create different versions of a single GTM container across different website environments. You can have separate environments to test any changes in your tracking setup before releasing them to production. And you don’t need to create separate GTM containers for each website version – you can manage everything from a single container.

A typical GTM Environments setup might include:

• Production.
• Staging.
• Development.

This approach is particularly useful for ecommerce businesses and organizations that rely heavily on accurate conversion tracking, where even small data collection issues can impact optimization decisions. You can troubleshoot any changes on a test version of the container, and then publish the changes to production once you’re ready.

If you wish to use GTM Environments to test your Stape sGTM hosting setup, there is one additional step to keep in mind. GTM Environment parameters are not automatically included in the Custom Loader snippets, so you need to add them manually. 

Custom Loader is Stape’s free power-up that helps reduce the impact of ad blockers by loading Google Tag Manager and Google Analytics 4 through your own domain instead of Google's default domains. This is a necessary part of any sGTM setup using Stape, as it can significantly improve data collection accuracy and reduce tracking loss.

In this guide, we'll show you how to use GTM Environments with server-side tracking via Stape, and how to verify that everything is working correctly.

Google Tag Manager Environments are particularly useful for larger organizations, agencies, and enterprise teams that manage complex tracking setups across multiple stakeholders, testing servers, and release cycles.

• Teams can collaborate across multiple environments: different teams can work on and validate separate versions of the same GTM container simultaneously. For example, developers can test new tracking implementations in a development environment while QA teams validate another version in staging, without affecting production tracking or each other's work.
• Use consistent, dedicated preview links: anyone using an environment’s preview link will see the most up-to-date published version assigned to that environment (unpublished changes will not appear). You do not need to generate and send a new link to your QA team or clients every time you publish a new staging version to the container.

• Simulate different user scenarios: you can recreate potential situations that may impact tracking performance in a safe setting, such as simulating various errors on the client’s side. Testing with Custom Loader in a non-production environment also helps identify any potential issues early and prevent inaccurate reporting after deployment.
• Prepare major tracking changes ahead of launch: when a significant website update, platform migration, or tracking overhaul is planned, you don't have to wait until launch day to configure and test everything. GTM Environments allow you to prepare changes weeks in advance, validate them in a staging environment, and keep them isolated from production traffic until the release date.
• Save time and money during future releases: once a testing workflow is established, teams can consistently validate new tracking updates, tags, and integrations before publishing them. Fixing issues before deployment is significantly faster and less costly than troubleshooting them after they impact live campaigns.

GTM Environments let you load a specific version of your container (e.g., staging or development) instead of the published version. If you use environments, you need to manually add the environment parameters to your Custom Loader code.

1. Get your environment parameters.

• In web GTM, go to Admin → Environments.

• Find your environment and click Actions → Get Snippet.

• Copy the three parameters from the snippet URL: gtm_auth, gtm_preview, and gtm_cookies_win.

2. Add the environment parameters to the head snippet.

Where you add the parameters depends on whether your Custom Loader snippet uses Cookie Keeper.

3. Add the environment parameters to the body snippet.

Do the same for the body snippet:

Append the same parameters to the iframe URL in the body snippet (replace the gtm_auth, gtm_preview, and gtm_cookies_win in the example with your own respective parameters):

To verify the setup is working:

1. 1.
   Open any page on your website.
2. 2.
   Right-click → Inspect → open the Network tab.
3. 3.
   Filter requests by your custom subdomain or same-origin path.
4. 4.
   Look for the GTM request URL – it should return a 200 OK status code.

Imagine an ecommerce website that uses a staging Google Tag Manager environment to test tracking changes before publishing them to production.

Without Custom Loader configured on such a staging environment, it is impossible to test how resilient your tracking setup is to ad blockers. As a result, when you release the changes to production, your users’ ad blockers may prevent GTM and GA4 scripts from loading, reducing your tracking performance accuracy.

By combining GTM Environments with Custom Loader, the team can validate tracking updates in a controlled environment before rolling them out to all users:

• Test tracking changes in staging.
• See the impact of ad blockers during validation by comparing backend data with GTM/GA4 events.
• Publish your tracking setup once you’re certain it is ad-blocker-proof.

Custom Loader and Google Tag Manager Environments work well together when you need reliable testing across staging, development, and production websites. The only extra requirement is manually adding the GTM environment parameters to the generated Custom Loader snippets.

Once configured, you can test GTM changes in isolated environments while still benefiting from Custom Loader's ability to reduce data loss caused by ad blockers and browser restrictions.