My post on the FeedLounge blog discussing contextual ads has spawned some interesting conversation in the comments. Several people feel it would be a very bad thing to put advertising in a feed reader, others don’t have an issue with it.
I’m not going to try to tackle everything here, but I thought it would be interesting to draw a few parallels with other services and applications:
- Opera – the free version of Opera shows ads while displaying web pages. These web pages are most certainly copyrighted material. My understanding is that the ads are sold against the Opera interface and are not contextual.
- Gmail – Gmail actually shows contextual ads based on the e-mail content. E-mails are copyrighted materials as well (everything has copyright unless you give it away) so this is a clear case of a service using other’s copyrighted content to determine what ads to display.
- Yahoo! Mail – it looks to me like the ads in Yahoo Mail are not at all contextual – just ads sold against the mail application (like Opera).
- Eudora – I think Eudora was one of the first native applications to put ads in their interface. I used it for a long time and the ads were never relevant to my e-mails so I’m pretty sure they were just selling the ad space.
- Technorati – the “sponsored links” in the sidebar look like they are contextual. Even though the full content is not displayed in the Technorati search results1, the ads are still based on a combination of other’s content and user input.
- All Forum Software + AdSense – if you put AdSense on a forum page, the ads are based on the content of the page, which more than likely is copyrighted content from other people. This isn’t a case of selling ads against specific content, but again of using that content for context when determining what ads to show.
Also, I’d like to point out that FeedLounge does show any ads that are included in feeds themselves. Content providers are welcome to make money from FeedLounge users as well.
Now, there are a few ways people could put ads into a service that would definitely get people upset (me included) – of course we wouldn’t do anything like this with FeedLounge:
- Inserting ads into content – When someone inserts ads directly into the displayed content, that seems to be way over the line to me. The ad is now part of the content instead of part of the application interface. The application should display the content, not change it.
- Selling ads against specific content displayed by the application – if someone were to charge $2/1000 impressions for ads shown when gizmodo.com content was displayed and $1/1000 impressions for ads shown when cnn.com content was displayed, that would basically be selling ads against someone else’s content – not selling space in the app UI.
So what would we like to do with ads in FeedLounge?
Our intent is to help subsidise the free version of FeedLounge with revenue from ads placed in the FeedLounge interface used by “free” subscription users. We believe that having contextual ads are good for both the user (more likely to see ads of interest) and for us as the provider (ads of interest are more likely to be clicked and generate more $$). There are a few ways we can determine the ‘context’ for contextual ads:
- Pass the URL of the n’th item being displayed to the ad engine and let it serve up ads based on the content for that page.
- Pass in some meta data like the tags given to the feed that contains the n’th item being displayed.
As long as we’re not selling ads based on the content, I don’t see a problem with #1 above (it’s just like Gmail or Forums), and I certainly can’t see anyone having an issue with #2. The only problem is, there doesn’t seem to be an ad provider that will give us either of these capabilities.
As a result, we’re likely to be just like Opera, Yahoo Mail and Eudora; selling ads directly in the interface with no relevance to the displayed content or meta data.
- Actually, it looks like Technorati could show full content for very short posts. [back]
This post is part of the project: FeedLounge. View the project timeline for more context on this post.