Google Analytics have released a new beta feature: Event Tracking, in order to better support RIA and Flash applications, or where ‘page views’ aren’t the only information you want to track.
The Google docs suggest this is useful for tracking: ‘any flash driven element, like a flash website or flash movie player, embedded ajax page elements, file downloads, [and] load times for data’.
Whilst we’ve been able to track things other than just page views using urchinTracker(‘/some/other/action’) for a long time now, enabling us to show how many people download a PDF, or leave the site via an external link, many of the actions which a user performs within a page we don’t want to track as part of the overall number of page views.
For instance, it is interesting for us to know how many people turn the sound off on our sites (it tells us whether the music is rubbish or annoying), or how many people stop a video halfway through playback (which also tells us whether the video is rubbish or annoying), but those figures can inaccurately inflate the ‘pageview’ count. It would be wrong to say we’d had 1 million page views if actually we were tracking the page view as one ‘hit’ and the ‘sound off’ as another.
Events allow us to seperate a pageview and an event.
Moving onto a more complex site, using a video gallery as an example, the first pageview is the gallery page, the next pageview is the user selecting a video, thats two hits (or two calls to _trackPageview()). The next step for the user is to press ‘play’. Now this is not a pageview or hit, but it is interesting from our point of view. Perhaps they press play, scrub around the video a few times, increase the volume, mute it, etc. That’s an event. Two content hits (gallery page, and then the selected video) and half a dozen events.
Within analytics, this then allows us to do two things: see how many people accessed that video, as well as how they interacted with it. Accurate number of ‘page views’, but far more granular data.
Google suggest you use an event to track a downloaded file. Personally, I would say that warrants being tracked as a page, rather than an event (consider my ‘contentview’ over ‘pageview’), as we want to track that they have accessed that download. That is why ‘pageview’ doesn’t cut the mustard. You can, however use events on top of pageviews. Track the download as a pageview AND an event of a certain type. So, perhaps your event object is ‘downloads’. _trackPageview(‘path/to/filename’) as your pageview, and the fact they’ve downloaded something as downloads._trackEvent(‘filename’). You can use the Event to then aggregate numbers of all events of that type (video interactions, downloads, external links) to get overall interaction trending – which has traditionally been difficult in Google analytics, having to some up ‘types’ of pageviews manually.
Currently, events are not related to pages. In theory, you could set up a uniquely named event for every item you’d like to track interaction on: movie_one._trackEvent(‘stop’), movie_two.trackEvent(‘stop’) or movies._trackEvent(‘movie-one-stop’), or even using labels: movies._trackEvent(‘stop’,’movie-one’), giving you a fair bit of control over how you can classify those events (you can also assign values to each event, perhaps monetary, download times, scrub-to positions etc.), but they’re then reported on entirely seperately to the page view itself. You would have to define a clear method of naming convention to ensure you can link all of the movies in Gallery A to the events you’ve tracked, as opposed to Gallery B. I hope the next step will be to attach (or nest) events to page views – for instance, get the count for all ‘stops’ under a certain content path. For now, we’ll need to use labels and values, but in any case its a great step forward for the already very nifty analytics suite.