How to Setup Analytics & GTM for Dev/Prod

Let’s say you’re launching a significant update to a website. A lot is changing: the theme, lots of URLs, maybe the CMS or backend, and so forth. And the team creating the website is working from various IP addresses on the development site. What’s the best way to handle the transition with Analytics?

Lately (after having a website launch without Analytics earlier this year) I’ve been handling this in a very particular way, and I’ve grown to really like it. Basically, I’m using hostnames (dev.domain.com, www.domain.com, etc.) in Google Tag Manager to automatically split traffic to different Analytics properties. I’m doing this by using a “lookup table” for my Analytics IDs (instead of using a “constant” variable).

Now that I’m using this, websites I’m working on will never launch without Analytics. It also has several other benefits and tangents. This post explains the basics. I hope to cover related topics in the future (such as how this setup interacts with Analytics hostname SPAM filters). Enjoy!

Using a Constant Variable to Populate the Analytics ID

If you use Google Tag Manager a lot, you probably have lots of Analytics tags sending data to one Analytics property. Pageview tags, event tags, virtual pageview tags for funnels, etc. Each of these is a unique Analytics tag, and each requires you to enter the Analytics ID (i.e., “UA-XXXXXXXX-1”). The Analytics ID is too long for most people to remember, and it wastes time to look it up or copy it whenever you need to create an event tag, so a lot of people use a constant variable in GTM to save time. This is what a constant variable (in this case called, “gaID”) looks like:

gtm-ga-id-variable-2

Then, for every Analytics tag that’s created (pageviews, events, etc.), you can use {{gaID}} instead of inputting the Analytics ID:

gtm-ga-id-variable-1

This saves a lot of time and seems to be a fairly standard practice among people who use GTM frequently.

The problem with this approach is that all pages with the GTM container will send data to the same Analytics property. When developers work on a development or staging site, those pageviews will be logged in the same Analytics property as visits to the production site. The traditional way of removing those visits from Analytics is by using filters, but those filters don’t easily account for a mobile workforce or dynamic development hostnames. You could exclude development hostnames in your GTM triggers, but you would need to add conditions to each trigger (which seems very inefficient).

The problems I’m mentioning aren’t specific to using a constant variable in GTM; these problems existed in Analytics well before GTM. However, GTM gives us the ability to solve these problems simply and elegantly.

Using a Lookup Table to Populate the Analytics ID

According to Wikipedia, a lookup table is “an array that replaces runtime computation with a simpler array indexing operation.” This is a fancy way of saying that it sets variable ‘B’ (Analytics ID) based upon the value of variable ‘A’ (the hostname or domain name where the page was viewed). For example, let’s say your website is being developed on dev.domain.com, and during that time the existing website is available at www.domain.com. Using a lookup table for the Analytics ID allows you to send regular site traffic data to the main Analytics property and dev site traffic data to a separate Analytics property.

Whenever a page is viewed on www.domain.com, all Analytics tags (pageview, events, etc.) can use the main Analytics property (UA-X…X-1). Similarly, whenever pages are viewed on dev.domain.com, all Analytics tags can use a secondary Analytics property (UA-X…X-2).

To create a lookup table variable in GTM that corresponds {{Page Hostname}} with different Analytics properties, follow these steps:

1. Enable GTM’s built-in “Page Hostname” variable.

gtm-lookup-table-example1

2. Create a user-defined variable named “gaID” of the type: “Lookup Table”

gtm-lookup-table-example2

3. Use {{Page Hostname}} as the “input variable”

gtm-lookup-table-example3

4. Create a row for each hostname

gtm-lookup-table-example4

You may need to create a new Analytics property if you don’t already have one setup specifically for dev/testing.

I also recommend setting a default value. Many people don’t realize it, but content scrapers, archive.org, translation services and a whole plethora of extraneous hostnames end up in Analytics (to view this data in Analytics: view behavior -> content -> pages and use a secondary dimension of “hostname”). You can track such pageviews independently, if desired, by setting the default value to a new Analytics property ID. Otherwise, feel free to set the default value to whatever is your preference — do you want archive.org and translation services to show up in your main view? If so, use your primary Analytics property ID as the default value.

Other Benefits of Using a Lookup Table

The primary benefit of using a lookup table for the Analytics ID:

  • It allows you to easily separate dev/staging sites and production sites in a way that’s more reliable than filters in Analytics.
  • You can test event tracking, virtual pageviews, and other Analytics tags on a dev site and have that data go to a secondary Analytics property.
  • Nothing needs to be edited when a website is pushed live for Analytics to work correctly.

There are also several secondary benefits:

  • Easily monitor when people are working on the development website.
  • Quickly see if organic, referral or other external traffic is visiting the development website.
  • You can setup alerts for traffic from extraneous hostnames, including content scrapers, archive.org, translation services, etc. For example, if you use a default value for the lookup table and send that data to an additional Analytics property, you can setup an alert in Analytics to let you know if traffic to that property increases. This will let you know if there’s a spike in traffic to new hostnames.