How to verify that Google Analytics is capturing data properly
With 90+ standard reports, advanced segmentation, custom reporting, and plenty of other amazing enterprise features, I’m not breaking any new ground here by saying that Google Analytics is a great web analytics solution. It has always bothered me though, that without live tracking it can be difficult to troubleshoot, diagnose problems, confirm that you properly set up your eCommerce conversion tracking or some other custom JavaScript implementation. Waiting 8-12 hours to see if data is still being collected, or if your “test transaction” is being reflected in your reports is no way to work in an enterprise environment.
The solution is to use an HTTP proxy debugger
An HTTP proxy (HTTP Monitor) sits between the internet and your web browser. It is able to record and display all of the data that is sent and received between your web browser / client and the server. This makes it easy to see exactly what information is being sent to Google Analytics, so you can quickly diagnose and fix problems.
In my example I am going to use a web debugging application called Charles, you can download a free-trial from their website. There are plenty of other HTTP debugger applications you can use I just happen to use Charles.
- Launch your application, You may be prompted to give it privileges on your computer.
- In your web browser visit the page that you contain your Google Analytics code.
- If you look in the HTTP debugging application you will see all of the HTTP requests that were made by the page. In the list you will see http://www.google-analytics.com
- In Chrles you can click on the arrow to reveal the two HTTP request that the page made. The first request was made to by the Google Analytics JavaScript file and load it into your system memory. You can look through the window on the right to see the status file. A response code of 200 means that the JavaScript file was loaded successfully into your browsers memory. So far so good.
- The next item in the list is that data string that was sent to Google analytics as a response to you visiting the page. There is a lot of data here but if you break it up by the “&” it is easier to find what you are looking for:
- http://www.google-analytics.com/__utm.gif
- ?utmwv=4.3.1
- &utmn=1482837383
- &utmhn=freshclicks.net
- &utmcs=UTF-8 – the encoding charset of the content
- &utmsr=1280×800 – screen resolution of the visitors monitor
- &utmsc=24-bit
- &utmul=en-us – browsers language setting
- &utmje=1
- &utmfl=10.0%20r22
- &utmdt=Fresh%20Clicks%3A%20Analytics%20and%20eMarketing%20Strategies%20%C2%BB%20MailChimp%20Review%3A%20Email%20Marketing%20Provider – Name of the site and Page title
- &utmr=-
- &utmp=/download/emailWhitepaper.pdf – tracks downloads as virtual pageviews
- &utmhid=1822260590 – unique id to track this user in Google Analytics
- &utmr=0
- &utmp=/2009/04/06/email-marketing/mailchimp-review-email-marketing-provider/
- &utmac=UA-475241-7 – The Google analytics code associated with your account
- &utmcc=__utma%3D144287458.1535030466.1246519340.1246519340.1246519340.1%3B%2B__utmz%3D144287458.1246519342.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B – This last bit is information about the cookies that have been set. You can see that UTMZ is responsible for seting the campaign information about the source of the traffic.
I couldn’t identify all of the variables it was collecting so if you happen to know any of them send me a note via twitter@LaryStucker so that i can update this page.
As you can see in this example, it is easy to use web Proxy debuggers to determine if Google Analytics is being executed properly and if Google’s servers are receiving the proper information.
If you found this information helpful, have questions or want to mention one of the other HTTP proxy degugging solutions please leave a comment or message on twitter @LaryStucker