I help manage a site that had classic google analytics installed and it has recently migrated to universal analytics via Google Tag Manager.
Now when travelling to a subdomain google is appending the cookie information to the anchor, as a querystring value.
?_ga=1.94005085.150702697.1452253355
Apparently this has didn't happen with classic analytics, even though the set up is like this:
pageTracker._trackPageview(getPageUri(true));
pageTracker._setAllowLinker(true);
Does anyone know if the url will be changed when travelling to a sub domain on classic analytics with the above options?
This is down to how your cookies are setup. For hypothetical purposes assume that your website and subdomain are:
www.website.com
subdomain.website.com
These domains can share a cookie and therefore share the Google Analytics information however unless you specifically set the custom variable of cookieDomain to auto (with GTM tag setup: #3 Configure Tag > More Settings > Fields to set > + Add Field > cookieDomain | auto) you essentially have two distinct cookies for each domain.
I also presume you have then also setup "Cross-Domain Tracking" and included "website.com" within "Auto Link Domains" setting in GTM.
TL;DR: Updating your cookieDomain settings to utilise "auto" will force GTM to first attempt to set a cookie for .com (which will fail) and then attempt to set one for "website.com" (will work work) and your cross domain tracking won't be required.
Bonus info: However to add some context for your question the code pageTracker._setAllowLinker(true); allows the linker to be applied to URL's in Classic Analytics, you would still need to decorate your links with code such as below, if you didn't have this before your links wouldn't have included the linker code (and wouldn't have shared cookied if on different cookie domains/paths).
<a href="http://www.my-example-blogsite.com/intro"
onclick="_gaq.push(['_link', 'http://www.my-example-blogsite.com/intro.html']); return false;">
See my blog</a>
Related
I'm trying to set up GTM to avoid including any tracking JavaScript (GA, FB Pixel, Linkedin, etc) code for users logged in to the website. Only administrators can be logged in and the site is using WordPress so my theory is that simply checking that the WordPress logged-in cookie is set will allow me to add conditions to my triggers checking for the cookie.
The problem is that a 32-character hash is attached to the end of the cookie name. Something like this:
wordpress_logged_in_c61670c29894a13760815de6f19b9544
How do I check for this in GTM?
I would like to avoid adding custom code to the website if possible. I know that adding a quick PHP function to set and remove a cookie would be quick and easy. I'd just like to see how it could be done in GTM.
In GTM I have a 1st Party Cookie called DL - WP Login Cookie. I'm just not sure what to place in the Cookie Name field since the cookie name is different for each user.
Can this be done?
When i check console in Chrome DevTools i see the 404 error above. Pasted example below:
POST https://www.example.com/g/collect?v=2&tid=G-XXXXXX>m=2oe8b0&_p=424137054&sr=1366x768&ul=en-us&cid=1940949659.1614938183&_s=1&dl=https%3A%2F%2Fwww.example.com%2Fmovies%2F&dr=https%3A%2F%2Fwww.example.com%2Fcasts%2F&dt=Movies%20Free&sid=1628778501&sct=16&seg=1&en=page_view 404
I don't know where to start debugging, is this a google tag manager or google analytics error? Every time a page on website is viewed, this error is displayed in console. The route "/g/collect" doesn't exist on my application. How do i solve? Do i have to create the route on my application or change something in tag manager?
The path is from a tracking call to GA4 (recognizable by the /g/collect route and the v=2 parameter, which refers to measurement protocol version 2).
If that is actually your own domain in that request, then it is possible that somebody has changed the "transport_url" property in the GA4 configuration in the "Fields to set" section of the GA4 configuration tag.
Or somebody set the "Send to Server Container" option and added your domain, which is essentially a nicer UI for the same feature.
If you have not configured the route on your server, this will result in a 404. You would configure this only if you run a proxy for you GA4 calls or want to use server-side Google Tag Manager. If you do not want to do that, just remove the setting.
For client-side GA, the endpoint should be: https://analytics.google.com/g/collect
For example:
https://analytics.google.com/g/collectv=2&tid=G-XXXXXX>m=2oe8b0&_p=424137054&sr=1366x768&ul=en-us&cid=1940949659.1614938183&_s=1&dl=https%3A%2F%2Fwww.example.com%2Fmovies%2F&dr=https%3A%2F%2Fwww.example.com%2Fcasts%2F&dt=Movies%20Free&sid=1628778501&sct=16&seg=1&en=page_view
Are you sending to https://www.example.com/g/collect or was this used for demonstration purposes?
The only time that endpoint would be different for any GA property is if you're sending data to a Server-Side GTM container.
I'm trying to set up tracking with GTM between the main domain and its subdomain. I've read a lot on this topic already, including this Google guide (it's about different domains but not sub-domains) and guide from Lunametrics. But still I can't find the answer.
So what I have now:
site.com and blog.site.com
Two separate containers for each of them
Two different properties in Universal Analytics.
What I need is tracking the domain with it's subdomain. I assume I'll need to create a separate view with filters in GA. Please let me know how to configure that tracking right. I wouldn't like to use one single container for the domain and its subdomain.
What you need is a single property. Implement the same code on domain and subdomain.
Set the cookie domain to "auto" (or do not set it all). This means the Google code sets the cookie for the highest accessible "level" from the domain (i.e. Google cannot set a cookie for the .com TLD, so it will use the next level, in your example site.com). It also means the cookie is available on the subdomains for your url.
That's basically it - your property will report users from domain and subdomain and will maintain the session when they switch between domain and subdomain.
However if you have pages of the same name on both domain and subdomain - say site.com/index.html and blog.site.com/index.html - they will be lumped together in the reports. To separate them you can set the hostname as second dimension, or apply a filter to your data view that adds the hostname to the url path (here is randomly googled tutorial on how to do this).
Been searching for an answer for this for a while but nothing that I can find that is useful.
Basically in the organisation I work in we use Shibboleth for user authentication.
We probably have 200+ sites & Shibboleth works effectively for these.
However, one site in particular is protected using Shibboleth (if the user is not a valid user they have to sign up for an account in this process also) which is causing an issue with our Analytics (Google Analytics). The referrer to the site is ALWAYS the shibboleth authenticator.
What we need is a facility to track conversions on this site based on source/campaign the user arrived from. The proposed solution right now is to use a Tag Manager product to fire off specific tags based on a combination the referrer or campaign. This one single site is used for a multitude of things (all prospective leads to EPR) but we need different information based on how the user landed on that page.
We are tracking all the interaction points that lead up to this (i.e. tracking potential leads) but a lot drop out during the signup process and right now we do not have actual conversion data, meaning the Marketing etc is being spent based on highest traffic source rather than which source or campaign is most effective.
The problem is when a user signs in, signs up using Shibboleth, Shibboleth sets a new cookie for that session. In Google Analytics all the referrer to this site are from the authenticator.
Is there some configuration issue with GA that I am overlooking for this scenario or is there something that can be done with Shibboleth so that the initial referrer (rather than the authenticator) being passed as the referrer which in turn would facilitate the rule creation of the Tag Manager to fire off the required tags
If you use Universal Analytics, you might be able to overcome using the new Referral Exclusion:
You can exclude specific domains from being recognized as referral
traffic sources in your Analytics reports. A common use for this
feature is to exclude traffic from a third-party shopping cart to
prevent customers from being counted in new session and as a referral
when they return to your order confirmation page after checking out on
the third-party site.
Google Analytics recognizes the URL you use to set up a new property
in your account and automatically excludes this domain from your
referral traffic, so you won’t see self-referrals in your Analytics
reports.
https://support.google.com/analytics/answer/2795830?hl=en
Another option might be to pass a parameter across the login page when you request an authentication. If you set your fields in the request correctly, you could have Shibboleth send your user back to any page or with any query string, such as adding ?source=original_page_name. After authentication, these parameters should be available to manipulate or pass on to GA. This won't actually spoof your referrers, but it will get you the data you need.
I have a site http://test.com. Potential customers are sent to that site with AdWords with a UTM source, so for example, http://test.com?utm_source=adwords. Now if the customers decide to register, they are sent to a page at http://register.test.com. I've configured Google Analytics to work cross domain using _gaq.push(['_setDomainName', '.mysite.com']);, but the problem I'm having is that my source gets lost and replaced with a referral to the original domain when I go to the subdomain's page. I tried adding a _gaq.push(['_addIgnoredRef', 'ekomobi.com']);, but that only causes my source to be set to (direct).
I will be trying to save the __utmz cookie's value and restore it on the other domain, but are there any other proper solutions to the problem of the UTM source getting overriden by the referrer on a domain change?
If you have cross-domain tracking correctly implemented, you should see the original utm parameter when you get to the register page. For cross domain tracking to work, BOTH top-level domain and subdomain must have _gaq.push(['_setDomainName', '.mysite.com']);,.