Redirects and Integration, Part II: Hacking Around the Browser
April 17th, 2008
In my last post I talked about redirects and the limitations they posed for online advertising. In this post I’m going to discuss the various workarounds that people have put in place to address the problem. I’m primarily going to focus on serving speed & the “one-way” challenges of redirects as there isn’t much that can be done to address the fact that redirects are inherently insecure.
Fundamentally when you are talking about “integrating” two different serving systems there are two key driving factors: tracking information and influencing the decision. In most cases tracking information is for either transparency or behavioral information. Influencing the decision is also often related to behavior as it’s close to impossible to transplant data from one cookie domain to another. So let’s look at three little ‘hacks’ that people do to make systems play nice.
Replacing a redirect with a tracking pixels
One of the primary reasons why agencies operate their own adservers is to be able to track the # of impressions that their publishing partners are serving. Yet a much simpler method of counting ads that doesn’t involve an entire redirect is to place an “impression tracking pixel” that the publisher (or network) shows on every ad call.
Let’s compare how an impression-tracking pixel impacts the serving speed compared to a more traditional redirect If both a publisher and an advertiser are using a serving system and are using standard redirects (or ad tags) to integrate, each ad call will result in three consecutive requests:
Call 1, Publisher’s Adserver. The first call obviously goes over to the publisher’s serving system. When the publisher’s adserver chooses an adserver he returns to the page either a 302 redirect or some javascript from the advertiser’s serving system. Effectively redirecting the user.
Call 2, Advertiser’s Adserver. In this call the advertiser receives the request, logs an impression and then spits back some HTML (or javascript) that tells the browser to download the ad, generally from a content delivery network (CDN).
Call 3, Creative Content. In the third call the browser requests the actual GIF/JPG/SWF file from a content delivery network and displays the ad.
If each call takes 250ms the total time to serve this ad will be 750ms as no call can occur until the prior one has fully completed. The browser doesn’t know where which advertiser adserver to request content from until he has fully received the publisher’s redirect and then the actual SWF file can’t be downloaded until the advertiser’s adserver has responded with the appropriate HTML.
When an advertiser passes the actual creative over to the publisher and includes an impression tracking pixel the ad-call sequence changes a bit.
Call 1, Publisher’s Adserver. The first call is still to the publisher’s serving system, except rather than returning the actual ad-tag (or redirect) to the advertiser the publisher’s system returns two things. One a call to the actual creative (SWF/GIF/JPG) hosted on his CDN and then a second pixel call to the advertiser’s impression tracking pixel.
Calls 2&3, Creative & Tracking Pixel. Because the user’s browser received both instructions it can now proceed to download both the creative and the tracking pixel in parallel.
If each call takes 250ms then the total time to serve this ad will be 500ms, 250 for the first publisher call and then another 250 for the creative & tracking pixel in parallel.
Benefits: The biggest benefit of the impression tracking pixel approach is that it decreases the time to serve an individual ad — something that will reduce discrepancies and increase the quality of the end user’s experience.
Drawbacks: Of course there are drawbacks with this approach. Trafficking both a creative and it’s associated impression tracking pixel is more work than a simple ad-tag. It also requires more coordination between the advertiser and the publisher
“Forking” an ad-call with an impression pixel
Impression pixels do not have to solely exist instead of a redirect. In fact, they can also be used to supplement existing ad-calls and let third parties “listen in” on an impression stream without giving them the power to manipulate an ad. For example, let’s say that a network uses the Right Media ‘NMX’ platform for their network adserving but is unhappy with the amount of information that he receives from the reporting systems. Said network’s advertisers demand more information from their media-buys — what can he do?
Obviously one answer is to add a redirect to every ad call — this quickly becomes complicated though as the network will have to host the actual gif & flash files, somewhat defeating the purpose of using a 3rd party network adserver. Also, many publishers won’t accept third party served ads from unknown adservers, posing an additional challenge when trying to buy tier-1 inventory.
Another way to address the issue is to insert a tracking pixel into every creative. On every ad-call the network fires off a pixel to his own tracking server which contains the key information that he is interested in — say — creative ID, publisher ID and referring URL. He can then log this information and provide the advertiser with the detailed reports showing exactly where his ads appeared without having to reinvent an adserver!
Using AJAX to load 3rd party content
AJAX has gained a lot of popularity recently. One way that people can integrate two serving systems is by inserting a small bit of javascript that loads the 3rd party content required to either track information or make a decision directly into the browser. For example, let’s say a network wants to know whether a behavioral data provider has valuable data on a user. If the behavioral partner he receives the impression and if not the publisher sends the impression over to one of his regular networks. He could insert a small bit of javascript that sends a request browser-side and loads the behavioral advertiser’s cookie data from the third party domain.
There are some benefits to this approach — timeouts could be set on the actual request limiting the potential slow-down. Also, since the third party isn’t in the redirect stream he doesn’t get full control over the entire impression. The downside is that the decision is made on the client side. This introduces a whole new set of challenges around tracking & writing cross-browser compatible JS.
All these methods are hacks
You’ve probably realized by now that most of the workarounds involve tricking the browser to load some content from different serving systems. Some schemes that I’ve seen get incredibly complex. I remember a customer who wanted to use Right Media’s serving system as the source of inventory but then inject behavioral information from his own cookie domain. The end result was that impressions came into the RM adserver, were redirected to his adserver and then were immediately redirected back to the RM serving system. That’s three ad-calls before an advertiser had even been selected!
That’s about it for now … Stay tuned for part III….
Maximizing network revenue
September 13th, 2007
Many publishers either don’t have a strategy for maximizing network revenue or use aging technies such as daisy-chaining to
Out of all the publishers that I’ve talked to many don’t have a solid strategy for maximizing revenue from ad-networks. Many simply don’t understand how networks price, since most are black-boxes that don’t publish how they optimize and choose which ads to display. Yet, there are a couple factors that I find can be large drivers of revenue.
The more times an individual user sees an ad, the less likely he is to respond to it. Ok, seems obvious right? What you may not realize is exactly how quickly user response to an individual ad drops. The following graph is fictitious but representative of the normal response curve of a user on a single site to repeatedly seeing the same ad.

