RTB Part I Followup

September 19th, 2009

Ok, so in the last post I explained what Real Time Bidding (RTB) was. Greg Yardley wrote a response on his blog which made me realize that I didn’t spend quite enough time on the technical implications of RTB. He wrote:

[...] If you’re using real-time bidding, and you’re buying one impression out of a hundred, it’s got to pay the cost of the ninety-nine other decisions not to buy. [...] I think you’ve got to have as close to real-time reporting as possible. [...] Finally, your models have got to account for the data that can’t arrive in real-time, or you’re going to put your efficiency gains at risk. [...]

Add all of the above up, and you may be wishing you stuck with your predefined rule sets.

So I guess I should clarify — building a real time bidder is technically almost exactly as complex as building a performance aware ad-server — it needs all the same pieces:
* Decisioning algorithms
* Targeting & frequency tracking
* Server-side cookie store
* Log Collection & Aggregation Pipelines
* Reporting & Analytics
* Budgeting & Campaign Pacing
* A Trafficking interface

This is certainly not an undertaking to take lightly. Many developer years go into building a scalable serving platform — so yes, hiring the talent and building out the infrastructure to build a scalable bidder is certainly an expensive proposition. But also, note that if you already have an adserver, it likely has a lot of the features listed above.

Put it another way — Real Time Bidding allows you to plugin your intelligence into a massive pool of inventory. If you don’t have any intelligence yet, obviously that will be a significant investment! I’ll talk more about building “bidders” in future posts.

Now to continue the intro on RTB.

Related Posts: