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

January 20, 2012 By Lukas Oldenburg 4 Comments

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:

Fiddler2
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:

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.
It is Chrome-only. What works on Chrome doesn’t necessarily work on Firefox or Internet Explorer.
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.

Filed Under: Errorlytics, Google Analytics, Google Chrome, Web Analytics, web analytics tools

New Video Tutorials – Using Google Analytics to track on-site campaigns

January 17, 2012 By Angela Wilkinson Leave a Comment

We learn so much by reading, but humans are visual creatures, and there are times when a video makes learning a new point easier to understand. In essence you’re watching over someone’s shoulder, albeit remotely, as they walk you through the information and explain how it works.

So we are delighted to advise that two videos have been added to the series on
Tracking on-site campaigns with Google Analytics

1. Tracking on-site campaigns with Google Analytics: The pros and cons of In-Page Analytics

Lukas explains what is meant by on-site campaigns and how to work out what links on your site (your on-site campaign) are clicked on by visitors. The three most common methods are In-Page Analytics, Event Tracking and URL Parameters and this first video is looking at In-Page Analytics.

In-Page Analytics are built in as part of Google analytics, you don’t have to set up anything once you’ve got your Analytics sorted. Accessing and understanding the data is not hard, they are very user friendly with the data shown as an overlay ontop of your actual web page.

This user friendliness does come at a price and it is important that you are aware of the limitations before deciding to use this as your tracking method. The second part of this video will explain each of the limitations and why it is a limitation so you can make an informed decision on whether this tool is suitable for your needs.

2. Tracking on-site campaigns with Google Analytics: The pros and cons of Event Tracking

This method does require some preparation work. You need to add so-called “event tracking calls” to each of your on-site campaign links. You can do that manually or use a ready-to-use script that does this automatically. Lukas explains the steps you need to take to get this script working.

However, once you have completed the preparation you have access to more functionality than with In-Page Analytics. These include filtering the campaign clicks links, eg by outgoing and destination page, retaining historical data and being able to export the data. Also, it is no problem to track links to outbound or subdomains. As you would expect, with more powerful functionality there are more complicated cons to be aware of relating to the preparation/set up and how the functionality works. Having said that, it is a very manageable way to analyze your on-site campaigns and can be used as an alternative or addition to In-Page Analytics.

Filed Under: Google Analytics, Website Optimization

Tracking On-Site Campaigns with Google Analytics, Part III: 4 pros and cons of Internal URL Referral Parameters

December 20, 2011 By Lukas Oldenburg Leave a Comment

Facebook used to have them, Amazon still has them – parameters in the URL that show through which on-site campaign link the visitor has reached the current page. But unless you really have a thoroughly thought-through system in place, you should think twice about using them.

Internal Referral Parameters are not Campaign Parameters

First of all, let me clarify what I mean by “Internal Referral Parameters” (IRPs): Those are not to be confused with (external) Campaign Parameters (for Google Analytics, read “utm_campaign” and the like). As stated in the first article of this series, you should never use Campaign Parameters in the links of your on-site campaign because they will override the external source of the visitor.

To give you an example for an IRP: If you visit Amazon.com’s homepage and click on “Books” in the left-hand navigation, you get to a page with the URL:

http://www.amazon.com/books-used-books-textbooks/b/ref=sa_menu_bo8?ie=UTF8&node=283155

See the “ref=sa_menu_bo8”? That is the IRP. It helps Amazon.com determine which links (=on-site campaigns) on its homepage, category pages, and so on are the most effective.

Another website that uses IRPs is YouTube. There, you often encounter URLs like

http://www.youtube.com/watch?v=xxxxxxxx&feature=related

