Google Analytics Sub-domain Problems – Find, Recognise, Troubleshoot, Fix, Prevent.

Troublesome cookies and sub-domain tracking are amongst the most common problems affecting users reports.

But how do you know if your GA tracking is actually faulty? We look at a real life problem, diagnose and fix it, provide a list of trouble spots and a list of places to look for tell-tale signs in your reports.

This post refers to a real site and is with thanks to Joe at https://www.furfeatherandfin.com

Here’s the Quick Nav:

• The Problem
• Domain Hash Made Easy
• Code Snippets
• Solution Choices – All the Fixin’s
• The Healthy Choice
• The How can this happen to you Checklist
• Seeing Errors and Causes in Reports

The Problem

Our Fur and Feather friends get adequate traffic volumes from many sources and should have transactions attributed across multiple Traffic Sources. Their problem showed up as eCommerce transactions all being attributed to Direct visits alone, against all odds.

Starting from a Google Search, the cookies, once the landing pages loaded, were correctly showing the traffic source. They continued doing so throughout the order process including when declining my test credit card. To get over the challenge of purchasing hunting products from the UK, I asked Joe over there to save a static order confirmation page from a real purchase to ensure I was dealing with the correct code.

The __utmz cookie value started as: 20538663.1298159917.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=fur feather & fin

Note the values storing the Source, Medium and Keywords.

After loading the order confirmation page my __utmz cookie read: 239384468.1298160047.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Clearly the Google organic traffic Source data had been overwritten. The reason for that is exposed by the domain hash changing from 20538663 to 239384468.

The four things we all need to know about cookies:

1. Location,
2. Location,
3. Location:
   They are written to and read from only their own domain. Within that restriction, we can only specify that it be written to the current sub-domain (e.g. www) or the root domain (e.g. mydomain.com or .mydomain.com). Paths are similar but not relevant to this discussion.
4. GA Domain Hash: This is an identification number, magically calculated by the GA code based only on it’s sub-domain or domain location and stored in the cookie.

Domain Hash Made Easy

Javascript is not given domain information when reading cookies – it can only read the cookies it can see. Since there might be more than one set that it can see (e.g. in www.mydomain.com and in .mydomain.com) it relies on matching the hash number of the domain name it wants, to the domain hash stored in the cookie.

If GA cannot find a set that matches the domain it’s instructed to use, it writes a new set. That’s smart and works well whenever the coding is done consistently.

Code Snippets

All pages had the following code in the head section (which is a good thing):

The order confirmation page did too.

However, it also reported the transaction as follows:

The mixing of Async and “traditional” code should not be a problem. Ultimately the Async code calls the same “traditional” functions.

The 2nd _trackPageview (the first was in the head) is a separate issue and not to be blamed for the cookie problems. The lack of _setDomainName is the one who done it.

By default, GA will write its cookies to mydomain.com and will calculate the domain hash “mydomain.com” – note the missing period. Since each character of the cookie domain is used to calculate the domain hash, “.mydomain.com” would result in a different domain hash. And that’s why we have the 2 domain hashes above.

Solution Choices – All the Fixin’s

Should Joe:

1. Remove _gaq.push([‘_setDomainName’, ‘.furfeatherandfin.com’]); from the head?
2. Change it to ‘furfeatherandfin.com’ (no period)?
3. Remove the superfluous _trackPageview() and replace it with pageTracker._setDomainName(‘.furfeatherandfin.com’);?
4. Completely replace the “traditional” code block with the code below?

The Healthy Choice

The healthiest choice will be what works best for the site. Since the code in the head is consistently implemented across the site, the logical solution is to simply extend the Async coding, replacing the “traditional” block with the Async version to only report the transaction. That removes the double reporting of the order confirmation page and uses the existing _setDomainName setting.

The choice is also based on maintaining the existing cookies. Only those visitors who existed on the confirmation page would leave with the wrong cookies. All others would have the correct domain hash so we don’t want to change the coding to upset their cookies unless we have to.

The How can this happen to you Checklist

The cause is common. This risk exists whenever custom GA coding is required or circumstances or the environment is different from the rest of the site.

Here’s a quick checklist of coding vulnerabilities:

1. Receipt Pages with eCommerce tracking code
2. Other confirmation pages if custom tracking code is used
3. Custom Landing Pages (see below)
4. Subdomains for eCommerce or an internal search engine, blog or wiki
5. A different code base for a site section, such as a forum, blog, wiki, etc
6. Google Web Optimizer pages
7. Any use of double tagging, whether intentional or in error
8. Sections that use different templates than others

Custom Landing Pages are a particularly mean example. They either don’t use the common template or don’t use one at all and are often created by 3rd parties unfamiliar with the GA coding and likely don’t have the responsibility for it. They are the worst of all since they are often part of an expensive advertising campaign but completely lose all traffic source data for the rest of the visit.

Seeing Errors and Causes in Reports

How can these and other errors be noticed in our reports and can we use our reports to point to the causes.

1. In this case the order confirmation pages will show up in the Top Entrance Pages report where it does not belong (except in very small numbers) If a Goal and Funnel are set up for the checkout process, all counts for the Goal Page would show as entrances.
2. For double reporting of pages (as with the order confirmation page above) the comparison of its Page Views to its Unique Views would show a 2-to-1 ratio.
3. Low Bounce Rates across all Mediums
4. Jumps in or abnormally high % New Visits
5. Jumps in or abnormally high % Direct Visits
6. Sudden jumps in Visit counts without a corresponding increase in Visitors or Page Views.
7. The surest sign of a problem is a high count of “self-referrals” – one’s own domain or sub-domain being listed as a referral.

Brian Katz – Analytics – VKI

Quick Nav