Statistical AJAX
These days the term ‘AJAX’ seems almost as overused as ‘drop-shadow’ was 18 months ago. Though it seems that in the hype of creating on-the-fly browser-server interaction, tracking that interaction has been overlooked.
But despite the weariness of terminology, the technology behind live communication between browser and server is producing a more flexible, usable web. I have even included said technology in a few recent projects at Notre Dame with some very successful results.
One must be careful, however, as AJAX comes with its own pitfalls, just as any other web technology. Depending on the requirements for the application, a developer must focus on degradation and user expectation, among other accessibility issues. On the bright side, methods exists to accomplish these goals, and these methods are becoming more widely available as time goes on.
Maybe I’m Selfish
I care about the users needs and expectations first, of course. But what about the needs of the developer? Or the Client. One thing a website needs in order to be deemed successful in the eyes of most clients is metrics. And metrics are something that seems to have escaped AJAX, at least as of now.
What I mean is, there is no standard statistical package that can easily translate the usage of an application that uses AJAX into meaningful statistics. With standard development, each page registers its own unique URL with its own page title, with a unique identifier for the visitor. All this can easily be combined to have a pretty good idea of what’s going on at your site. But I have yet to see a tool that can do this with a site that makes heavy use of AJAX.
But It’s So Hard
First off, there is no standard way of doing AJAX. There’s the Prototype method, SAJAX, even coding the XMLHttpRequest Object yourself, amongst who knows how many other options. And each time the data is requested from the server, there is no standard script from which it grabs. All this and more make a server-side solution nearly impossible.
This leads to a JavaScript solution, and even at that, it would seem a purely custom one. Even stats packages based on JavaScript such as Mint don’t allow for tracking data after the initial page load. It seems that in the hype of creating on-the-fly browser-server interaction, tracking that interaction has been overlooked.
Begging the Question
So what kind of statistics should a client expect from the use of AJAX. Is the click-stream important, or is it the end-results we care about? Could an industry-standard solution even be created for tracking this data without the need for coding a certain way? I just love it when I ask more questions than I answer.
Post and Author Info.
Published December 09, 2005 by:
Commenting is currently off for this post.
So far there are 12 comments.
Nice.
Stats and browser history seem to go well together in my mind. Both track a users course on the web, be it on the server or client side. Methods are being developed to add back-button functionality and browser history into AJAXY apps so your point that stats have been forgotten is a noteworthy one. Seems like the two should work together. If an AJAX call is added into history (client side), metrics should be recorded (server side). Just a thought.
December 9th, 2005
In my mind, the kind of stuff that I would build with AJAX that would mess up my stats would be web based applications, for use by a restricted group that I know, and so I don’t care as much about stats.
For example, I have an in-out board here at work called AWOL that I built years ago. It’s on Freshmeat, and in GREAT need of a re-write. It would be perfect for AJAX stuff, speeding up refresh times for the lady at switchboard, ease of use for our office people, etc.
And for that application, I really couldn’t care less about stats. I already never check them for that domain.
December 9th, 2005
You’re right that if an AJAX app acts like, say, a Flash app (there’s a starting point URL and no other true pageviews beyond that), there aren’t easy ways to track with out-of-the-box stats. Rolling one’s own seems to be the way to go now, though there is certainly a place for something that can plugged in. The power of such a stats package could go well beyond standard stats (I imagine that’s the “click-stream” you mention.
However, for the tiny additions that AJAX has brought to make interactions simpler, I would say we’re getting truer stats. Say, for ranking a post in NewsGator, or a review on Amazon, should that really count as a pageview? Or, two pageviews (one for posting the vote and the other for returning to the previous page)? The user isn’t actually looking at a different page at all. So, what used to register as three pageviews really is one. Here, AJAX is helping us show the right stats.
December 9th, 2005
Luckily, I’m a PHP programmer. So, for example, using a site with MYSQL access stuff, I can just add to the PHP a simple page counter, every time function X is called, add one, etc.
But this is not nearly as in-depth as people are use to. It’s hard to justify spending the extra time you’d need to spend in order to get full stats.
But AJAX is being overused in a lot of ways. I think providing user feedback is it’s most useful part- not loading entire websites and breaking the back button, as well as killing perm links.
December 9th, 2005
Actually Steve, you’re only part right about stats packages.
I know (as I’ve implemented it) that Google Analytics can do this via the urchinTracker(); method. This makes a “request” to the stats package, and you can have mock URLs. An example request might be to put into the onComplete handler of the Ajax.Request for prototype: urchinTracker(”/shoppingcart/ajax-cart-step2.html”);
This “fakes” a hit to /shoppingcart/ajax-cart-step2.html. You can then track progress that way, tell what step people are abandoning it, etc.
Although… on the usage of such. I much prefer AJAX calls on smaller, non-essential items. I think the “digg it” button digg is the best example of AJAX I can think of. There’s absolutely no need to refresh the page for a digg – but on the other hand, there’s really no need to individually track the statistics of those who digg. You can do that via server-side checking.
A multi-step form (where analytics really excell) is no place for AJAX.
My golden rule is this: If there needs to be any more error checking than checking if the form is filled out – AJAX should be left out.
December 9th, 2005
Kyle: That’s nice to know about Google Anylitics. I was unaware of such a feature, although I could see how that could be abused to ‘fake’ things like referrer spam, etc, unless they have back-end methods to protect against such things.
On a more general level, I want to make a clear distinction between simple AJAX calls on a web site and a true Web Application. In this particular post, I’m referring to the latter, a place for doing full-out application-style functionality, not just the occasional nifty feature. Although on a lower scale, I would love to track my AJAX search with Mint using the ‘Local Search’ pepper, but for the life of me I can’t figure out how I would do that since Mint uses a tracking key that’s created by PHP that only lasts for 5 seconds. This, I would imagine, is how Shaun gets around abusing the Mint tracking feature.
December 9th, 2005
Good points, all ‘round. I hadn’t even considered the track-ability of AJAX. One of my common complaints though, sort of falls into that category, which is a lack of bookmarking ability, mentioned by Phil. I’ve been reading up quite a bit on AJAX recently, but just can’t think of a good way to put it to use for the small projects I do, without it being eye-candy just for the sake of having it. Still, it seems to be the trend that’s being followed, so it’s best to be read up on the topic, I suppose.
Re: Mint – the Session Tracker pepper logs things somewhat, but that’s assuming the user navigates away from the page they hit, to another page within your site. So yeah, that’s really not helpful for an application like Google Maps, for example, where the user never leaves that actual HTML page. I’m just thinking out loud here, and not really offering concrete answers, so I guess I’ll just cut this comment off now. :)
December 9th, 2005
Yep – the urchinTracker() method can even be called from flash events. The easiest way I’ve found to track links throughout sites is by overriding event handlers via the DOM – attaching an onclick event listener to links with a certain ID or class or rel that calls this method. This, of course, will only help you with Google Analytics…
December 13th, 2005
As far as my experience with AJAX goes, I don’t see why make it all in one page. I realise that the hype around AJAX is really being able of integrating information without jumping from page to page, and loading on-site content, but that is, in my opinion, just a way of making an unorganized website. The number one e-mail complaint I used to get from my old personal site was the lack of ‘bookmarkable’ pages, as it was in Flash. I now know this is a terrible thing for most users and AJAX is going through the same path.
Even though tools like the urchinTracker method fix this, I can’t call it a solution for the problem, anymore than I could call it a ‘hack”.
December 14th, 2005
Fernando: Making an application with AJAX does not have to be unorganized, you just have to do it correctly, just like a standard website. And again, what I’m really talking about is a full web application, not a website. When dealing with an application, bookmarking is uncommon, and often, unneccesary… especially if you architect your application correctly.
December 14th, 2005
While myself, I am just starting to get into AJAX, so take my thoughts with a grain of salt… I thought that all AJAX calls were made via the XMLHttpRequest Object. It seems to me, then, that one could simply monitor the information requests being handled, and update statistics files per one simple, standard, reusable class. Seems like there could be a seemingly unused string sent back to the browser after the server request that holds some sort of site location classifier that your prefered stat utility would understand. The string would be quite easy to dynamically generate, as most likely it will be the new, yet unupdated, url. I dont know, just a thought. By the way, veiwing this site with ie using pocket pc 2003 on a hanheld mobile industrial scanning device, and everything is looking good, heyhey
December 16th, 2005
Wow, very sweet blog – beautiful, clean and elegant.
I’m new to AJAX (as described today in the Web 2.0 era), but it’s interesting to see questions that we Flash developers have been facing for a long time. Client: “So how do we track this…”
The question of metrics in Flash apps has nearly always required custom solutions, or at least custom ways of interacting with existing stats packages. It’s also led to some interesting discussions about what needs tracking and what really doesn’t in an environment that moves beyond page loads.
The solutions I worked with usually involved calling a function in a package like WebTrends via JavaScript. Usually I’d leave hooks in the app at several key decision points in the UI which could call unique functions (or functions with args) in the tracking package. We’d usually deploy, then have several calibration cycles to see what was working and what wasn’t. If one has the luxury of smaller-scale beta testing, then you can actually redesign more easily before launch…but that’s another story. =)
When I write that out, it sounds really obvious, like “well, duh!”. To me, the interesting questions are more about “what should be tracked, and how should we interpret these results” than, “how do we track this & that”.
December 18th, 2005