Separate Google Analytics data based on dev environment
M

2

6

So I've found a few similar questions, but often either outdated, not exactly what I'm searching for or they don't use Google Tag Manager but write their tags in the <head>.

----------- Current situation -----------

We use Google Tag Manager to inject tags such as Google Analytics on our website. We use multiple tags depending on what needs to happen; such as:

  • tracking pages
  • tracking specific clicks
  • tracking log in or registration events

All the data goes perfectly to Google Analytics

----------- The problem -----------

However, we also receive data from other environments such as localhost:3000 or https://dev.ourdomain.com, which can result in inaccurate data.

----------- What we want -----------

Is a way to separate that data. By either:

  1. Separating Google Analytics in data from production (domain A) and data from development (other domains)
  2. Separate the data before it reaches Google Analytics (like my suggestion below)
  3. Or maybe other suggestions

Between point 1 and 2, I'm more of a fan of the first way, as this would separate existing data into production and development data.

----------- Suggested solution -----------

I've been thinking about using a new property and then, using Google Tag Manager, I would return Google Analytics Settings depending on the current domain. Production would return UA-code-1 and development UA-code-2. The only issue however, is that every Google Analytics tag in GTM must be duplicated. With one containing the Google Analytics Settings for production, the other for development.

I was hoping there was a better way to tackle this, any suggestions?

Muzzle answered 11/1, 2021 at 12:22 Comment(0)
B
4

You can still use single Google Analytics settings variable in your GTM and have a single instance of each tag but you can use some Lookup Table / custom JS variable inside your GA settings variable in place of tracking ID.

enter image description here

Update:

Note that the GTM Environment variable is incompatible with the lookup method and debugging/previewing. When previewing, the value is something like Preview window 1121212. In order to workaround this, an easy lookup table based on production {{Page Hostname}} works well with a default value fallback to your staging tag value.

enter image description here

Bon answered 11/1, 2021 at 12:50 Comment(2)
Not a bad idea. Basically using a variable "getTrackingID" and then return a string based on the domain. That would indeed solve it. I'm going to take a look at implementing this.Ghirlandaio
AFAIK this maps to event-scoped dimensions, but what you really want are user-scoped dimensions, since they affect the entire session (not just a single event). We use GA4 directly without GTM and found that calling gtag('set', 'user_properties', ...); yields much better reporting data than attempting to include the property in each event, since GA then treats it as a fact about the user/session and thus allows you to slice reports by that dimension.Gazo
H
3

I assume you're using GA4, and if not, that would be a good idea since Google is really pushing the move from UA to GA4. You can create multiple properties for each domain, which would each have their own tracking ID. Then, in your index.html file where the installation code is, use some JS code to switch the tracking ID based on environment.

You'll also need separate Google Tag Manager containers for each property. If they all share the same container, you'll see the inaccurate data start to flood your properties.

This takes a bit of work, but will save you the hassle of inaccurate data being tracked in your respective properties.

Hollinger answered 15/3, 2022 at 21:16 Comment(2)
Hey man! Welcome to Stack Overflow. We're indeed also working with GA4, but I didn't know that it would result in inaccurate data if they all share the same container. I'll definitely have to analyze that part further so we have correct data. Thanks!Ghirlandaio
As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.Episcopalism

© 2022 - 2024 — McMap. All rights reserved.