Process Control: Google Analytics and Google Tag Manager in Development and Live Environments

Analytics and page tagging are part of a broader technology context within the enterprise and should be managed with the same attention as other deployments. Here at E-Nor, we encourage our clients to consider the bigger picture and guide them to mature in their analytics implementation, integration, and reporting processes. Part of that maturity is careful management of Google Analytics and Google Tag Manager in development and live production environments.

When first including Google Analytics tags (and Custom HTML tags that support GA, such as for data layer population) in Google Tag Manager, you probably don’t want to start off in your live environment. Like any other code change, you risk errors in your Google Analytics tag configuration and the resulting report data and even the off-chance that a Custom HTML tag breaks your site and causes you to lose sales.

Before we continue the discussion, let’s consider two fundamental points:

You can use a single GTM container or separate GTM containers in your development and production environments. While either approach is workable, my esteemed colleagues in the E‑Nor tech team would advise you to use a single container across both environments for easier management.

You can use a single GA property or separate GA properties for your development and production environments. We detail both of these options below.

Same Google Analytics Property ID for Development and Production

For this scenario, there are three main steps:

1. separate views: In your Google Analytics property, create separate views for development and production, with hostname include filters applied accordingly as shown below. (Always maintain an unfiltered backup view for each property.)
2. development-only trigger: While you’re testing your tags, apply a trigger for the development hostname only as shown below instead of the generic All Pages trigger.
3. change to all-pages trigger: After you have tested the tags to ensure that your Web pages in development are still working correctly and that the GA data is reporting correctly from the development environment, you can change the trigger to All Pages.

If you’re using the same Google Analytics property ID in your development and production environments, your should create separate views and apply hostname filters such as shown below.

Enable the built-in Page Hostname variable to make it available in tags and triggers.

Instead of applying the generic All Pages trigger to your GA tags during testing, you can apply a trigger as below that will fire only when the hostname indicates that the page is loading from the development server.

As a related note, it’s considered best-practice to store your GA property ID as a Constant variable in GTM as shown below so you can reuse the same property ID in various tags (pageview, event, social, and Ecommerce) without hard-pasting each time.

Constant variable in GTM for the GA property ID.

We can reuse the GA Property ID variable in all of our Google Analytics tags.

Different Google Analytics Property IDs for Development and Production

In this scenario, you’re recording activity from your development and production environments into separate Google Analytics properties. Since we’re using the same GTM container, our task is to direct to the right GA property based on hostname.

When first testing GA tags in this case, perform the same initial steps as above: apply a trigger that fires the tag only in your development environment. You can also use the Constant variable for your development GA property ID, also as shown above.

Once you have verified that the new tags have not interfered with any functionality on your development pages and are sending data to Google Analytics correctly, you have two basic options to move the tags to production and to begin capturing the data in the production GA property:

• Update your Google Analytics tag with your production GA property ID (preferably using another Constant variable), and apply a trigger that fires under your live hostname instead of your production hostname. (You could use this trigger change to move non-GA tags from development to production as well.)
• As shown below, update your Google Analytics tag with a Lookup Table to dynamically populate the Google Analytics property ID based on hostname, and apply the generic All Pages trigger to the tag.

Using Lookup Table Variable to Dynamically Insert GA Property ID

One of Google Tag Manager’s many strengths is its ability take an input an process it into a different output. The Lookup Table variable exemplifies this functionality: we’ll provide a dynamic input – in this case, the development or production hostname – and output the dev or live GA property ID into our GA tags as shown below.

This Lookup Table takes the hostname as an input and outputs the dev or live GA property ID accordingly.

Finally, create a Google Analytics pageview tag that uses the lookup table variable for the Property ID setting.

This GA Event tag uses the Lookup Table to dynamically insert GA property ID.

That’s it – you now have a single GA pageview tag that will dynamically switch between your development and production Google Analytics properties according to the hostname on which the tag fires. Any tag configurations (such as custom dimensions, content groupings, or event values) will apply to both Google Analytics properties from a single tag.

GTM Flexibility for Process Control

As demonstrated above, GTM’s flexibility and dynamism can help you manage your GA tag deployments in testing and live environments. Whether you’re using a single or separate Google Analytics properties, Google Tag Manager enables the process control that you need.