What the above shows is that if you are to maximize revenue you need to start thinking about users and not impressions. A user that’s been on your site for hours and has seen a hundred ads is far less valuable than someone who just logged-on.
Of course every ad-network will tell you that they have a large # of advertisers and deals and that you shouldn’t worry about such things — but lets not forget the Pareto Principle, also known as the 80/20 rule. A small percentage of top advertisers will generate the majority of revenue (and hence higher rates). What that means is that each ad-network will only have one or a couple high CPM ads.
Hence the effective CPM that you receive per user from a network declines as that network continues to see him over and over again. The larger the network the slower the decline, but each will look similar — here’s a rather rough sketch of what various network payout look like (again, numbers are hypothetical, but shape of graph will generally be correct).

Obviously daisy-chaining will not work in this situation as both the medium and large networks have paying ads for each individual ad-view. In the hypothetical example above, you would want an individual user to see the following sequence of ads to maximize revenue:
- Small
- Medium
- Large
- Medium
- Large
- Large
- Medium
- Small
Comparing the effective CPM of each network individually versus optimized together:

What you see is that you can vastly increase your CPMs by distributing your networks. Now — although these are fictional numbers — the concepts are real and they work. So how do you do it? Rather simple!
It’s impossible to allocate impressions on a per view basis as I did above so we must rely on a little bit of approximation. The way to do this is to setup multiple placements or zones with your ad-network and then to frequency cap them individually within your own adserver. The above could look something like this:

