Avoid The Facepalm: 5 Common Mistakes In Your Google Analytics Tracking Code

June 11, 2015 | Dorcas Alexander
Avoid The Facepalm: 5 Common Mistakes In Your Google Analytics Tracking Code

When something’s broken and you can’t figure out how to fix it, there’s nothing like that feeling of sheepish chagrin after you discover it simply wasn’t plugged in. Believe it or not, we see the equivalent of “not plugged in” pretty often when troubleshooting broken implementations of Google Analytics.

Avoid the d’oh moment: Check your Google Analytics tracking code for these 5 common mistakes.

Mistake #1 – Code is missing

Besides simply overlooking some pages during your initial implementation of tracking code, code can turn up missing because:

  • New templates didn’t get code
  • Special campaign landing pages didn’t get code
  • Code was inadvertently deleted during edits to other parts of a template or page
  • Code from your Dev site without GA was pushed live

GA notification about missing tracking code

Best practice #1 – Get everyone on board

Have a process in place to ensure that all team members are aware of your tracking code and know where to place the Google Analytics code or where to place Google Tag Manager code on new templates or pages.

Mistake #2 – Code is duplicated

Perhaps someone accidentally pastes the new code twice or, more likely, code can be duplicated because something goes wrong during migration to a new implementation of Google Analytics.

Frequently, one code snippet is near the top of the page, while the other piece of code is near the bottom. Even if they’re right next to each other, you may find:

  • Google Tag Manager (or another tag management system) is sending hits to GA and code on the page is also sending hits to the same GA property (the same UA ID number)
  • Classic GA code and Universal Analytics code are both sending hits to the same GA property

There’s a great Chrome Extension called Google Tag Assistant that will help call out this mistake and other mistakes.


Best practice #2 – Test and monitor code changes

Any time new code is implemented, use browser developer tools to ensure that only a single pageview is tracked on each page as intended, or if multiple pageviews are tracked, then they should be sent to different UA numbers. Old code should be removed or directed to a separate UA number.

More technical users will remember that the Classic GA code sends its hits to http://www.google-analytics.com/__utm.gif, while Universal Analytics sends its hits to http://www.google-analytics.com/collect.

Chrome Developer Tools Network Tab

Chrome Developer Tools Network Tab

Bonus tip: Monitor data in Google Analytics following the implementation to watch for drops in bounce rate caused by an extra hit on each page.

Bounces are sessions with only a single hit, typically from viewing a single page. Bounce rate will plummet when pages send two hits to Google Analytics each time they are loaded.

Mistake #3 – Automatic events affect bounce rate

In addition to duplicated code, automatic events can also make bounce rates artificially low if they send a hit every time a page is loaded. Examples:

  • Internal promotions
  • Partner ads
  • Modal windows

Best practice #3 – Use non-interaction events

If a user is not intentionally interacting with your site, track a non-interaction event to keep bounce rates accurate (and useful).

Mistake #4 – Subdomain tracking is missing

Do your users travel between subdomains like blog.mydomain.com and microsite.mydomain.com? If you don’t implement subdomain tracking, Google Analytics will identify User A as User B on the second site – which will also create a second session.

Google Analytics writes cookies to identify each user and, by default, cookies are written to the full domain (with the exception of “www”). You should not rely on the default if you want to track users across subdomains, for example:

  • Users who start on mydomain.com and end on shop.mydomain.com or donate.mydomain.com
  • Users who go back and forth between subdomains (or your main domain), such as news.mydomain.com, investors.mydomain.com, or products.mydomain.com

GTM Fields to Set

Best practice #4 – Set the cookie domain to ‘auto’, add referral exclusion

Setting the cookie domain to ‘auto’ will write cookies to mydomain.com, allowing them to be read by the main domain and all subdomains of mydomain.com. This way User A will be identified as User A across subdomains and not start a second session.

Universal Analytics Code on Page

Lastly, verify that your domain is listed in the Referral Exclusion list. For more information, check out our guide: Two Steps To Correctly Tracking Subdomains in Google Analytics

Exception: If you want to track a second session each time a user travels across subdomains, stick with the default, which will tell you that sessions starting on mydomain.com were actually referrals from a subdomain like blog.mydomain.com.

Mistake #5 – Cross-domain tracking is missing

Do your users travel from mydomain.com to myotherdomain.com? In this case, subdomain tracking won’t help you. You need cross-domain tracking to make sure that User A is still identified as User A and to avoid starting a second session in your analytics data.

If both of these websites are tracked into the same Google Analytics property (they have the same UA number on them) then you’ll end getting multiple sessions and users as someone moves between the two or more sites.

Best practice #5 – Set up cross-domain tracking

There are two parts to cross-domain tracking:

  • Push the _ga cookie to the URL of the link that was clicked on Domain A, i.e. “decorate the link”, and
  • Read the cookie from that URL on Domain B. (And vice-versa, decorate links on Domain B and read cookies on Domain A.)

URL decorated with _ga cookie for cross-domain tracking

Cross-domain tracking fails because one of these components is missing.

Google Analytics knows this is a common issue, so they’ve built in a process to make it easier. There are different commands you can use to tell GA to pass the cookie when a user clicks on websites you determine, and then another command that allows the tracker on the second website to use the passed _ga value instead of creating a new one.

It sounds complicated because…. well… it is! Setting it up right may require that you hire expert assistance. It can be less complicated, but not necessarily a snap, with cross-domain tracking in Google Tag Manager.

What mistakes have you seen more than once? Have you had any facepalm moments? Please share in the comments.