Advertisement

Feeds

August 30th, 2009

If you’ve been following popular blogs & trade magazines you’ve probably heard the phrase “Real Time Bidding” (RTB) pop up here and there. Adexchanger brought it up in this post:

With RTB, exchange participants have a new feature coming for the buy side which should make agency business intelligence mucky-mucks and advertisers delirious after watching the development of yield management tools for the publisher or supply-side.

I don’t know how this is a hurdle, but I want to point out that saying “real-time” is the “cool” thing to say right now but there is almost no substance behind it to the trained eye.

Yet, nobody seems to be explaining either what RTB is, who’s doing it or what the implications of it are! This seems like the perfect opportunity for me to pickup blogging again (sorry for the long absence).

A Brief History Lesson

Real Time Bidding is the next evolution in how we deliver ads. First, a little refresher in how the traditional adserving process works. Take an ad-request that involves a publisher, an ad-network and an agency (if any of this is new to you, please read this post first):

The first thing to note is that the entire process is driven by the browser and not by either the publisher, network or agency adserver. Each time one party passes off the ad-request it’s sent off to the next. there is no impression level feedback loop or communication between the three serving systems. This leads to a number of challenges:

Long latency in ad-delivery. Lots of redirects, means lots of time for the browser to download content.

Lack of integration between systems. The browser naturally drops request and the integration between systems is a manual trafficking exercise. This leads to discrepancies, human error in ad scheduling and and overall pain for operations teams.

Pricing Inefficiencies. Perhaps most importantly the fact that these systems aren’t integrated means that it’s hard to buy intelligently. Buyers & algorithms must define a limited number of fixed trading rules which are implemented manually by operations teams. Additionally, the lack of integration between systems means behavioral data doesn’t translate directly and frequency caps are local to each adserver — strong limitations in a space that promises accountability and the opportunity to buy intelligently!

So what is RTB?

Ok, so we all know this world — so what is RTB? Real-Time bidding is exactly that — real time integration between serving systems. Rather than simply passing one impression off to the next system the sell-side adserver asks buyers whether or not they want to show an ad at that given time, and if so, how much they are willing to pay.

It almost looks too simple… doesn’t it? So why go real time? Well, it addresses all the issues shown above. Fewer client side hops results in faster ad-serving. Deep integration means lower discrepancies and a trail of accountability. No longer will can ad-networks claim “it wasn’t me” when a bad ads gets shown as the publisher will know exactly which as is served when. But perhaps most exciting — since the publisher asks each advertiser on every impression what he’s willing to pay he also maximizes revenue as every impression goes to the highest paying buyer.

Seems too simple

Now if you’re new to this industry the obvious question is — why wasn’t like this in the first place? First, you have to remember that the majority of adservers are focused on prioritization and not maximizing revenue or eCPM. These systems don’t function in the RTB world as they assume that delivery is a given and are trying to fulfill allocations & priorities. It’s much harder to estimate the effective CPM of all possible campaign/creative combinations versus trying to make sure that each of 20 campaigns gets it’s allocated share of impressions.

It is also worth mentioning that the idea itself isn’t particularly new. We were talking about this at Right Media over two years ago when I was still working there and Fox Audience Network has been live with a client-side real-time auction since 2007! It is also not until recently that the costs of hardware, bandwidth & CPU cycles have come down enough whereby adservers can cost-effectively decision on ads that they aren’t guaranteed to win.

What about Ad Exchanges?

Now if you read the post “Ad Exchange Model Part I” I referenced above, you may be wondering… Doesn’t Right Media solve all these problems? In theory, yes. Right Media was the first auction-based system which synchronized adserving across all parties who adopted the platform. Networks, Publishers and Advertisers who adopted either NMX, PMX or AMX respectively were integrated on a per-impression basis and didn’t suffer the problems listed above. There is one big issue with the traditional Right Media Exchange model — it requires everybody to adopt the same technology platform.

As soon as Yahoo adopted the RM platform every smart startup & technology player started calling wanting to integrate their secret sauce into the exchange. Therein lay the challenge — all these buying systems had to dumb down their algorithms into a limited number of buying rules (line items) to actually integrate. This is of course why Right Media is starting to talk publicly about RTB recently.

If all of this sounds awfully similar to what Right Media already does on behalf of our demand and supply customers on every ad request, you’re correct: We’ve been doing real-time bidding for years. We were the first to offer it, we became the largest provider, and we are still the largest supply pool of real-time, bidded, non-guaranteed inventory.

I think the above statement has the potential to do a lot of hurt in people’s understanding of real time bidding so I’d like to throw out a little clarification: Right Media pioneered impression level auctions years ago, choosing the highest paying campaign based on either a pre-registered fixed CPM bid on a line item or a run-time predicted eCPM using the internal optimization system, but has not yet been accepting real-time bids from third parties. That being said — it sounds like they’re working on it, which is exciting news!

Ok, that’s enough for now. In Part II I’ll talk more about who’s doing it (or who isn’t?) and what does this all mean for industry participants.

Hi Mike- Interesting post. Can you elaborate on what you mean when you say that Fox Audience Network has had client-side real-time auction since 2007? Thanks.

http://www.pubmatic.com/blog Rajeev Goel

Mike,
Great summary, looking forward to Part II. At PubMatic, our view is that RTB will be a key part of the future online advertising ecosystem and we’re making it a reality for our publisher partners today. We real-time enabled our entire publisher platform back in January of 2009 and are working with about a dozen early innovators in this space (including you!) to bring better monetization for our publisher clients and better ROI for media buyers.

It will be some time before RTB reaches scale within the industry but we’re looking forward to this new(er) approach to monetization.

[...] Getting down to brass tacks, Nolet gives an explanation (with graphics) of the efficiencies that real-time bidding (RTB) will offer advertisers and publishers through the exchange model. He takes exception to a part of a recent announcement by Right Media who said they’ve had an RTB solution for a while now. Nolet writes that RM “has not yet been accepting real-time bids from third parties. That being said – it sounds like they’re working on it.” Read more. [...]

Interesting. It would be nice to see something like this working at scale.

In your second diagram you show the interaction between the publisher adserver and multiple networks. Does this potentially multiple source back and forth not slow down the adserving in the same way a series of dumb redirects would? Especially when you consider that presumably if Network 1 came back with the best price out of 3 or four networks, once the publisher ad server knew that it would need to go back to it and request the actual ad again. It would be interesting to see some realistic HTTP traces for this stuff.

Also, for cookie based ad systems, per request visibility of the user to a behavioural network in this model would be harder to attain, no? The network in this case would need to “touch” the user in order to read the cookie.

Sorry for the delayed response. You’re right — RTB will certainly slow down the adserving process. That being said, it’s *far* more efficient for two adservers to communicate together than an end-user to two different serving systems. Will write more on this topic.