The key here is not to over-complicate. Sure, a Myspace, Facebook or Bebo may create hundreds of different placements each with different caps and priorities, but there are two reasons you shouldn’t
- It’s incredibly resource intensive to manage
- You don’t have enough inventory
Each placement needs to run a minimum amount of volume otherwise pulling out the effective CPM will be nearly impossible. A lot of pricing is based around user response to ads — eg CPC or CPA based pricing. Since clicks and conversions are rare events you need to have enough volume in each placement to get a predictable effective CPM. On CPC networks you can probably get away with a couple thousand impressions per placement per day but on CPA you’ll want to go closer to ten to twenty thousand.
There is some art here as you will have to update both the frequency caps and the pricing on your placements regularly. The first couple times chances are you’ll see your network cpms fluctuate as you play with the caps & inventory allocations but as you get a hang of it you should gain some serious lift.
Enough for today — next, how to effectively target network placements to maximize revenue.
Exchange v. Network, Part I: What’s the difference?
August 16th, 2007
The “Exchange” Buzz!!
Back in May I started a three part series on “The Ad Exchange Model” where I focused primarily on the technical benefits that exchanges bring to the online advertising industry. Since then exchanges have received quite a bit of press with all the recent acquisitions and the word exchange has reached buzz-word status, without much understanding of what it actually means. Perhaps most confusing is that many don’t seem to be able to differentiate between an Exchange and an Ad-Network. For example, compare these two quotes from iMedia and Ad.com, can you tell what the difference is?
“An ad exchange is a company that brokers online advertising by bringing publishers and advertisers together on a website where they can participate in auctions for ad space.” iMedia Connections — Ad Exchanges At a Glance
“Websites have ad space. Advertisers have ads. We’re the middle man – using our phenomenal technology to match ads to space.” Advertising.com Homepage
The ‘Nasdaq’ Analogy
One of the most common explanations I have heard goes something like this — “An ad-exchange functions just like the Nasdaq.” (this is in no way a jab at ContextWeb’s Adsdaq, this analogy is regularly used on all ad-exchanges). You like the Nasdaq right? Good, the Nasdaq is efficient has some fancy electronic trading and does lots of good things, which is why you should buy this ad-exchange. Oh, well of course! Ad exchanges bring efficiency just like the Nasdaq does, that makes absolute perfect sense! Try explaining an ad-exchange like this, it’s actually quite amusing. Generally what happens is the other person’s eyes glaze over slightly and he starts nodding as if everything has been made extremely clear even though he still has no clue what the ad-exchange actually does. You see, the Nasdaq analogy really doesn’t make sense but nobody wants to sound stupid and say “I don’t get it”, so they let it slide and remain confused.
So why doesn’t it make sense? Well, we could argue semantics of stock markets versus commodity and future exchanges — but who cares. The real problem is that the Nasdaq analogy works just as well for Advertising.com as it does for Right Media, adECN or AdsDaq. The Nasdaq is a mechanism which enables people to buy and sell stocks. Ad-networks are mechanisms by which people buy and sell ad-inventory. If this is surprising, it shouldn’t be — an ad-network is a mini-marketplace, very similar to an exchange or stock-market. The whole reason we have them to begin with is to enable thousands of sites to work with thousands of buyers. Can you imagine Netflix writing individual checks to the thousands of different sites where their ads are displayed?
So what’s the difference
Even though an ad-network may perform many of the same functions as an exchange there is a subtle difference. The network operates and controls all aspects of the mini-marketplace whereas the exchange is an “agnostic” platform that many buyers and sellers use to run their own businesses. In most ad-network limits each transaction (or ad-impression) to three parties: a buyer, the network and a seller. The exceptions to this would be networks such as Tacoda where a fourth data-provider might receive a cut of the transaction based on information about the user that the network provided. Of course in reality online advertising is far more complex than that and a single online ad impression can involve far more parties.
That’s where the exchange model shines — instead of one party “operating” the exchange on behalf of a number of buyers and sellers, the exchange provides a single technology platform upon which many companies — advertisers, publishers and networks — can buy and sell ads. Each impression can have anywhere from zero to many middlemen.
Who cares?
First off, the exchange is many companies versus one in the case of the ad-network. The platform is an ecosystem that supports a large variety of business models which results in more innovation and competition. Then there are certain basic technical benefits from having multiple participants in a transaction use the same platform, something that isn’t possible with an ad-network. For example, a proper exchange removes the operational barriers that have limited access to inventory in the past are eliminated in an ad-exchange. This enhanced the liquidity of the marketplace, which results in higher and more stable rates for publishers. I’ve covered most of these benefits in detail in my ad-exchange series.
Of course some of the above is still somewhat theoretical as we are just now starting to see the exchange model mature. As the model grows, most standalone networks will find life difficult without some level of integration with one or more of the coming exchanges.
In Parts II & III of this series I’ll talk about some tactical steps Publishers and Advertisers can take to leverage exchanges as either sources of inventory or pools of advertisers to maximize ROI and revenue and perhaps some bits on how Networks can different themselves in the coming landscape.
Selling behavioral data in a multi-platform ad-industry
July 26th, 2007
Not too long ago I wrote a post One buyer, many cookies, now what?. In that post I promised that I would write about how buyers can best operate in the coming market with multiple platforms — and hence multiple cookies & adservers.
A quick refresher
In prior posts I have stressed the following:
- An exchange or ad platform, fundamentally an adserver
- Adserving is still tied to one cookie.
- Behavioral targeting is tied to knowledge about a user
- Knowledge about a user is stored in the cookie (whether as a unique user id or the actual data)
If that didn’t make sense — go read some of my older posts first.
Behavior is the future!
A single exchange with a single cookie space would have enabled true global internet wide behavioral targeting. Lets imagine I wanted to remarket to mikeonads.com users. All I would have had to do in a single platform market is add my visitors to one behavioral segment on one exchange and then place buys on that segment. Sadly this is not likely to happen since the three major internet giants swooped in and acquired practically every adserving/exchange/marketplace up for grabs. So what would I do in a world with three platforms? Lets talk about some options.
Option #1: A global user-id
Imagine this — an independent entity that offers a global user-id database. Every marketplace, ad-network or exchange subscribes to this UID service and syncs their user-ids with the global user-id. So even though Google might think that you are user #12345 and Yahoo might think you are user 54321, I can use global UID database to map your mikeonads UserID of #164 to Yahoo’s 54321 and Google’s 12345. I then simply signal to Yahoo that user 54321 is a mikeonads.com user and similarly to Google. Now each exchange knows who my users are and theoretically I can then target campaigns to my users.
Chances of this happening? Pretty close to nill. First off you’d need an independent company to provide the global UID space because none of the giants would want to give up control to another on this front. Then this conglomerate would have to get past scrutiny from the FTC, FCC, FBI, CIA and who knows who else before being able to launch, and then finally somehow convince end users, who would have probably gotten wind of this from all the press coverage, that this wouldn’t be an invasion of privacy.
Option #2: Massive user-segment mapping
In theory this solution isn’t too different from the above except that it requires browser-side communication of segments. Instead of having a global user database which allows companies to merge and map their data you simply signal each individual piece of information to each platform. If I were Revenue Science, Exelate or Tacoda I could sign up with Google, Yahoo & any other source of supply and set up my user category mapping in each system. Then, when I decide whether to add a user to a segment I fire off pixels (or whatever method to add a user to a segment) for each system.
Lets go back to remarketing to mikeonads.com users. Some people might find this a little confusing, so I made a little diagram:
Lets walk through the steps (btw, this is hypothetical, I’m not actually tracking you like this!)
- You come to mikeonads.com
- The html for the site contains three img tags that point to various platforms
- Your browser loads the Google pixel
- Google updates it’s user database and adds info to your cookie
- Your browser loads the Yahoo pixel
- Yahoo updates it’s user database and adds info to your cookie
- etc.
Why does this have to work this way? Cookies! Each company has a different UID and each UID is stored in a cookie. For Yahoo or Google to store data on this user they must know who the user is, for which they need access to the cookie, which means the user’s browser has to request content from their servers.
The above is actually a perfectly feasible model and practiced a fair amount today. The problem is that it’s difficult to scale — sure if all I want to do is tell each platform that you visit my site it’s pretty easy. But what if I have thousands of different user segments and then have weights and scores on each?
Option #3:Tagging users based on value
Instead of building a mapping of a thousand different categories across five different platforms there is another solution — flagging users based on value. Lets say I rank my behavioral segments into ten different buckets, from very low to very high value — for example, users interested in credit-cards are far more valuable than users interested in harry potter. After having assigned a value priority I can then create ten different segments in each supply platform that I want to work with. Each time I have access to a user’s browser I fire off one of the ten segments to each of the supply platforms to signal the value I place on this user, much like option #2 above. Note that I still place the exact category in my own user database.
Once I have flagged users based on value I can then place a media-buy with each platform at different price points based on the ten user segments. For example, I can have one $5.00 CPM campaign for all the high value users, credit-card and auto buyers, and a $0.50 campaign for the less interesting behaviors — low-income family, under 18, etc.. Each time I win a campaign I have the platform redirect the user to my adserver where I pick my own ad to serve based on the exact categories that the user in. The major draw-back of this approach is that it forces third party adservers. To some extent this is inevitable but this is non-ideal from a creative review, discrepancy and user experience perspectives.
Final Thoughts
Even though the industry won’t be standardizing behind one platform there are several methods of enabling cross-marketplace behaviors. Obviously there are some privacy concerns that will have to be ironed out, but those are independent of the platform being used. Also, if you own a site and are interested in remarketing to your users in ways I describe above you should check out Advertising.com’s LeadBack service which allows you to do just that!
Microsoft making the right moves to stay #3
July 26th, 2007
Microsoft has bought adECN. Still sitting in your chair? Yup, the ‘exchange’, which in reality is just the network ExperClick, was acquired by Microsoft today. I’m really at a loss as to what to say. AdECN isn’t really an exchange, more a loose consortium of ad-networks, and loose in the sense that they’re primarily based around one single ad-network. Why buy a crappy exchange instead of building on top of DrivePM, one of the top ad networks in the US?
The Ad Exchange Model (Part III)
May 4th, 2007
I’d like to continue my series. If you haven’t already, be sure to read Part I and Part II first.
After my first two points I received multiple questions around the lines of “Who will make money off of this?”, and “Who benefits most?”, “How will ad-networks survive in this environment?”. Well, I thought we’d take a look at the various types of players in the market today and discuss how they will thrive/survive/die in the exchange environment. When discussing each of these I imagine a world in which there are two or three major ad-exchanges. Say, Googleclick, Righthoo & Micro7 … Any business that wants to play has to in involved with one or more of the exchanges as in this new world, 95% of all inventory gets sold on the exchange.
The Ad-Exchange Model (Part II)
May 2nd, 2007
If you haven’t already, be sure to read The Ad-Exchange Model (Part I) first as this is a continuation of that post.
Technology Integration
I’m sure you’ve got a picture in your head by now that there’s an annoying manual process here. Well, the technology piece gets worse. Today, most technologies that companies will consider “competitive advantages” are either optimization/prediction algorithms, contextual engines or behavioral datasets. Say we have this company called Google that has a great technology that matches ads to page content. The payout on each click depends greatly on what the ad is for. Pages relevant to autos or medication will net far higher payments than pages about the local pizza joint. So how is the publisher to decide when to show ‘Adsense’ over the $1.00 CPM deal he just signed? There’s absolutely no way for the Publisher to know the effective CPM of the adsense ad before he shows it.
Currently there are two ways that publishers manage this problem. The first is to simply accept an inefficiency in pricing. He may prioritize Google Adsense at $0.95 CPM across all pages because on average that’s what he can expect to receive at the end of the month. The other option would be to setup tens or hundreds of different tags targeted to different types of pages and then setup different prices for each. Again, this would require setting up tens or hundreds of categories in Adsense and then trafficking tens or hundreds of different tags into the Publisher’s adserver. Not really the best solution.
What about a behavioral advertiser that wants to buy New York Times traffic because he thinks he has data on some of the users. Since the behavioral data is stored in his cookie (see my post here about behavioral advertisers) there is no way for the Publisher to know which of his users will be valuable to the advertiser! How is he supposed to price this? This one isn’t so easy. One way is for the advertiser to simply buy a flat rate for all New York Times users and then simply count the users for which he doesn’t have data as a loss. The other would be some sort of rudimentary integration where the advertiser drops a pixel for the Publisher’s cookie domain for his users. Again, not ideal, not simple and INEFFICIENT!
High Latency/Slow Adserving
Each call to a different adserver costs time. The more hops that a user’s browser has to go to to receive the actual ad, the more likely that he is to click-off to another page before he actually sees it. Try it, go to myspace.com and click through on a few links. How often did the actual ad finish loading? The higher the number of systems involved in an ad call, the higher the difference between how many impression the Advertiser and Publisher’s systems count. Last I heard, 5-10% of impressions are lost for each additional adserver that is added to an ad-chain.
The Exchange Model
Fundamentally I believe people don’t quite understand why Ad-Exchanges are key is because they don’t realize that an ad-exchange is simply a glorified adserver. Really… nothing special, just one centralized system instead of three or more. Take a look a the following diagram:
Notice a difference? In this case, there’s only ONE request to ONE system, the ad-exchange. The exchange is the ecosystem through which advertisers, publishers and networks all manage their businesses. Some may integrate their contextual technologies, some may simply use the system to set prices. But it’s ONE ADSERVER! Lets revisit the three main challenges we listed before.
Pricing/Operational Inefficiency — On the Exchange
Now that the advertiser and the publisher are both on the same system the whole world changes. There is no longer a need to transfer “tags” back and forth, as all the data is in the same system. Pricing is also no longer an issue as the advertiser has integrated his technology solution with the exchange and can now bid a different price on each ad impression depending on the page the user is visiting.
Technology Integration
Although there is still a significant amount of work to be done to integrate an Advertiser’s technology solution with the exchange, it’s worth it since it’s work that only needs to be done once. Once done, this technology will work across any and all publishers. Imagine this, the New York Times starts using Googleclick as their adserver, which is, of course, fully integrated with adsense. The NYT no longer has to worry about inefficient pricing for Adsense as the technology will be integrated with exchange. On every ad-call, Adsense can check the page content and place and appropriate bid according to the types of ads that it would place. Genius right?
Now what about the Behavioral network? Of course it will integrate it’s data with the exchange, and again, on every ad call it can enter bids on the users that it has data on and even price differently based on the types of data. Of course it will be slightly more difficult to integrate technology with the exchange adserver as by nature it’s more complex than a basic adserver, but this doesn’t really matter. Since the Advertiser only has to integrate his technology once, with one adserver it’s worth the effort.
High Latency/Slow Adserving
This one should be pretty obvious. Since there is only one request, ads serve faster and fewer impressions are lost.
Final Thoughts
I realize this post is long, but I think it’s important that people realize the true value that Exchanges bring to the market. It’ll be fascinating to see how the market changes as Google and Yahoo each attempt to take control of the billions of dollars of advertising that flow through the internet every day. This new model will truly change the online advertising world for the better, except perhaps for those ad-networks out that there purely benefit from the pricing and operational inefficiencies that exist in todays world.
Stay tuned for more thoughts on the potential acquisition of 24/7 by Microsoft, securing an exchange, ‘broker networks’!
The Ad-Exchange Model (Part I)
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.
Ok, so how does it really work? Well, the first thing you need to understand is how the ad-request actually happens. To request an ad from an adserver the publisher, or website, must place an ad-tag on their page. An ad-tag is simply a snippet of HTML, generally either some Javascript or an IFRAME that tells the browser to request some content from the adserver. Here’s an example tag:
<IFRAME FRAMEBORDER=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=NO WIDTH=468 HEIGHT=60 SRC=\"http://ad.yieldmanager.com/imp?Z=468×60&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.
Pricing/Operational Inefficiency
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)



