What is the main use case for 'Live' environments' Google Tag Manager snippet? - google-tag-manager

Google Tag Manager article about environments mentions:
Note: Every container is set up with a "Live" environment by default, which always points to the container version that is currently published. You don't need to define the Live environment.
But what is the intended use case for Live environment's dedicated GTM snippet, that can be obtained via: "Admin" > "Environments" > "Live" > "Actions" > "Get Snippet", is unclear
If you use "Live" environment's GTM snippet on your production site - gtm_auth & env parameters values are shared publically. We've used 'default' GTM snippet, which can be obtained by "Admin" > "Install Google Tag Manager", for your production environment and it works perfect.
So the question is how one benefits from using "Live" GTM snippet?

No benefit really.
When you get the live GTM snippet, you get the environment params populated as you do for any other environment.
When you use the "Install GTM" snippet, it skips the env-specific parameters because when the env parameters are skipped, GTM defaults to loading the live env. Specifying the live env doesn't really bring any benefit since I don't think you can change which environment is live. So env-2 will always be live. I'm trying to confirm the last part just out of curiosity. You'd think they would preserve env-1 for the main live env, but no.

Related

Google Tag Manager not collecting data when deployed to Vercel (Next js)

I am trying to use Google Tag Manager to collect event data (including page view) but it isn't feeding through to Google Analytics once its deployed to Vercel.
I have checked the following things:
GTM has a GA4 Configuration Tag with the measurement ID from GA
I have set up the GTM measurement ID as a public variable in env.local (and reflected this in Vercel)
T have added the script to _app.js
I have added the iframe to _document.js
Set up the tags required in GTM and published it
Using dev tools I have checked that the gtm script (with the correct reference) is fired in the Network tab
Also checked dataLayer in the Console tab is collecting the data expected
However, in spite of all of this I can't see any data in Google Analytics. Played around a bit yesterday expecting to see some today but nothing.
It seems to work on localhost and checking both in real time Vercel doesn't register a view but localhost does.
Previewing the Vercel URL from GTM does say its connected and I can view that in real time in GA when going this way, but if I go to the address directly it's not logging it. Checking 'Tag Coverage' on GTM also says the pages aren't connected.
Am I missing something? It seems to work in theory, just not in practice when visiting the Vercel address directly (as opposed to via GTM preview)?
Thank you in advance
I think I found an answer myself and it's rather basic. It seems a pop up blocker I had installed ('Pop up blocker for Chrome™ - Poper Blocker') was preventing it from firing. Disabling the extension seems to have done the job.

Google Tag Manager on localhost

I was asked to implement the Google Tag Manager scripts into the React application. I've added the scripts to head and body of my html file. I've tested the site in the Preview mode of GTM and everything seems to working fine. Clicks and route changes are tracked correctly.
I have one doubt... What about the localhost development ? Is it going to generate unnecessary logs on the analytics (which I have no access to)? Or maybe it's just enough to paste the snippets and that's it?
I can't find an answer so that's why I decided to ask here.
If someone has some experience on that topic - please let me know :)
I would advise you to map separate Google Analytics property IDs by either a datalayer variable, URL or custom JavaScript to return a separate property ID based on whether users are accessing your website from either your localhost development environment, your UAT environment (if any) and then your production environment (or others as applicable).
Essentially you're looking at having something that says "if the URL contains "localhost", return my development property ID", then use this variable name in your Google Analytics tag(s) instead of a static value.
Yes, unfortunately all your existing testing is all in your profile because if you had the production property ID configured and fired off a bunch of events and pageviews, it absolutely collected and sent there as part of the debugging experience. Generally though, that's a low concern on a production app because you make up such a small portion of overall traffic; you're just a couple of blips in the larger dataset.

Google tag manager - Show debug bar by default in environment?

