November 2009

Archive for November, 2009

Tracking 404 and 500 errors in Google Analytics

Monday, November 30th, 2009

Everyone would like to know if their users are seeing error pages due to broken links (404 not found) or server side errors (500 server error). Here’s how you can use Google Analytics and the relatively new Google Analytics Event Tracking API to track these errors.

There’s some brief advice on using this technique with WordPress, Rails or Apache at the bottom of this post.

Prerequisite – ga.js Script

Prerequisite, I’m assuming you’ve got Google Analytics set up for your site. If you did this some time ago, you might still be using the old urchin tracking script. If you are you’ll need to update to the newer ga.js script. If you know you are using ga.js, then feel free to move along to the next section.

If you are not sure, take a look at the source of one of your pages. If it looks something like the snippet below, saying urchinTracker() then you are using the old urchin tracking script and will need to upgrade:

Here are Google’s instructions for upgrading from the older urchin to the newer ga.js script.

If you are already using ga.js your pages should contain something similar to this:

Event Tracking Script

The event tracking script itself is very simple, a single line of javascript will log an event with Google Analytics:

The first parameter ’404′ is our new event category, the second parameter is the URL that has not been found, and the third parameter is the URL of the page that referred the visit.

This line should be added to your Google Analytics tracking script on your 404 Not Found error page, for example:

For 500 Server Errors it is very similar to the above but change the ’404′ to ’500′. Your tracking script becomes something like:

Viewing 404 and 500 Events in Google Analytics

Google Analytics Events are listed under Content. To see your new 404 and 500 errors, select Content / Event Tracking / Categories in the Google Analytics sidebar. You’ll see 404 and 500 listed as Categories once there have been 404 or 500 events. You can view details of these events by clicking on a particular category.

Here’s a screenshot of 404 events on one of my sites – I’ve deliberately created some 404s by pointing my browser at random-ish urls on my site’s domain:

Viewing 404 events in Google Analytics

Enjoy!
Paul

404 and 500 tracking on Apache

If you are using Apache and haven’t already specified a 404 error page you can do so by adding the following to either your .htaccess file or inside your site’s virtual host element:

ErrorDocument 404 /path/to/your/404.html

Replace /path/to/your/404.html with the path to your 404 error page. The 404 error page is just a plain old html page.

For 500 errors, you’ll need to specify a 500 error page in either your .htaccess file or inside your site’s virtual host element just like we did for 404 errors:

ErrorDocument 500 /path/to/your/500.html

404 and 500 tracking on Ruby on Rails

Ruby on Rails users will find you already have 404.html and 500.html files inside your public directory. You can add the GA tracking script there.

404 and 500 tracking on WordPress

Wordpress users can add the following lines to their theme’s footer.php inside the Google Analytics tracking script:

So for example, your footer.php should look something like:

Javascript dropdown menu of recently viewed pages

Sunday, November 29th, 2009

Lately I’ve been sharpening my Javascript skills and have read Douglas Crockford’s excellent book Javascript: The Good Parts. Last week I had a need to create a recently viewed cottages drop down menu for our holiday cottages website so I thought it would be interesting to use Javascript together with the robust Prototype library.

One advantage of using javascript is that the personalisation is client-side. This technique works with static pages and indeed, any pages rendered by the server can be the same for all users – potentially simplifying caching.

For this blog post, I’ve modified and generalised the script to show recently viewed pages instead. You can see it working by clicking on ‘Recently Viewed’ in the navigation bar at the top of this page. The script should work for many websites and blogs without much modification. Here’s the details..

The script works by creating a cookie whose value is JSON representing an array of ‘recently viewed’ objects. The ‘recently viewed’ object contains information about a recently viewed page. The array is ordered so that the most recently viewed page’s entry is the first element. No pages are duplicated, if you view a page again it simply moves to the beginning of the array. In order to keep the cookie value reasonably small, by default I’ve limited the array of recently viewed pages to the last 5 unique pages.

I was surprised to discover that Javascript doesn’t have the common block level scope found in C, Java, Ruby etc. Javascript has function level scope. We can use this idiosyncrasy together with Javascript’s support for closures to achieve something close to a module, with private variables and functions as well as public functions. Here’s the template for a ‘module’:


We need a few functions for reading and writing our cookie, and setting the expiry time for the cookie to some future date. For berivity, I won’t list those here but they’re included in the complete source at the end of this post.

We need a function for remembering a page view in our cookie. This function needs to maintain the ordered array containing the objects representing page views, the most recently viewed page comes first. It also needs to ensure there are no duplicate page views in the array. I’ve written this as two functions, a private remember function and a public rememberPage function. The public rememberPage function is only responsible for obtaining the page url and title. The private remember function is responsible for creating and maintaining the cookie of ordered unique recent objects. Following the format of our module template from above, notice how the private remember function is a stored in a variable of the constructor function, whereas the public rememberPage function is stored in a variable of the that object.

Here’s the corresponding recent function for obtaining the recently viewed page objects from the cookie:

Now on every page we want to remember we include a call to the rememberPage function. For example, my blog’s header html file has the following body tag which invokes our onload function:

Here’s our onload function (we’ll see the function renderPopup later):

At this point, we’ve got enough code to populate and maintain our recently viewed cookie. Next up is the drop down menu displaying links to the most recently viewed.

To create a drop down menu we use the CSS position. First, lets create our menu heading – a link that will cause the popup menu to display. To position the popup menu relative to the menu header link, we wrap the menu header link in a span#recently-viewed-popup-container which has position: relative. As well as the menu header link this span also nests a div which contains our popup menu.

The popup menu div has position: absolute together with left: Xpx; top: Ypx; where X and Y give the top left position of the popup menu relative to the top left of the menu header div. The popup also has a z-index: 100 to push it on top of everything else. Notice the style=”display: none;”, this hides our popup until we’re ready to show it.

Notice the onclick=”RECENTLY_VIEWED.toggleDisplayPopup();return false;” links, the return false prevents the browser following the href and changing the current url.

This brings us to the javascript function which shows and hides the popup menu – toggleDisplayPopup. Here we make use of Prototype’s $(id) to set the display of the recently-viewed-popup div, inline to show the popup and none to hide it. The variable popupId specifies the css id of our popup menu div. It is a private member variable declared and initialized in our constructor function. The popupId is available to our public function via closure.

Next we need a function to populate our popup menu from the contents of the recently viewed cookie.

Like the rememberPage function, this renderPopup function also needs to be called on every page where the recently viewed popup menu is available. Remember our body tag contains:

<body onload=”RECENTLY_VIEWED.onload();”>

And our onload function (from earlier):

That’s it. No doubt there are numerous improvements that could be made and adaptations to other JS libraries instead of Prototype. Please do comment if you’ve a question, suggestion, have done something similar or just want to say hi!

Bye, Paul

P.S. Here’s the complete code:

HTML snippet:

CSS snippet: