(skip down a little further if you don’t need an introduction to Google Analytics.)

I love Google Analytics. In fact, I’m a big fan of Google as a whole, and I do the majority of my work using Google Docs, Calendar, and Gmail (online collaboration! oh, and free) and Google Analytics is a beautiful tool for businesses, whether their website‘s primary focus is online sales or just a small info-about-my-business site. If you don’t have some kind of tracking, you’re missing out on very important information; GA is a good place to start. Anybody can put GA into their website, and everybody should put something in.

The way GA works is by dropping a snippet of Javascript into your page; this javascript runs a series of tests against the visitor’s browser, checking screen resolution, flash capabilities, seeing if the user is unique, watching the user’s path through the website, checking the user’s location, and much, much more (all collected anonymously). This is all put into an interface where you can see the data collected and organized. However, AJAX applications don’t function as normal websites- you don’t get a new page hit every time you fire off an UpdatePanel, because it’s not a full page refresh. So, we need to do a little trickery to get things to work the way we want them to.

(you can start reading again if you skipped earlier.)

If you have the Google Analytics in the host page (whether the aspx page, or more likely, the master page), then you have to register a client script block that calls the trackpageview method. If you use jQuery, it’ll look something like:

ScriptManager.RegisterClientScriptBlock(UpdatePanelID, typeof(UpdatePanel), "uniqueIdentifierString", "$(document).ready(function(){ pageTracker._trackPageview('/pagename'); });", true);

If you’re not using jQuery, you’ll have to do a little more work to attach to the window’s onload event, but it’s pretty similar.
What you’re doing is registering a script block to execute when the UpdatePanel updates (because it won’t execute JS returned in the text), and using the pageTracker object (that the GA code you copied when you first set up GA on your site created) to force a pageview for a page you define. For my applications, I generally use something like “/dataentry/guestbook/edit” or “/dataentry/guestbook/delete” so that I can easily track guestbook views, as well as edits / deletes. It’s both a way to track controls you load via AJAX, and a cheap shot at logging (not perfect data, though, so you’re still best off doing all of your own logging on events, of course.)

The official Google help doc on the subject is also here: http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55519

GA is a beautiful tool; just throw in a .js file, a couple variable configurations, and you’re done. It’ll show you everthing from the most common city people are visiting from, to the highest web browser / OS combo (which is extremely useful.. can we drop IE 6 YET? The CSS support is killing me). It’s got every metric I could hope to track. However, that doesn’t solve all problems – what do we do with old trending data? How do we get them together? How do we archive these Google reports?

Even then, the answer is clear: the holy grail of universal data format, XML. Google Analytics very conveniently exports all reports as XML format, so it’s really just a matter of taking all of the old data and pushing it through a little tool thrown together quickly using Visual Studio, which parses and exports data in Google’s XML format. Now we’ve got all of our data stored and backed up, and even ready for the next thing to come after Google.

I’ll attach a breakdown of all of the different tools we looked at, tomorrow.