Here, the “feature” parameter is telling YouTube which link you used to get to the current video (in that case, I clicked on a “related video” on the right-hand side.

We stopped using them, and so did Facebook
My company used internal referral parameters for some months, but we stopped using them for the reasons I will explain in the full article. So has Facebook, which had used them extensively until a couple of months ago. They now seem to have dropped almost all URL parameters. Apart from the challenges those can cause for web analysts, they had other negative side effects: It was not easy, for example, to get a clean or “canonical” URL of your profile or fanpage because there always was “parameter clutter” attached to it, and every page existed in the form of countless URLs. You’d even see websites linking to the “wrong” (non-canonical) version of their fanpage.

In the full article, I will look at four pros and cons of Internal Referral Parameters. Although they are easily combinable with conversion metrics and make some basic reporting easier, there are hefty issues like SEO problems, cluttered advanced reports and more work up-front if you want to avoid these problems.

Filed Under: Google Analytics, SEO, Web Analytics, web analytics tools, Website Optimization

Google Analytics, German Customer and Extra Privacy Statement Requirements

November 25, 2011 By Irene Bodle Leave a Comment

If your website uses Google analytics and you provide services to customers based in Germany you are now required to provide specific information to users in order to comply with recent changes to German data protection law.

Google Analytics and German Data Protection

Google analytics collects statistics about website users by „tracking” an individual’s use of a website. This information is then made available to website operators free of charge. Following an agreement between Google and the German data protection authorities it is now the responsibility of the operators of websites to implement certain measures when using Google analytics.

Making your Website Compliant

Under German data protection law website users must be able to stop user profiles being created and prevent their complete IP address from being saved, unless they have specifically consented to this. If you are a website operator you now need to include the following in your privacy policy:

inform users that you use Google analytics; and
advise users that they can turn off Google analytics tracking in their browser settings

In addition you should use a Google software solution that masks the IP address of the user – this blog post from Google Analytics explains what website owners can do.

Application to UK and US Websites

Although this is a German data protection issue, if your website is directed at German customers, or the majority of your customers are located in Germany, it is advisable to make these changes in order to avoid any potential breach of German data protection law.

Filed Under: Data Protection, Google Analytics, Internet Law

Tracking on-site campaigns with Google Analytics: Part 2 – The pros and cons of Event Tracking

November 17, 2011 By Lukas Oldenburg Leave a Comment

Welcome to part 2 of this series on how to track on-site campaigns, for example, teasers on your homepage. After taking a deeper look at In-Page Analytics in part 1, we are now going to dive into the world of Event Tracking and Virtual Pageviews and offer you a script that will track all the clicks on your homepage by default.

One of the best things about In-Page Analytics was that you don’t need to add any code to your page or alter your links. With Event Tracking or Virtual Pageviews though, there is no way around some additional coding.

Event Tracking or Virtual Pageviews?
So what’s the difference between Event Tracking and Virtual Pageviews again? To make a long story short: With Virtual Pageviews, you can track Pageviews for “virtual” URLs (you can decide their name), even though there is no real pageview. For example, anytime someone clicks a link on a teaser, you can tell Google Analytics to record a virtual pageview like “/teaser-click-to-url-x”.

Almost the same happens with Event Tracking. To stick with our example, when somebody clicks on a teaser link, you can tell Google Analytics to track this as an Event. The major difference is that Event Tracking doesn’t create fictional Pageviews and thus doesn’t inflate your Pageview-based data. Imagine that every click on every teaser on your homepage was tracked as an additional Pageview. That would skew your data a lot because it also has a major impact on other data like Bounce and Exit Rate, Pageviews per Visit etc…

I prefer Event Tracking
That is the main reason why I do not use Virtual Pageviews for this purpose. Be aware though that Event Tracking can also skew your bounce rate and Time on Site/Page metrics, for example when you use it to track outbound links (usually bounces). Luckily, Google Analytics has recently published a way to work around this with “Non-Interaction Events”.

In the full article, you will find advice on how to properly implement Event Tracking for on-site campaigns, including a javascript that automatically tracks all the teaser links on your homepage or category pages, and we will analyze 7 advantages and 5 disadvantages of Event Tracking as a means for tracking on-site campaigns.

Filed Under: analytics, Google Analytics, Web Analytics, Web Analytics Implementation, web analytics tools, Website Optimization

Google Secures User Data: Mixed Messages, Mixed Feelings

October 31, 2011 By David Fothergill 2 Comments

Google recently announced changes which will see them redirect all logged in users to https://www.google.com. The reason given for this change given by Google is that it will make search data more secure for it’s users, ensuring private data remains that way.

From a web analytics point of view the main impact is that no keyword referral data will be passed for organic searches in the above circumstances. Although Google played down the impact, stating that this would affect less than 10% of data, there was much uproar from the whole SEM community (I don’t think I’ve ever seen so many comments on an GA blog post or reaction blog posts), with much of the ire being directed towards what has been dubbed a highly hypocritical move: not applying the same user protection to keyword data for users clicking on AdWords ads. If user data protection is priority number one, then Google should have the courage to stick to it’s principles, especially when money is involved.

The reason for doing this is obvious – a great selling point of advertising through AdWords is the ability to accurately measure ROI and optimize performance at keyword level. To take this away would surely lead to a huge drop in revenue from the cornerstone of Google’s financial strength.

This lack of consistency is at the root of the frustration for the SEO community: by not committing fully to the cause which they give as the reason for the change, it clearly shows that Google is merely paying lip service to need to to show they are serious privacy issues. The move has all the hallmarks of a compromise; finding a middle ground to keep everyone within the Google team happy.

I specifically choose to say ‘reason’ rather than ‘defence’ in previous paragraph – in the big picture this is a positive move as you cannot deny that any move towards increasing the security of data around the web is hugely important. For anyone outside the SEM industry, it would be hard to find any negatives to this change. Ill feeling at this point from a minority voice is surely collateral damage that was expected and accepted before the changes was publicly announced.

With my web analytics hat back in place, I have to draw the conclusion that this change merely pays lip service to the idea that they are prioritizing the protection of user data.

This is a real shame, but I get the impression that no amount of outcry will change the stance Google has taken.

Change happens all the time and at the end of the day the best thing to do is to accept it, adapt and continue to do the best job possible with what data we do have. As Stephen Hawking wisely said “Intelligence is the ability to adapt to change.”.

Filed Under: analytics, Google Adwords, Google Analytics, SEM, Web Analytics

Tracking on-site campaigns with Google Analytics: Part 1 – The pros and cons of In-Page Analytics

October 27, 2011 By Lukas Oldenburg Leave a Comment

Your homepage is usually your most important landing page. But it is not an easy task to find out how the page’s teasers or “on-site” or “internal campaigns” are performing, especially for content-heavy websites. In the first part of this series on how to track on-site campaigns, we will look at some general issues and then show you 5 pros and 9 cons for Google Analytics’ “In-Page Analytics”.

I work for a company that has a homepage clogged with teasers and links. It looks like this:

Image of e-fellows.net website

The teasers change once a week, so every week there’s the question: How well did each teaser perform?

If it were teaser links in an email campaign, the solution would be easy: Just tag all the links with your campaign parameters, and make sure your email service provider offers click tracking.

Why shouldn’t I use regular campaign tags?

Some people also use these normal campaign tags (utm_source etc.) in their on-site campaigns. That is not recommended because you lose the original source of the visitor as soon as she clicks on an on-site campaign link: The original source gets overridden by the parameters of that link.

Paid solutions: Mouse Movement and Click Heat Maps

So what is the solution? You can of course resort to full-scale click-tracking tools like CrazyEgg or PicNet Mouse Eye Tracking (both are paid solutions, PicNet offers a free trial on some pages). Be aware though that this means putting a lot more Javascript on your page which often needs IT buy-in (often hard to get), can impact the page loading time, and you have to use yet another tool. I also think it’s a little obtrusive to track each and every click and mouse movement of your visitor even if they are not (easily) individually identifiable.

Analyzing teaser performance with Google Analytics

You’re not lost if you just want to stick to Google Analytics. In my opinion, there are several proven methods to analyze on-site teaser performance:

In-Page Analytics (a.k.a. “Website Overlay”)
Event Tracking or Virtual Pageviews (actually two methods, but they work similarly)
URL parameters that specify the referring link (like http:\\www.mydomain.com/article?ref=home)

All have their pros and cons. To spoil the show, I use In-Page Analytics for some purposes and Event Tracking for others. I used URL parameters for a while, but almost entirely stopped doing so because it makes reporting a lot more complex and causes other issues. But depending on your goals and your resources, all three solutions may be viable options for you.

In this series on how to track on-site campaigns, we’ll look at all three methods in detail. This first post will focus on In-Page Analytics – a powerful and often neglected tool that is available out of the box and can help tremendously on most websites, although it also has many downsides especially when you have dynamic content, outbound links or links to subdomains. To read the full article, visit “Tracking on-site campaigns” with Google Analytics in Web Analytics World’s guides pages.”

Filed Under: analytics, Google Analytics, Web Analytics, Web Analytics Implementation, web analytics tools, Website Optimization