I was just about to set up a 2nd GA property that I would implement into my Staging environment. I figured i'd do the same with GTM and just export/import containers from Stage to Production whenever necessary. I also figured I'd dynamically populate the Tracking-ID dynamically based on hostname. No big deal.
But then I stumbled across Environments for GTM. The first bit I read said that using this feature would solve the problem of moving code across environments. To me this implied that the snippet code would remain the same in all environments and that there would be no need to change (dynamically, via build script, manually or otherwise) any values or anything... that GTA was smart enough to deploy the right container(s) to the right place(s) at the right time(s). That sounds great, I'll do it.
Now that I'm getting into that process I'm learning (if I'm understanding correctly) that each environment does in face have to have a separate snippet. So now I"m back to where I started, with having to dynamically add values to the snippets based on domain name (which determines stage or test). With out that, every time the file containing the snippet is pushed between environments, it will contain the wrong values. I guess using Environments still takes out the export/import process for containers (which, don't get me wrong, is nice) but having to change those values is a pain..
Is this the long and short of it - do I have this right? Is there any way around having to change code in the web page (or template) by doing it somehow through GTM instead? I'm guessing not, since the snippet is the base of GTM's functionality, but i figure I'd ask.
Further complicating things is that I was planning to use a Wordpress plugin, Google Tag Manager for Wordpress, to add the GTM code. in this case, all I can even change is is the Tracking-ID, which actually stays the same... it's other values that change that I have no control over with the plugin. Is anyone aware of a way to inject new values into the snippet that the plugin writes to the page?
The snippet for an environment has the same GTM id, but has a token for the environment name attached to the GTM url. If you use any kind of build system it should be possible to set or change the token according to the server you deploy to. Personally I am not convinced that environments are really useful.
If all you need is different values for tracking ids, you can implement lookup table variables that take hostname variable as input and return the respective tracking id for live or staging. Then use that instead of hardcoding the tracking id into your tag.
Related
I am trying to implement GA to track traffic to a Medium page. First of all I don´t know and I couldn´t found if this is trackable at all since I don´t really "own" this url.
I have tried the two ways: by the global website tag (gtag.js) and by Google Tag Manager.
On global website tag I am not really sure I could implement it since I tried to modify the source code of the page but it didn´t save.
On GTM y created a tag (GA4 configuration) with "all pages" activators and it shouldn´t be much more trouble.
The thing here is than when I open the Tag Assitant Legacy it just finds one tag GTA tags and it does with a UA identity, even though I always tried to configure the two options above with the new identities G-XXXXXXXXXX.
All in all, I have three questions here:
Is it possible to modify the source code of a webpage? If it is, is it specifically with Medium? If yes, how?
Why does GTA shows just one tag if I tried to configure two?
Why the configured task shows a legacy identity (UA-xxxxxx) if I always used the new one (G-xxxxx).
Just to finish and give the complete picture here, when I try the Tag Assistant, this is what appears. Here I can only recognize the first code (which is the same than the GTA one). Moreover, it sometimes sends the "can´t connect to the website message" once in a while.
So much problems, so many questions; if anyone can help I would really appreciate that.
Thanks so much!
Previously working code that downloads a csv file from our site, now fails. Chrome, Safari and Edge don't display anything helpful except "Blob Blocked", but Firefox shows a stack trace;
Uncaught TypeError: Location.href setter: Access to 'blob:http://oursite.test/7e283bab-e48c-a942-928c-fae0907fdc82' from script denied.
Then a stack dump from googletagmanager
This appears to be a fault in the tagmanager code introduced in the last couple of weeks.
The fault appears in all browsers and is resolved immediately by commenting out the tag manager. The problem reported by a customer on the production system, and then found on both staging and locally. The customer advised they had used the export function successfully 2 weeks ago.
The question really is, do Google maintain a public facing issues log for things like the tag manager?
It's not about GTM as a library really, it's about poor user implementation. It's not up to Google to check for user-introduced conflicts with the rest of the site's functionality.
What you could do is go to GTM, and see what has been released in the past two weeks. Inspect things and look for anything that could interfere with the site's functionality. At the same time - do the opposite, see all the front-end changes introduced during this time frame by the web-dev team.
Things to watch for is mostly unclosured JS deployed in custom HTML tags. junior GTM implementation specialists like to use the global space, taking the global variables, often after the page is loaded, thus overwriting front-end's variables.
Sometimes, people would deploy minified unclosured code to the DOM, thus chaotically taking short var names. To the same end.
This is likely the easiest and most common way for GTM to break front-end. There definitely still are many ways to do so besides this though.
If this doesn't help, there's another easy way to debug it: make a new workspace from Default (or whatever is live), go into the preview mode and confirm that the issue still happens. Now start disabling newest created fired tags one by one and pinpoint which one causes the issue.
Let us know what it was.
Solution was to replace the previous tag manager code with the latest recommended snippet
I'm currently working on blocking the scripts injected by gtm and I noticed there's a way to add allowlist or blocklist inside datalayer to reach that: https://developers.google.com/tag-manager/web/restrict
But after trying to add the gtm.allowlist/blocklist, it still injects the 3rd party scripts
Anyone who had any experience on that? Many thx
The best way to allow the delivery of a tag is to associate the correct trigger based on the classification of the cookies you assign.
With OneTrust (you are using) the cookie (or the OnetrustActiveGroups variable) that contains the information of the accepted cookie classes will contextually contain the values C0001, C0002, c0003, C0004, ... If for example the category C0004 is for cookies may be set through our site by our
advertising partners, to GTM Facebook tags, Ads tags, etc ... you will assign as a trigger the check that in that variable there is that value. If it is present the tag is fired otherwise not.
In this way everything is much more controlled and you leave nothing to chance or to the interpretation of the tool.
I'm setting up Google Analytics and KISSmetrics for around ten different services (different websites/apps with different domains), all of which share the same login/signup service. I want to be able to track our users coming from one service, going through the login/signup service, and then going back to the service they came from.
My current setup is that I have only two properties, one for staging and one for production. I fire the appropriate property using Google Tag Manager. I then filter the properties into different views based on which services the user came from.
I have never worked with Google Analytics or KISSmetrics before, but I have read about the pros/cons about using a single property and filtering, vs using separate properties. I haven't really found anyone who was in my exact situation though. I would love some advice from someone who's worked extensively with either or both services.
Using the same property for many domains brings problems big and small. There are a lot of settings at the property level. If you use one property for ten domains you will have 2 custom dimensions and metrics per domain instead of 20; you will have to be very careful if you use the data upload lest data shows up in the wrong view; you will not be able to link your webmaster tools accounts since this happens at property level. There are probably other caveats.
I would suggest a two pronged approach: first use a property per domain/service to collect data per domain to have use of all property settings. Then use another property to collect data across all services (needs to be setup for cross domain tracking); since they use the same login id you should be able to generate a user id from the login data and enable session stitching, so you can even track them across devices (you need to create a dedicated user id view for that to work).
I have nothing useful to say about Kissmetrics.
I'm using the Google Analytics Flex API to record data from a Flex application.
As I understand it, Google Analytics has a 3-tier hierarchy: An Account can contain one or more Properties, each of which can contain one or more Profiles. A UA code is associated with a Property, and Filters can be used to record specific traffic to a specific Profile.
The application lives on 5 different server environments (development, staging, live, etc) and we need to separate the data from the different environments.
Note that the server environments do not live within the same domain name. For example, staging is at staging.x.com, but the live version is at www.y.com. But I want them all to share the same UA code, so we are tracking them as 5 different Profiles.
So I have one Property with multiple Profiles. I set up a Filter for each Profile saying "Include only traffic form the domains that are equal to" and the particular hostname for that server environment.
The "Default URL" for the Property is set to the hostname of the default Profile, which is the live environment.
We set up that configuration yesterday, and today there is no data in any of our Profiles. We had data the day before (before doing the reconfiguration). I am confident that the tracking code in the client app is sending the hits to GA, since I can see them in Chrome debug mode, and the client app wasn't changed between the day before yesterday and yesterday. The only thing that changed was the configuration of the Property and the Profiles.
So obviously I'm missing something about Property and Profile configuration. Some specific questions:
Am I understanding Filters correctly? Is it somehow applying the Filter to the entire Property? It seemed like the Filters were at the Profile level.
Does the "Default URL" for the Property have an effect on which hits are recorded? What exactly is it used for?
Is there some restriction on how the Profiles within a Property can be affiliated? For example, do they have to belong to the same domain name? I thought not, but maybe I'm wrong?
Any other suggestions?
Obviously, I can experiment with the configuration and see what happens. But I have to wait until the next day to see the effects of each change. Thanks for helping.
Am I understanding Filters correctly? Is it somehow applying the
Filter to the entire Property? It seemed like the Filters were at the
Profile level.
Yes Filters are always applied at the profile level.
Does the "Default URL" for the Property have an effect on which hits
are recorded? What exactly is it used for?
The "Default URL" has no effect on data collection or filtering at all. It's only used to create links from the page reports back to your site. So when you see the top page being /index.html and you click the little link beside it it will take you to "Default URL"/index.html . So you might break that specific feature if the url doesn't exist on you domain. But for the sake of reporting it's completely fine to use a different url.
Is there some restriction on how the Profiles within a Property can be
affiliated? For example, do they have to belong to the same domain
name? I thought not, but maybe I'm wrong?
No, the Profiles inside a Web Property don't need to share the same domain name. It's perfectly fine to have multiple profiles filtered by hostname and it's completely fine and normal to have a global profile with data from multiple hostnames. In that last case the data may be a little off unless you implement Cross Domain Tracking.
Any other suggestions?
It seems that you have a very good understanding of how things work in GA. One thing that you might have missed and #jk commented about is that you should always have an unfiltered profile on you Web Property to avoid losing data due to bad filters.
Another thing to notice is that in the past I had problems with the predefined domain filters. It seems they were being aplied to the wrong field inside Google Analytics. I think they were being applied to the "Visitor ISP Organization". For that reason I never use predefined filters. So if you are using predefined filters you might consider changing them to Custom Include fields, select the "Hostname" metric and enter the domain you want to filter as a RegExp. I believe this bug should be fixed by now, but you never know, I just lost confidence in the predefined filters on that day.
If you acidentaly used 2 include filters in a profile that filter on the hostname but with different values chances are they are canceling each other. So you might want to go into each profile and check if they only contain one include filter each.
eg:
Include only trafic from x.com
Include only trafic from y.com
This will result in a profile with no data.
Another thing to notice is that filters don't apply to retroactive data. So if you apply a filter today to a profile it will only filter data from now on. Data that has already been processed will be elft untouched. There's no way to change data that has been added to a profile, nor to add retroactive data to a new profile.
Other than that you are probably good.