I wonder if it is possible to automatically show the GTM debug bar when loading GTM with a specific environment and/or other GTM variable?
I have set up a new environment in GTM to be used for dev/testing purposes. When setting up this environment there is a checkbox with the option to "Turn on debugging when previewing". I first thought that this did just this, but no debug bar appears by default even though I checked it and is loading GTM with the code that the environment applies. What does this do then?
I actually can get what I want, sort of, by adding the parameter gtm_debug=x to the implementation code, however this feels hacky maybe, and also causes the console to log a weird 400 error to GTM:s api domain, which doesn't feel so good...
Does anyone know how I can achieve this?
I've came across a similar (or maybe even the same) problem. I've wanted to enable the QA team to access/show the GTM debug toolbar (i.e. enable/disable it) on their behalf and without going into tag manager.
This is the solution I came up with:
https://www.googletagmanager.com/set_cookie?uiv2
&id=GTM-XXXXXXX
&gtm_debug=x
&gtm_auth=AUTH
&gtm_preview=env-0
&url=https%3A%2F%2Fwww.example.com%2F
(enable debug)
where "GTM-XXXXXXX" has to be replaced with your container ID and "url" is an optional parameter.
This URL sets the necessary cookies to switch GTM into debug mode and also provides a link to leave debug mode again ("Exit preview and debug mode").
https://www.googletagmanager.com/set_cookie?uiv2
&id=GTM-XXXXXXX
&gtm_auth=
&gtm_preview=
&gtm_debug=
(leave preview and debug mode, i.e. remove cookie)
The values for "gtm_auth" and "gtm_preview" are different per container/environment and you can find them via "Get Snippet" from the "Actions" menu of each environment on the "Environments" view ("Admin" -> "Environments"). You can also get them for the two default environments, i.e. "Live".
When setting up this environment there is a checkbox with the option
to "Turn on debugging when previewing". I first thought that this did
just this, but no debug bar appears by default even though I checked
it and is loading GTM with the code that the environment applies.
What does this do then?
"Turn on debugging when previewing" is from the "Share preview" screen. On the "Environment Configuration" screen, it says "Enable Debugging by Default" and also Google's documentation suggests what you (and me) expect:
Optional: Check Enable Debugging by Default if you need the environment to always use preview mode.
But it doesn't work for me neither. :(
The preview & debug mode relies on 3rd party cookies (i.e. cookies on www.googletagmanager.com and even if the checkbox is checked they are not set. The missing cookies are also the reason for the 400 error you were mentioning.

Is it possible to have different tags included in different environments in GTM?

I have two different environments for my account in Google Tag Maneger: Staging & Live. I want to have some tags for only staging environment but when I publish the changes to live environment, everything goes live. Is there a way to divide the tags as some of them is for staging and some for live? Thanks!
Technically yes, you can publish a version to the Staging Enviroment, then remove your changes and publish to the live environment. Does not really make sense, though.
To comply with the spirit of your question rather than the words, you can create a trigger based on the built-in "environment name" variable that either fires tags only when you are on staging, or works as an exception trigger and blocks certain tags when you are not in the staging environment. So all tags will be "live", but some will never be fired unless you're on the staging environment.

Google Analytics Tag for Dev vs. Prod

I run a standard google analytics tracking code (ga.js asynch version) on a website.
I am wondering if there is a line of js I can add to the tracking code so that I can segregate dev/prod data? e.g. when I pull in the codebase to do dev work, I can set the tag to DEV. When releasing back to production, DEV tag gets replaced with PROD tag.
Is this even possible and if so, how do i implement it?
One method I thought of is just to create a new "property" (which would generate a new ua number, which I could add during dev. that would allow me to track it all separately.)
Wondering if there are any other methods I should consider.
Alternative to mike's answer is to setup a filter in your profile based on the url or domain or based off any number of other things.
I'm not worried about collecting data from my development server, but I do want to make sure I'm not polluting my production data -- I've been using some variation of the following:
if (!/devServer|localhost/.test(window.location.hostname))
{
_gaq.push(['_setAccount', 'UA-11111111-1']);
}
On the devserver domain (or on localhost), _setAccount doesn't get executed, so the tracker defaults to the default tracker, UA-99999999-1. This allows you to still see tracking data being sent to the analytics servers (via ga_debug.js, chrome dev tools, firebug, fiddler, etc), but doesn't register against your production profiles.
Downsides -- it is an extra bit of code that get's run on the client.
If you do want analytics from your development servers, you could try something like:
gaq.push(
[ '_setAccount',
/devServer|localhost/.test(window.location.hostname) ? 'UA-11111111-1',
'UA-22222222-1']
);

Resources