15 Ways Your Google Analytics Might Be Broken, Part 1: Checking the Code, Requests, and Cookies

Google Analytics feels user-friendly.  It seems easy to set up -- just drop the GA tracking code on your site, and see data!  With this seeming user-friendliness comes a lot of opportunities to break your GA data without realizing it.  On almost every new analytics engagement, we find organizations with existing data that they never knew was incorrect.  Just because data’s showing up, however, doesn’t mean it’s right.

This post will show you ways you can check your tracking code, requests, and cookies to avoid some of the most common pitfalls.  Part 2 shows you how to check for other signals of broken data by using the GA interface.  It assumes that, like most organizations, you’re still using the Classic asynchronous tracking method rather than the new Universal Analytics.

Your GA data might be broken if ...

1)  Your analytics improperly tracks across sub-domains.  

If you have sub-domains, does the tracking code on both subdomains contain the following method ahead of the _trackPageview call (either without or with a leading “dot”)?

_gaq.push(['_setDomainName', 'yourdomain.com']);

or

_gaq.push(['_setDomainName', '.yourdomain.com']);

Is the parameter exactly the same in the code for each subdomain?  If the answer to either of these questions is “no,” your GA is likely breaking when people move between them.  As a result, GA will treat each as a separate visit, which also affects other metrics.  Average visit duration goes down because the time is fragmented between two visits.  The bounce rate goes up because GA thinks the users have left the site when, in reality, they haven’t.  Other reports, such as traffic sources, frequency, and recency report incorrect data.

2)  Your analytics incorrectly tracks across top-level domains.  

If you expect multiple domains to be tracked together, you’ll want to double-check two tracking setups on your site.  First, when you click on a link from one domain (mydomain.com) to the other (yourdomain.com), are parameters beginning with ?__utma=something appended to yourdomain.com?  If not, GA is not properly sharing the visits between domains, and the visits are breaking.

Even if these values are correctly being appended, check the GA source code on the destination page.  Does the tracking code have the following method ahead of the _trackPageview call?

_gaq.push(['_setAllowLinker', true]);

If not, the destination domain won’t use the cookies appended from the initiating domain, and the visit will still break.  

3)  The Google Analytics tracking code appears twice on the same page.

Somewhere along the way, a developer may have added code that tracks to the same web property ID (UA-XXXXXX-Y) twice.  We see this surprisingly often with new clients.  As a result, GA will double-count pageviews.  

You can easily check in Chrome: open Developer Tools (View >> Developer >> Developer Tools).  Navigate to the “Network” tab, load your site, then search for the __utm.gif request in the list of resources.  Does more than one __utm.gif request appear?  If so, click on each request.  You’ll want to look at two parts of this request.  First, are both requests tracking to the same web property ID number?  Check the utmac parameter:

If both web property ID numbers are the same, it doesn’t automatically mean that you’re double-counting.  Next, check whether the utmt parameter is defined as "event"
 or "var", as well.  If one is, it’s firing an event or variable rather than a second pageview, and you’re in the clear.  If, however, both of your utmac parameters are identical and no utmt parameter exists, you may be double-counting this page.  

4)  Events trigger on-load of a page without a non-interaction parameter.  

If you do see a utme parameter in one of your gif requests, then you’re firing an event on-load of the page.  Viget does this to measure users’ browser dimensions by default.  Check this gif request for the parameter utmni=1.  If this parameter doesn’t exist, it means that you are firing a standard event instead of a non-interaction event.  GA will see this standard event as a second “hit” and will, therefore, drop your bounce rate and exit rate to 0%.

5)  A third-party “widget” plugin sends you bad data.  

Many third-party tools have GA “integrations” that don’t take into account the nuances of GA cookies.  They simply ask for your GA web property ID number, then send data to that account.  Because the integration doesn’t account for most cookie situations, data often isn’t tied with the appropriate visit, inflating visit counts (and changing the other metrics described above, too).  A few recent offenders we’ve dealt with include Convio (a long-time GA-breaker) and Vzaar.

The solution depends on the individual vendor.  It’s possible to get Convio to track properly -- it just takes some extra legwork -- and others can isolate the bad data into a separate profile based on a hostname filter.  

6)  A domain lacks a consistent set of cookies.  

This can be the result of lots of mis-setups -- misconfigured dual-trackers on a page is a common cause.  To check if you have too many cookies, open Chrome Developer Tools and navigate to Resources > Cookies > yourdomain.com.  Check if you have more than one __utma, __utmb, __utmc, or __utmz cookie:

If you do, are both associated with your main domain?  If you have more than one of each cookie associated with the same main domain, GA may be setting and reading multiple sets of cookies (about inbound source, how many times a person has visited, etc.).  There’s no guarantee that it’s reading the right set, potentially giving you bad information.  

Check out Part 2 of this post for ways you can use the interface to identify other ways your data might not be tracking like you expect.