Basics of Debugging Google Analytics Code: GA Chrome Debugger and other tools

**7th Feb 2012 – you can now watch the second instalment A Tutorial Video on Fiddler’s Inspector and AutoResponder functions**

Is that Virtual Pageview really being sent to Google Analytics when someone submits my registration form? Does the Event Tracking Call for outbound links get to GA in time before the visitor has left my website? Why do I not get any data for clicks on my teaser links? Questions that can drive a Web Analyst mad. Not if you know how to debug.

When I started using Web Analytics tools, there always was this huge black box: I’d put the tracking code on each and every page, and from then on, I usually waited and hoped the code would work as intended. Often, it didn’t, but I wasn’t able to see that until hours or sometimes a day later when the reports poured in to Google Analytics. Sometimes, it seemed to work, but only in some browsers. And so on. The more complex the code got (like when using Event Tracking for Flash applications), the harder it was to find out whether the code actually did what I was hoping it did. Luckily, that time is over.

Why is tracking code debugging so tedious?

  • Time lag: It usually takes several minutes to hours for the data to pour into the reports (even real-time analytics is never really real-time)
  • It was me, wasn’t it? You sometimes wonder whether the data in that report was caused by you or someone else that accidentally did the same thing on your website
  • No access to IT resources: Web Analysts may know some JavaScript, but we mostly are not IT people, so if you are testing web analytics code you sometimes have to wait for your IT guy to upload every little code change. An absolute killer for continuous improvement!
  • Testing on a test system isn’t the same as on a live system: There might be other scripts that are being loaded on the live system, the test system might be on another subdomain etc… Things that can be crucial for your code to function.
You can certainly name several more reasons why debugging the old-fashioned way is a very frustrating and time-consuming exercise.
Common Debugging Tools 
There are some good tools out there to switch on the light in the tracking code’s black box:

My absolute favorite (see next post on how to use this HTTP traffic monitoring tool). Fiddler2 makes it easy to view every request to Google Analytics (and any other javascript-based Web Analytics tool). You can even try out changes to your tracking code on your live system before releasing them to everyone, the tool is independent from browsers – and it is free!

Web Analytics Solution Profiler (WASP)
A well-known Firefox add-on by Stéphane Hamel that now belongs to iPerceptions. It recognizes a wide array of Web Analytics Tools’ tracking codes and shows you if your tracking code is successfully being executed (or not), crawls your site to find untagged pages, and so on.

