This post has been marinating in my head for a while, and Jeremy’s recent writings pushed me over the edge to get them on paper. I traded emails with one of the guys at Google last week on this, but didn’t get very far.
Google’s AdSense has allowed lots of bloggers to monetize their content (at least on their web sites) by showing context-sensitive text ads on their sites. Google is the obvious player to produce the system I’m describing. But the current system doesn’t work for blog feeds. So, how would the perfect in-feed ad system would work? Here’s my take…
Its important to note that Google and other ad services like to track ad views and ad clicks. This helps advertisers track their return on investment and it helps Google optimize its click-through-rates. So, our ideal solution needs to allow Google to track these ads too. This means no static, same-link-in-every-post style ads like we’re seeing in Engadget right now.
If I write about my iPod mini one day, then I should see iPod ads.
The Web Service
The first thing we need is a web service for grabbing ads. Let’s assume that Google is going to add this feature to its AdSense offering. REST would be the easiest way to grab ads. You’d need to pass the IP address of the client who will be viewing the ad (remember that Google likes to track ad views and clicks), the publisher ID of the blog (your AdSense ID), an aggregator ID (more on that later), and the URL of the permalink for the specific blog post.
Something like this:
This would allow Google to match the ad to the content of the post and also the viewer. You don’t want to send the same ad to the same ad over and over again, hence the IP address. Maybe Google would allow the IP address requirement to slide, but I doubt it. Google would have to speed up its indexing (they don’t seem to get to blog posts as fast as they could, but if ContextWeb (one-time source of NetCaptor’s in-browser ads) can do realtime indexing, Google can too.
Blog authors would mark posts so that aggregators would know they wanted to display a text ad at the bottom of the post. Perhaps they could use a specially formatted HTML comment like a server-side-include or use an additional XML attribute. If you develop a standard interface, you could even swap different ad services.
Then, before displaying a post to a viewer, the aggregator would hit our web service, pass URL of the post permalink and other info, and merge the ads into the end of the post. Some authors would only flag every 5th post, some only posts over X characters long, etc. Its that authors choice. Show too may ads, and you’ll lose readers.
There are a couple of ways to merge ads from this service into feed posts: a dynamic feed processor could do the merge for each request, but it gets complicated when dealing with different types of aggregators. This would work great for direct aggregators like FeedDemon which have a one-to-one correlation between feed requests and client views. But indirect aggregators like My Yahoo!, BlogLines, Feedster complicate the picture. Remember that Google wants to be able to track ad views and ad clicks. If My Yahoo! downloads the Slashdot feed, and all its subscribers see the same ad, Google would track one ad view and a zillion ad clicks. That doesn’t work. Things would be much simpler if the aggregators merged the ads for us.
So how do we convince aggregators to cooperate and merge these ads as directed by blog authors? I could ramble on about a social contract between aggregators and bloggers, but a financial incentive would probably be more persuasive. That’s why Google would create special aggregator accounts. The aggregator will pass their ID to the web service along with the ID of the blogger so they can split revenue. A business model for aggregators… cool!
I put together a little sample that shows how AdSense displays ads based on page content. It would be trivial to wrap an XML front-end this. GPL’ed PHP code included.