Quantcast
You are here: Home / Archives for web analytics tools

Debugging Google Analytics code (II): A Tutorial Video on Fiddler’s Inspector and AutoResponder functions

February 7, 2012 By Leave a Comment

Fiddler is a tool that many web developers are common with. It is my favourite tool for debugging existing tracking code and testing new code.  This video shows two useful functions for this purpose: Inspectors and the AutoResponder. 

Fiddler is a free Web debugging tool. You can download it at fiddler2.com. Fiddler logs all HTTP traffic between your computer and the internet. That means you can view just about everything that is exchanged in the background while you’re browsing the web.

What makes Fiddler so great

Apart from the functions shown in the video below, I love Fiddler because of at least one more reason: It is not dependent on any browser. Tools like Firebug, Chrome’s Web Developer Tools or the Chrome Extension “Google Analytics Debugger” (see the first article on how to use these tools) all just work within one or the other browser. But Web Analytics code is usually JavaScript code. And JavaScript works differently from browser to browser. That does not mean that Fiddler should be seen an alternative to Firebug. Both tools have their purposes and go very well together.


The following video shows how to use Fiddler for Web Analytics purposes. You will learn:

  • How to test existing code with Fiddler’s “Inspectors” feature. The use case will be the test whether a click on an application button really triggers the desired Virtual Pageview call
  • How to try out new or different tracking code without having to upload anything to your server (no IT needed!).

 

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

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

January 20, 2012 By 4 Comments

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

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:

  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.
  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.

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

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

December 20, 2011 By 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

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

November 17, 2011 By 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

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

October 27, 2011 By 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:

  1. In-Page Analytics (a.k.a. “Website Overlay”)
  2. Event Tracking or Virtual Pageviews (actually two methods, but they work similarly)
  3. 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

Engage With Webtrends: Last One in is a Rotten Egg

June 3, 2009 By 1 Comment
Guest Author: Jascha Kaykas-Wolff, VP Marketing Webtrends

John Lovett of Forrester recently published a report evaluating the current stage of Web Analytics while providing a forecast of the role it will play for organizations into 2014. Having spoken with John a handful of times before, and having met in-person recently, I’m well aware of the valuable insights into the web analytics industry he shares amongst our tightly knit community.

It seems to me there is a tremendous opportunity for web analytics to continue to grow while building on the new sets of data (Twitter, Facebook, blog comments, etc.) where the players in our space we can now analyze and offer to our customers valuable insights. As the web expands, so do the possibilities associated within web analytics.

Additionally, John notes that “while the industry has experienced some setbacks from an overall financial growth perspective, it is thriving.” It’s no surprise that the current micro-economic situation has resulted in some minor discomfort for sales among web analytics players, but the ‘awkward stage’ (as John puts it) of web analytics will be outgrown and will move onto a positive future.

Webtrends recently announced the Digital Marketing Maturity Model (DM3), our benchmark for measuring the maturity of your digital marketing campaigns. We feel strongly that addressing a maturity model within our industry is an appropriate next step to analyzing the effectiveness of all marketing spends and consequently your web analytics use. Being self-aware is a critical component to getting the most from your data and the tools you are using. In a call with John recently he made the comment (and I’m paraphrasing) “Do you think it is appropriate for a vendor to lead a maturity model discussion?” My answer to him was brief, and to the point. No. I want to reinforce that this (the DM3) is not a program that can, or should, be lead by a vendor. To that end we are in discussions with the WAA to discuss how the Web Analytics Association governing body could take this effort to the next level. In the meantime, we feel like it is the right investment to make in the industry and will continue to push forward this vendor agnostic model.

It is often the case with web analytics that customers have a powerful tool to analyze a comprehensive set of data but lack the knowledge to effectively utilize the tool and make sense of their data. I, and we at Webtrends, believe the web analytics industry needs to begin discussing the proliferation of data access, such as APIs, new applications, etc., that make sense for customers. Piggybacking on John’s ‘learning to swim’ analogy, I believe that it’s up to Webtrends, and the web analytics industry as a whole, to continue to provide the necessary support and training so our customers can take off their floaties and enjoy the full length of the pool.

Growing up I remember people using the phrase, “last one in the pool is a rotten egg.” With this in mind Webtrends is actively taking the steps to ensure that our customers will be fully supported in their marketing campaigns and with their web analytics tools. We don’t want anyone being referred to as “rotten eggs.” :)

Thanks for reading.

Jascha

Filed Under: Engage with Webtrends, Industry News, John Lovett, Web Analytics, web analytics tools

Using Behavioral Analytics to Understand Web Traffic

March 24, 2009 By 1 Comment
Standard web analytic reports provide ample information about past performance: page views, click-throughs, time on site, etc. While this information is critical for reporting on the areas and metrics to which you should paying attention, behavioral analytics can help give you guidance on what to do next.

We’ve just written a new white paper (download here) explaining how behavioral analytics can dig into your web analytics data to uncover how visitors truly interact with your website.

But, you’re probably asking, “What is behavioral analytics and why can’t my current web analytics tool deliver the same info?“

Behavioral analytics refers to the ability to uncover patterns of behavior in interaction data, uncovering clusters of people that demonstrate a propensity to go through similar sequences of actions, such as clicks on web pages, online or offline purchases, responses to marketing offers, etc. The payoff from understanding these behavioral patterns is huge: you can use this insight to optimize your site, influence people’s behavior, and ultimately drive actions that you care about – clicks, page views, purchases, etc.

The white paper explains how behavioral analytics helps you identify the content that visitors will look at next, ways to increase transactions, attributes that indicate likely-to-return visitors, factors that make visitors click on ads, and more.

You can download the paper here. Once you do, we’d like to know what you think. Comment on this blog posting, or email us at info@quantivo.com, and let us know!

Filed Under: analytics, behavioral targeting, Quantivo, web analytics tools