A drawback is that it only works in Firefox, although it allows you to fake another user agent (like “iPad” or “Internet Explorer” which can be cool.

The basic version is free, but to be honest, it doesn’t help me that much for my use cases. Maybe I am too stupid to use it the right way, my use cases aren’t the ones the tool is made for (like using several web analytics solutions on one website), or I should try the paid versions.
So feel free to share your experience with WASP here in the comments.

Charles Debugger
A tool similar to Fiddler2, see this blog post on how to use it for Web Analytics Code Debugging.

Firebug/Chrome Developer Console:
A tool that makes any JavaScript Debugging so much easier, so it is a must-have for Web Analysts, too. And if you use Chrome, you don’t even have to install anything, not even a browser add-on (see this video by a Google Chrome Developer with 12 tricks to get the most out of the Developer Tools). That helps when you have to debug on someone else’s computer for example.

The function I use most of the time apart from the Console (where errors are being logged) is the Network Tab. It can tell us if the tracking beacon has been sent to Google Analytics successfully. To find out, look for the __utm.gif request. If it displays a “200 OK” status code (see the green light in the screen shot), you know that Google Analytics has received the current Pageview or Event. You can take a look what is inside that request in the “Headers” tab (Cardinal Path’s Kent Clark’s marvelous “Cheat Sheet” helps interpreting the values).

Chrome GA Debugger / ga_debug.js
Google’s recommended debugging tool for Google Analytics is Chrome’s Add-On “GA Debugger”. It is basically a form of using the “ga_debug.js” script without having to alter your page’s code at all (if you use ga_debug.js, you will have to change ga.js into /u/ga_debug.js on every page you want to debug). Chrome GA Debugger is a nice and easy-to-use tool that logs every Pageview and Event that you send to Google Analytics in your Chrome Developer Console (right-click on any part of the page => “Inspect Element” → go to tab “Console”):

Chrome GA Debugger shows you in an easy-to-read format what is being sent to Google Analytics without having to understand or inspect cookie variables or the Network Tab of your Console. It gives you hints like:

  • Does my visit have the correct source/medium/campaign?
  • Are there pages that accidentally override those sources?
  • Are there pages where conflicting JavaScript or other reasons hinder the Tracking Code from being executed?

I am not using Chrome GA Debugger much anymore though because:

  1. It does not help with most cases of Event or Virtual Pageview Debugging. Events or Virtual Pageviews are most often tied to a click on a link (if you want to track the clicks on outbound links for example). If you click on a link though, you usually get to a new page, in which case Chrome’s Console is being cleared – and the Event Tracking call with it. So before you can take a look at what is being logged, it is gone. EDIT: As Judd Lyon noted in the comments, you can keep the Chrome console from clearing the ga_debug info by enabling “Preserve Log upon Navigation” in the Chrome Develepor Tools settings. You can access the settings via the cogwheel icon in the lower right corner.
  2. It is Chrome-only. What works on Chrome doesn’t necessarily work on Firefox or Internet Explorer.
  3. It breaks down sometimes, especially if you click quickly from page to page. And once it has broken down, nothing is being logged anymore even if you click slowly again to ensuing pages. That freaked me out because it always made me wonder whether my code wasn’t working well. You can easily restart the tool though by reloading the current page, but, even so, that is one factor that caused me to rarely use Chrome GA Debugger.

So much for a brief overview on the matter and a deeper look into Chrome GA Debugger. In my next article, I am going to show you how to effectively use Fiddler2 on some real-life examples.


  1. Guillaume Hermans says

    I also highly suggest the “HttpFox” Firefox extension.

    It is similar to Firebug (in its “net” tab) but it allows to filter the list to see only your tracking hits instead of having to find them in the middle of every request the browser sends.

  2. says

    Thanks for the addition, Guillaume! HttpFox is certainly a great plugin.
    I still prefer Fiddler2 (see upcoming post) because that one is not dependent on any browser which is something that always causes trouble when dealing with JavaScript code.

  3. Beth says

    Try ObservePoint for FF plugin. It’s the same as WASP but detects other scripts as well and can see the request URL gif

  4. says

    Thanks for that hint. Haven’t tried ObservePoint yet, will take a look at it. Again, any browser-based tool is flawed when it comes to browser-specific bugs, and there are plenty when dealing with JavaScript.
    But for a first look, tools like ObservePoint, WASP and HttpFox are certainly a great option!

  5. says

    Nice write up!

    One thing to note: you can keep the Chrome console from clearing the ga_debug info by enabling ‘Preserve Log upon Navigation’ in the Chrome Dev Tools settings.

  6. Paulo Gonçalves says

    Nice, Judd Lyon it works, I had the same problem on GA Chrome Debugger, “Preserve Log upon Navigation” in the Chrome Dev Tools settings solves the problem.
    Now I can see that my event is sent but it does not appear on events report.
    It only happens in chrome, firefox and IE works good. Do you know why? Event beacon sent!
    utmwv=5.3.0d&utms=13&utmn=813142707&*Aderir)&utmcs=UTF-8&utmsr=1280×1024&utmvp=1280×899&utmsc=32-bit&utmul=en-us&utmje=1&utmfl=11.2%20r202&utmdt=Aderir%20%C3%A0%20M%C3%A9dis&utmhid=1035342360&utmr=0&utmp=%2Fpt-PT%2FAderirMedis%2FPages%2FSimuladorSaudeEmpresas.aspx&utmac=UA-31246961-1&utmcc=__utma%3D49035111.1594285923.1336491147.1337008027.1337076710.4%3B%2B__utmz%3D49035111.1336491147.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B&utmu=6AE~ ID : UA-XXXXXXX-1
    Page Title : Aderir à Médis
    Host Name :
    Page : /pt-PT/AderirMedis/Pages/SimuladorSaudeEmpresas.aspx
    Referring URL : 0
    Hit ID : 1035342360
    Hit Type : event
    Event Name : Simulador Saude Empresas
    Event Type : Aderir
    Visitor ID : 1594285923
    Session Count : 4
    Session Time – First : Tue May 08 2012 16:32:27 GMT 0100 (GMT Daylight Time)
    Session Time – Last : Mon May 14 2012 16:07:07 GMT 0100 (GMT Daylight Time)
    Session Time – Current : Tue May 15 2012 11:11:50 GMT 0100 (GMT Daylight Time)
    Campaign Time : Tue May 08 2012 16:32:27 GMT 0100 (GMT Daylight Time)
    Campaign Session : 1
    Campaign Count : 1
    Campaign Source : (direct)
    Campaign Medium : (none);
    Campaign Name : (direct)
    Language : en-us
    Encoding : UTF-8
    Flash Version : 11.2 r202
    Java Enabled : true
    Screen Resolution : 1280×1024
    Color Depth : 32-bit
    Ga.js Version : 5.3.0d
    Cachebuster : 813142707

  7. Paulo Gonçalves says

    I tried with another computer and it works, maybe is my chrome that has some problem??

  8. says

    Thanks, that’s a great hint. I knew about this feature in Firebug, but hadn’t found it in Chrome yet. We’ll add id in the text of the post

    @Paulo: That’s really hard to tell from here, I also don’t know if I understand your problem correctly. If it works on another computer, then it’s probably your Chrome (maybe some plugin?) that prevents the event from being sent. Or do you have some filter of your IP address in GA? Normally, if the event gets sent, it also gets to the GA reports. Have you tried the Fiddler2 HTTP debugger:
    That one’s more reliable than GA Chrome Debugger. I use it for more intense debugging. It is also non-browser dependent, that’s a big plus when debugging Javascript.

  9. Paulo Gonçalves says

    @Lukas, sorry for late response, didn’t get an alert for this.
    I finish the related task some months ago, everything was working at that moment.
    Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *