Crosstown Traffic
Up until now, if you’ve used advanced Web techniques like AJAX or Flash to create interactivity on your site, you’ve been punished when it comes time to tally up your traffic. Even at this late date, most off-the-shelf tracking software remains ignorant of clicks that don’t involve simple HTML pageviews. Since your fancy Web 2.0 app doesn’t transfer HTML with every click, those clicks don’t get counted.
There are workarounds. Clunky at best and mostly proprietary, they’re seldom used by the third party agencies who audit the traffic claims of major sites (and thereby influence the rates those sites can charge advertisers). In other words, they don’t rate with the moneymen.
There have been efforts to emphasize other metrics, such as the amount of time a user spends on a site, but they haven’t amounted to much yet. At least not enough to free us from traffic woes when playing anywhere remotely near the bleeding edge.
It’s quite plain this state of affairs is holding these technologies, and the Web, back. Enough so that Adobe has apparently decided to take matters into its own hands, at great expense, by plunking down a king’s ransom to acquire Omniture, a major player in the business of counting site traffic.
With this purchase, Adobe clearly intends to construct a bully pulpit from which it can influence this state of affairs for its benefit, serving their deeply vested interest in Flash. Good for them.
So this begs a question.
Is anybody working on a solution for AJAX?
It would seem like the work currently underway on HTML5, a specification fittingly dubbed “Web Applications 1.0″ at one point, provides a choice opportunity to establish some clear guidance on trackable AJAX events in Web apps for everyone involved, and help steer the ship forward.
I’ve been scanning the spec-in-progress, but haven’t yet seen anything that seems to fit the bill. It’s a big spec. I could easily be missing something. Maybe we can use the ping attribute? Perhaps it’s in how resource fetching is defined? I don’t know. But I’m sure minds more knowledgeable than mine have some ideas. Ideas that wouldn’t constitute a proprietary hack.
The major sites won’t budge until the auditors move. The auditors won’t move until the corporate coalitions make some decisions. The corporate coalitions are comprised of the owners of said major sites. Lather, rinse, repeat.
What’s needed now is a standards body to break this stalemate. Otherwise we remain locked into a stagnant scenario where no one wants to be the first mover, and the proprietary solutions pass us all by.
This is a hard one, and definitely far too difficult to attempt to even footnote into the HTML5 spec.
The difficulty is in the fact that you’re now trying to track inter-application communication in the same way one would track an entire page load.
Web “pages” fit very well with how we’ve always tracked “readers” or “watchers” or “listeners”. An entire broadcast segment of content which includes advertising (written page, radio program, tv show, etc) is given to a group of people. We count those people and tally our numbers.
Sure, many retrieve data, maybe for a 100 x 300 pixel “latest news” widget that updates every minute, or a “most recent tweets” listing. And I could see the value in knowing whether that data was shown.
But now we’re talking about a very granular sort of tracking. Not of pages but of specific portions of data that makes those pages. And within that granularity comes application complexity. Was that widget even within the scroll range of the browser? Was the update filtered by a client-side filter like “only show sports”? Or even a simple client-side filter like a “hide” button?
Some ajax calls are merely a “hi, I’m still here!” so you don’t automatically get logged off or “how many new messages?”, which will usually respond with a number. And of course there are today’s social apps which are using ajax for chat and “notifications”. We would obviously have to differentiate these somehow.
Standardizing these things means standardizing the internals of how people write their software for purposes that have little to do with the act of writing software, which is going to be like asking developers to wear chicken suits in judicial robes and bake apple pies every Friday to make sure Management gets their just desserts before the weekend.
These things CAN be done in some ways that fit with the current model of tracking, as long as the application is planned with that in mind. But that’s way beyond the scope of HTML.
Valid points, all.
I have no illusions that there’s no one-to-one replacement for the pageview, and that any metrics guidance for HTML5 would mean a much squishier concept that wouldn’t apply in all situations. It might even imply several types of standards, to be used at the discretion of the builders, depending upon the app. In some cases, nothing would fit.
But something has to be done. The current problem isn’t going away, and in fact is growing much, much worse. I’m just looking for standards we can advocate for with the major players.