May 1st, 2007
Clearly the recent acquisitions of both Doubleclick and Right Media by Google and Yahoo respectively signal a strong vote of confidence in the ad-exchange model. Reading all the news coverage of these two acquisitions made me realize that very few people out there realize the true value proposition of a centralized exchange. Sure, “transparent marketplaces”, and “auction models” are great, but why is this better than any of the existing ad-networks — Google Adsense, Advertising.com, YPN, etc.?
The Basics — A simple publisher serving ads
First lets start with a really basic question — What is an adserver? Before we can talk about an exchange, you have to understand how adserving works today. In it’s most basic form an adserver serves ads on web pages, tracks clicks on those ads and then provides reporting on the ads served and the number of clicks received on those ads. In the online space today, the vast majority of publishers, networks and advertisers all have their own adservers.
<IFRAME FRAMEBORDER=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=NO WIDTH=468 HEIGHT=60 SRC=\"http://ad.yieldmanager.com/imp?Z=468x60&s=2948&t=3\"></IFRAME>
This little snipper of HTML, when placed on a web page, informs the browser to open a small window (460×60 pixels), and in that window place whatever content is returned from “http://ad.yieldmanager.com/imp?Z=468×60&s=2948&”. When I loaded this in a browser I got the following response (truncated for clarity):
<a target="_blank" href="http://ad.yieldmanager.com/click,AAAAAIQL[...]AOUINkYAAAAA,,,"><img border="0" alt=""height="60" width="468" src="http://content.yieldmanager.edgesuite.net/atoms/8c/21/8c21402b07a3ca60e6af42e48b09a3cc.gif"></a>
Which essentially tells the browser to load an image from content.yieldmanager.com (the ad), and then when the user clicks to send him to ad.yieldmanager.com/click. Here’s a basic little diagram that outlines this simple process:
Ok, so you understand the most basic implementation of a web-page with an adserver. Now lets look at reality.
Life gets complicated — the advertiser has his own adserver
In the example above, when an ad was requested the adserver immediately responded with an image. This implies that when it comes time to pay for the ads served that the advertiser is going to rely on the Publisher’s reporting system to determine how much money he owes. In reality the advertiser is interested in tracking information as well. What this means is that both the advertiser AND the publisher need to have their own adservers. Now, the publisher’s adserver can’t immediately return an ad, instead it returns a SECOND ad tag that points to the advertiser’s adserver. Here’s another pretty diagram:
Now imagine that there’s an ad-network representing the advertiser that’s sitting in the middle, in which case what we get is:
What’s wrong with this picture?
So by looking at the diagrams above I hope you get a sense that this isn’t the most efficient of ways to buy and sell media. Think about it, for each individual ad we have to request content from three different systems! This means three times too much work is being done. So lets dig a little deeper. Essentially, the traditional adserving model has three key problems:
Lets dig into these three.
One of the things I forgot to mention above is that each point of integration between two adservers is manual work. If the Advertiser wants to buy 10 million impressions at $1.00 CPM from a Publisher the following process generally happens:
- Publisher sales rep contacts advertiser
- Publisher and advertiser negotiate contract terms (e.g. 10M @ $1.00)
- Publisher and advertiser sign a contract
- Advertiser sets up the ads in his adserver and sends over the “ad-tags” for the media buy
- Publisher has trouble trafficking ad-tags into his system and contacts his support department
- 5 days later, Publisher finally manages to get the ad-tags live and the campaign starts
So what’s wrong here? First off, there’s a certain inefficiency here. When the advertiser decides he wants 10 million impressions he probably specifies a certain set of targeting parameters to ensure that the Publisher sends him users that will be likely to be interested in his offer. For example, he may want over 18 males with a maximum of 4 ads shown to each user every day. Clearly there is a problem here. Depending on the offer, 18-25 males might be far more valuable than 50-85 year old males. Also, the first ad the user sees is far more likely to elicit a response than the second or third. So what do people do? Well, instead of setting one fixed price for all over 18 users he could setup 20 difference prices. Ten different age buckets (e.g. 18-25, 25-30, 30-35, 35-40) and two different frequency buckets (e.g. first ad, second through third ads). Well, this makes life a little bit better but there are still some problems here. First off, the higher the number of pricing points, the longer the entire process outlined above takes. 20 price points means 20 different tags in the Advertiser’s adserver, and 20 tags to upload into the Publisher’s adserver, and 20 different tags for which the Publisher may need to contact his support department for help. Here’s a nice little diagram –
In this new digital age of APIs and digital systems, why the hell does this take so much work? Can’t we do this in a better way? Well, at some point people realized that pricing flat CPM rates for inventory wasn’t the most efficient way to do things and came up with Cost Per Click (CPC) and Cost Per Acquisition (CPA) pricing models. In these systems the advertiser simply specifies how much he’s willing to pay per Click or Acquisition (generally a purchase, or lead form) and lets the publisher’s system determine the best users to deliver ads. Although this system is better than the above it introduces another set of problems. The advertiser now becomes wholly dependent on the Publisher’s optimization/prediction algorithms, which may or may not be any good! I can continue here for ages, but I’m pretty sure you are getting a sense of how inefficient the current system is.
Enough for one post. Stay tuned tomorrow for Part II — Tech issues and how the exchange model helps.
Update: Part II is ready, read on here: The Ad-Exchange Model (Part II)
- Exchange v. Network Part II: Adoption
- Exchange v. Network, Part I: What’s the difference?
- Adotas Premium v. Remnant Series
- The Ad-Exchange Model (Part II)
- On Scale Webinar!