My friend Tim referred to a link at Marketing Vox which in turn refers to an article at TechWeb which has an ominous section called "The End of PageViews"... The jist of it is that AJAX will force "publishers, advertisers, Web analytics companies, and everyone else affected [...] to figure out another way"

That's a bit melodramatic, and I'll explain why.

First of all, just because you're using XMLHttpRequest (sorry, I just can't make myself use "AJAX" without thinking of some cleaning product) doesn't mean that you don't know what people clicked on. If you've ever turned on Live HTTP Headers or sniffed an Ethernet packet or two, you can clearly see the request that the browser is making back to the server for the additional content.

Conclusion: You still have your click-path data, it's just that now, the GETs from the clients are for XML docs, and your responses are text/xml rather than text/html. One (admittedly non-existent) problem addressed.

Secondly, to anyone who has actually programmed XMLHttpRequest, you are swimming in JavaScript code. This means that when you actually get the updated content from the server, it gives you the opportunity to call any old JavaScript function on the page-- including, critically, the option to "rotate" your ads... which, may I suggest, you simply use XMLHttpRequest to refresh?

Conclusion: Yes, XMLHttpRequest threatens to eliminate advertising inventory... unless you actually update the ad content using XMLHttpRequest itself! Brilliant? Or painfully obvious? You tell me.

Clicking a link results in not only updated content, but new ads as well-- and advertisers and publishers both have a common context in which to treat these XMLHttpRequest-delivered ads as new page views, new impressions just as they were before XMLHttpRequest robbed you of your "standard" pageviews... And, ironically, the heroic XMLHttpRequest comes to the rescue of the dastardly XMLHttpRequest.

So our clickstream and impression traffic remains viable, trackable, and bankable. But it gets better yet...

So far the scenario I've described is what I call "parity" revenue-- that is, by using XMLHttpRequest to switch out the ads whenever you switch out the content using XMLHttpRequest, you've reconciled the standard and begrudgingly accepted model of online advertising with the new model of updating dynamic content on the page.

But I think there is room for greater-than-parity revenue opportunities here, and the easiest way to point this out is to use the analogy of the rotating advertisements they have at sporting venues, or the lenticular style billboards, where, after a few seconds, the advertisement rotates... There's already a real-world analogue, which means that advertisers would "get it". And publishers with sticky content can show more than one ad per ad position per page.

I imagine the conversation between an Account Manager and an Advertiser would go something like this:
Advertiser: I'm looking to spend $500,000 on a 468x60 banner placement
Publisher: OK, I've got a $2 CPM placement available, which will give you 250 million impressions
Advertiser: Wow, I was hoping to get at least 300 million impressions
Publisher: Well, this is just a branding campaign right? I've got $1.50 CPM placements, but you'll be in rotation with another advertiser. Half the time, your ad won't appear, but you'll actually get 333 million impressions instead of 250!

Do the math... You can sell one advertiser one position at $500,000, or two advertisers in rotation on that same ad position for $666,666. That's a 33% increase in revenue. Not bad for a little JavaScript! Either way, far from the sky (literally) falling, publishers could be looking at parity or better revenue thanks to XMLHttpRequest.