AJAX Counting Nightmares

More than any other topic, people ask me every week asking about AJAX (define) impression counting. I’m known as something of a leader in the advertising metrics space, so this doesn’t surprise me. I’ve been part of the Interactive Advertising Bureau’s (IAB’s) Measurement Guidelines Task Force, Broadband Committee , Rich Media Measurement Task Force, and numerous other efforts. These have all been worthwhile, if lengthy, engagements, and the IAB has done a great job of making the appropriate counting methods available to the industry and provides excellent guidance for auditing activity.

I’ve been very vocal about the AJAX counting issue; I’ve written several articles, spoken on panels, and pushed the IAB to update the impression guidelines on a very fast timeline. There’s been interest and response, and the IAB is beginning to act. But everyone involved in the process realizes this will take time. So today, my recommendations for how developers of AJAX Web pages and software applications that include advertising can deal with the unique counting issues. There are no guarantees. Final guidelines may differ from my guidance. But, I’ll put this stake in the ground. Let’s see if we can’t pivot around it.

What Are the Issues?

In a standard HTML-based Web environment, each time content is loaded on the page, the Web browser refreshes. This act of loading a Web page is called a page view. If there are advertisements on that page, a new set of ads is loaded, creating impressions.

AJAX stands for asynchronous JavaScript and XML, and it’s the asynchronous part that causes the problems. In Web pages created using AJAX, content is loaded asynchronously with no browser refresh. This causes big problems with counting page views and impressions: if a page never reloads, it’s difficult to define what a page view is. And if the page is never reloaded, deciding when it’s appropriate to refresh or load new advertising is left to the developer’s discretion. Similar issues exist around software applications that include advertising.

The current IAB impression-counting guidelines don’t provide specific guidance on this topic. But they do offer general guidance on pages where advertising is automatically refreshed or reloaded. In the current audit process, every page that automatically refreshes will be treated as a unique case. The publisher must prove to the auditor that its business rules are justified. This means an immense amount of work on all sides during an audit, and decision-making criteria for every ad refresh scenario must be documented ahead of time for the auditors.

Avoiding a Nightmare

I’ve had numerous developers of AJAX Web interfaces tell me they were going to use various rules for ad refresh for all the wrong reasons. In one case, an identical interface used different refresh rules in different countries. The reason? Increase ad inventory in one country over another. In another case, separate interfaces within the same application used completely different rules, essentially because they were coded by different teams, and no one provided guidance. There was no business justification in either case. Come audit time, the sites in question will fail their impression audits.

Then there’s the page counting problem. Several companies have told me that after deploying new versions of AJAX-intensive sites, they seemed to have lost all their traffic in comScore and Nielsen//NetRatings. I’ve also been told about developers rolling out new versions of applications that didn’t consider the Web analytics software used by the company until after the product was rolled out.

I’m not saying you should avoid using AJAX. But you should be very deliberate about rolling out a new product that could have a significant effect on your ability to measure your business and, of course, one that could completely screw up your impression audits.

Before developing an AJAX application, conduct an internal audit. Have the development team create a checklist of all the things that are done on your current pages. Look at all the ad calls and counting tags (some pages could have several Web analytics, measurement company, and third-party ad-server tracking tags), and, if at all possible, completely understand the current behavior of your pages.

When building an AJAX application, make sure you understand how user activity will be similar to and different from your current site. Be deliberate and methodical in how you invoke tracking tags and refresh advertising. Document every decision made about counting, and keep it someplace handy for audit time. It’s a very good idea to ensure the person who manages your audits takes part in this process, but at the very least ensure that he knows where the documentation is stored so the auditors can access this when needed.

My Guidance

If your AJAX application invokes new information based on user action (ideally, a click), it’s probably appropriate to think of this as a page view activity. This is relatively straightforward if you’re simply recreating an existing HTML-based application with AJAX. If you’re not changing the activity of the user significantly, just making the experience more palatable, for example, then anywhere you’d have refreshed the page in the past should invoke a new ad and call to your various page-counting tags.

This gets messy with brand new applications and software. I’ve talked a lot with people about time-based page refreshing and what’s appropriate. This isn’t a new issue and is why the language exists in the current IAB counting guidelines. But it’s never been a simple one to deal with. My general guidance is to avoid any kind of time-based advertising refreshes if at all possible.

If you feel you can’t avoid doing this because of your product’s nature, make sure you document exactly how you set the refresh rates and keep that documentation handy. You must also expose the fact that you’re automatically refreshing inventory as part of your sales process. If you adjust this refresh rate, make sure customers are notified.

Considering the range of activity that must be encapsulated can be messy, too, because ultimately this conversation isn’t about AJAX or any specific technology. It’s about the functionality of the various technologies and the appropriate business use of them. I see a looming scenario where we’d need to craft guidelines that differ by application type. One set of rules around a word processor, one for an email application, one for a mapping application, one for a photo editor, one for a news reader, and so on.

In these specific cases, I don’t have strong guidance to offer. A lot of work must be done before I could make a bold statement. In general, everyone creating advertising scenarios in these new application types should be conservative and defensible in their approach. It’s important from the advertiser’s and application end user’s standpoints. If advertising doesn’t provide a useful impression for the advertiser, it won’t perform and advertisers won’t buy. We must avoid setting negative expectations, or the whole category will be set back. We also want to avoid clutter and ad overload for the consumer lest we lose all value from the category. We don’t want another situation like the one we had with pop-ups and floating ads.

Join us for our Online Video Advertising Forum in New York City, June 16, 2006.