If you're not using Google's Universal Analytics (UA) on your site yet, you soon will be. The successor to Google's old Analytics tool (which we'll call historic GA), UA was launched in late 2012 and released to public beta in 2013. But making the switch hasn't been plain sailing for everyone.

How to Upgrade Your Code

It can be tempting to switch from the historic GA code (identified by ga.js in the code snippet) to the UA code (identified by analytics.js) straight away. But if you have been running historic GA all along, this is not the best option. The best approach is to create a new test property in your Analytics account so your historic GA data continues to work while you check out UA and make sure you are seeing the data you expect. To do this, follow Kissmetrics' excellent guide: Universal Analytics: Switching to the Next Version of Google Analytics.

Issues with Universal Analytics

When you have the test property set up, you can grab and install the code for your site. There's no problem with running both historic GA and UA code together; they collect data in different ways and so there's no conflict. The reason Adept Marketing recommends you run both sets of code in tandem is so you can easily identify any issues that arise. And there definitely are issues. Three of the common ones the Adept team has seen include discrepancies in reporting of pageviews, sessions and traffic sources. The same feature that makes it easy for you to run both sets of tracking code may also be responsible for some of these discrepancies. Here's why:

  • Each ga.js tracker object starts with 10 hits that are replenished at a rate of 1 hit per second. This applies only to event type hits.
  • Each analytics.js tracker object starts with 20 hits that are replenished at a rate of 2 hits per second. This applies to all hits except for ecommerce (item or transaction).

So the two sets of code are tracking different metrics at different rates, with the UA code providing much richer data. However, it's still possible to compare like items, and this is what you need to do if you see discrepancies.

How to Troubleshoot Your Analytics Setup

Here are a few areas to check if you don't see the data you expect in analytics reports. 1. First of all, make sure that you are running both scripts on every page otherwise you will not be able to compare one set of data against another. This is particularly important for ecommerce and goal tracking. The Adept team finds Screaming Frog a good tool to use for this. Not only can you check by UA number (a handy shortcut) but you can also extract analytics data, as this helpful tutorial from SEER Interactive explains. 2. Verify that you are loading the two scripts (GA and UA) from the same place. One of Adept's clients was using historic GA code hard coded onto the page with UA code loading from a tag manager, and the two sets of data were different. When Adept moved the UA script from the tag manager and hard coded it onto the page, the data discrepancies disappeared. You need the same method for both if you want to ensure the integrity of your data. 3. Check your settings. You might have been using historic GA for so long that you don't even remember all the settings you put in place to get the data you want. A mismatch in settings is another common reason for data discrepancies. Areas to check include:

  • Filters - make sure that you have the same filters set up on your UA test profile as you had on your historic GA profile. That means checking your filters for IP exclusions, ignored referrals and excluded traffic (for example, when you ignore internal, developer or staging traffic).
  • If you have linked AdWords accounts to your historic GA profile, you also need to link the same accounts to your UA profile.
  • Timeout handling. This must be the same for both profiles. By default, session timeouts are set at 30 minutes but if you have already modified this in your historic GA profile then you need to modify it identically in your UA profile.

4. Check the location of your code. Maybe you're seeing differences in reporting because there's historic GA code running somewhere it shouldn't be. To find out, create a "show full domain" filter and you will soon locate any missing iterations. Then you can ensure that UA code is configured to match.

Other Reasons for Data Mismatch

Once you have identified and eliminated those causes of data mismatch, there are still a couple of reasons for possible discrepancies. The Adept team finds that it's usually because of session handling or cookie handling.

1. Session handling

As previously mentioned, UA collects more data than historic GA and it handles sessions differently. As MeasureLab points out, this means that since referrals trigger new UA sessions, more sessions may be reported. Though UA should give more accurate data, you may have to set up referral exclusions to handle this. Here's more detail on UA sessions from Kissmetrics.

2. Cookies handling

UA also handles cookies differently, using a single session cookie where historic GA used multiple cookies. Marketing Land's analysis says:

according to Google, the "Universal Analytics collection methods can be implemented and used to collect user interaction data without cookies." This statement indicates that some visitors that you were unable to capture previously, (ones that didn’t accept cookies), can now be counted."

And that means your visitor numbers may be higher in your UA reports.

Next Steps

Once you have eliminated all the causes of data discrepancy, you're safe to move over to the new UA code. Options include using Google's own upgrade tool or changing the UA number in your profile from test to historic. That makes it your default, and then you can get rid of the historic GA code. If you're still using historic GA on your existing site, you have a couple of years before that code is retired altogether. However, if you're setting up a new site, UA is your only option for analytics tracking with Google. Have you made the switch to UA yet? How did it go for you?