Whither the page view?

There’s an amusing graphic on Steve Rubel’s Micro Persuasion blog lamenting the demise of the page view (1994 – 2010, says Steve). Steve highlights the fact that, as web applications move beyond the traditional ‘page by page’ model, utilizing technology like Ajax and Flash, the page view – which, together with the click, is the cornerstone of how all online media is sold – is on its last legs.

The reason for this, if you haven’t already read this on a hundred other blogs, is that these new (actually, not new at all, but let’s gloss over that) technologies allow content to be refreshed in one part of the screen without the whole page (and its attendant ads) being refreshed. Steve describes this problem as online advertising’s “dirty little secret”. I don’t agree with that – sure, there are a number of competing initiatives to solve the problem, such as the Web Analytics Association’s standards committee, and the IAB’s version of the same thing – but plenty of noise is being made about the issue.

Steve rightly identifies that the issue is more a business issue than a technology one, though there is a bit of the “we’re all doomed!” in his tone. In my opinion, this is a market efficiency issue, and those tend to sort themselves out (with the odd casualty here and there) by themselves without too much bother. But the post got me thinking: what alternatives to the page view exist? Here’s a not-at-all-definitive list from the recesses of my own brain:

1. Click events. Unless you’re into radically rethinking application design, user interaction will still be facilitated by clicking the mouse. Not all mouse clicks are created equal, of course; so a site couldn’t just publish its click numbers – that would be a bit like the old hits metric, since it would be so easy to game the system by creating a click-heavy site (lots of drop-down boxes, radio buttons etc). So you’d need some way of identifying which clicks returned content, and which didn’t, which would lead you to a…
2. Content events. Although page views are being broken down into smaller pieces, there is still some intuitive mileage in the idea of the ‘content event’; a package of activity where the user requests some new content, and the content is displayed to them. This is a bit like a mini page-view. Content retrieval is Ajax apps is usually done by asking for a piece of XML from the server, and then rendering it (using JavaScript) in the browser. However, the thing that makes Ajax interesting is the fact that content can be retrieved from the server in the background (don’t forget, the “A” is for “Asynchronous”), whilst the user’s doing something else – for example, the next e-mail in the list is retrieved whilst you’re reading the current one. So you couldn’t just count the number of XML ‘pages’ retrieved from the server, because any app could game this by pre-fetching.
3. Time on site. For relatively static parts of an Ajax app interface, the amount of time the user spends interacting with the site can be relevant, because ads could be coded to auto-rotate every 30 seconds or so. There are several challenges with this, however: firstly, it’s actually quite hard to determine how long a user spends on a site because when they leave, they just disappear – their final trackable action is the last thing they did before they left, which could be many minutes before they actually left the site. Paradoxically, the serving of timed auto-rotate ads could help here, because if you know that you served 10 ads on a 30-second rotation to a user, they were at the site for at least 9 minutes 30 seconds, and for no longer than 10 minutes. The second challenge is that ads in static parts of a site design tend to be ghettoized by users – that is, they quickly learn where the ads are and ignore them. This is not a new problem – it’s why the banner has suffered as an online ad format. Finally, auto-rotating ads are much less well-suited to contextual advertising, since the ad rotation can’t take the currently displayed content into account.
4. ‘Ad refresh events’. This is a sort of combination of the above three measures – a media owner designs their app and builds in some technology for automatically inserting and rotating ads on some basis, linked to clicks/content events. So to take the example of a mail or feedreader app, display ads might refresh once every three content events, whilst a smaller contextual placement might refresh every time the ‘content pane’ (however defined) updates. It doesn’t actually matter how the media owner does the refreshing, or on what basis – merely that they stick to what they’ve said they will do, and that this can be measured. Those two last things are, of course, the sticking point – how to make sure the owner of an app behaves honestly? Plus, the media owner will have to be able to publish information about refresh mechanisms for the various types of placement on offer; I guess you’d see something like:

Placement	Ad display events
Home page top banner	1,534,346
Home page contextual	6,324,235
Login page display	3,232,453
App interface banner	768,255
App content page contextual	2,850,235

Now that I’ve written those out, it’s clearer to me what a can of worms this is. It’s an irony that, having been the most accurately measurable marketing medium of all time, advances in technology mean that online is likely to get less, not more, measurable in the future.

Have I missed any options? Let me know in the comments box if I have.