"Data Driven Thinking" is a column written by members of the media community and contains fresh ideas on the digital revolution in media.
In late 2009, the story of Real-time bidding (RTB) in the display ad space appears to be conforming to a pattern familiar to those in the software and media industries: the hype cycle (http://en.wikipedia.org/wiki/Hype_cycle). We have reached the "peak of inflated expectations" and some might say we are now on our way to the "trough of disillusionment". Companies on the sell side have announced real-time bidding systems before they existed, or that are actually something quite different (not real-time, not bidding, or neither). Some on the buy side publicly stated they were doing RTB with certain partners before it was even possible, others have publicly and privately said different things. For the record, for our CPMatic buying platform we have been building and testing real-time bidding and related cookie management infrastructure, but it is not (yet) bidding on
real-time inventory as of the writing of this. We will, but will probably NOT put out a press release when we do, though.
There is no doubt that the real story of the value behind RTB is centralized price discovery and streamlined inventory access (and the ability for this to happen at scale), and this will take some time to be realized in a meaningful way and will take widespread publisher adoption of new selling platforms. In the near term until publisher adoption increases though we’ll probably have a bunch of companies bidding in real time against each other for 15% of the ad inventory out there! In some ways RTB may be a red herring that might distract us from the underlying goal of creating a centralized market mechanism that provides quick access to inventory that gets the owner of the inventory the best price for it – RTB could cynically be seen as a way for ad exchanges/hubs outsourcing their decisioning and infrastructure costs to others. More about this later.
This sounds pretty expensive to implement vs. auctioning based on predefined rules. First, you’ve got to make a decision about every impression. 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.
Next – someone correct me if I’m wrong, but I think you’ve got to have as close to real-time reporting as possible. There’s not much point making decisions in real time if the info you base them on only gets updated every few hours. Real-time reporting at scale is neither easy nor cheap.
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. For instance, click and impression fraud is generally filtered out by the exchange after the fact, but before your reporting’s updated. CPA offer conversions take time to trickle in- forms can’t be filled out instantaneously.
Add all of the above up, and you may be wishing you stuck with your predefined rule sets.
Real-time bidding promises the marvelous ability to jump ahead of the problematic daisy-chain and buy exactly the user and ad space you want, at the price you want. But in so doing it will completely change the way different companies buy and charge advertisers for media. Why? Because a buyer’s infrastructure costs will potentially become decoupled from the costs of actually delivering an ad to a user. Advertising agencies have passed on a lot of their costs to clients, (sometimes with hefty markups e.g. 15c CPM adserving anyone?) but they’ve always been able to point to some kind of media delivery (and in some cases creative creation) as the underlying deliverable to which they attach costs.
Pay for my infrastructure please
Right Media’s (RMX) infrastructure has buckled under the strain of over 9 billion daily impressions. Latency in adserving and pixel serving abounds, and reporting outages have been common. Strange and shadowy undocumented limits on various things like targetable number of line items, confusing decisioning inconsistencies etc. And yet it still functions fairly well at huge scale, for all that, when you consider the immense work it is doing. What is clear though, is that it has been hard to make this kind of system scale and so instead, a different approach might be to have a much simpler dumber center with the complexity in decisioning pushed out to the buyers. The exchange pushes some of its costs outward to bidders, but in so doing instead of one entity having to manage the hardware for bidding, buying and adserving, everyone would to have their own version. This is where the math starts to get both interesting, and confusing.
Lets look at some hypothesized costs of bidding. Based on some rough estimates, assume it costs 50% of the cost of serving an impression to send a bid (fully burdened with maintenance costs and so on it may actually be higher, but let’s just keep it simple), so if you spent $0.02 CPM on adserving costs at scale, you might expect to pay a $0.01 CPM to bid, per thousand bids. So now, the biggest question becomes what percentage of the bids you make do you actually win?
The RTB systems let (or will let) you "pre-bid" – create a filter bucket that narrows the range of inventory you will be bidding on. This could be broad, like US only, or very narrow for example only targeted to a specific user cookie or segment created by you or by a data provider. Presumably you would want to bid on a fairly wide range of traffic, looking to find your ideal audience and take advantage of the wonders of RTB. Because if your bid range was really narrow then it begs the question – why bother to do real-time bidding at all?
Hypothetically let’s assume you bid on a broad range of traffic and win 5% of your bids. In this case, if you end up buying 500mm impressions your costs look like this:
Your serving costs at 2c end up being $10k but your bidding costs eat up $100k! If you are an ad network with margins (like the public comps) of say 40-50%, in this example say you are bidding on normally priced (not super-cheap) traffic at a $2.00 CPM cost and charging clients a nice markup to sell it at $3.50;
Assuming RTB gives you more/better access and campaigns perform better, you should see better client retention and performance but at the cost of lower margins. Here the margin for this hypothetical ad network went down from 42% to 37%. But if the traffic they were bidding on was cheaper, say they were looking for a 50c CPM campaign and paying 88c (same margin pre-serving or bidding costs), then their margin is dramatically impacted by these costs:
So in this case real-time bidding becomes less about finding the cheap inventory, and more about bidding on slightly more expensive inventory so that the bidding costs don’t depress margins too much. This is the case for an ad network, who has already historically had to bake in underlying technology costs into a single (usually fixed) CPM price. For an agency-type business model, the agency would presumably need to pass along the bidding costs to the client… and this is just the costs of bidding. Other costs for maintaining a real-time infrastructure are not accounted for by this simple set of calculations.
This is an admittedly simplistic analysis, not taking into account the uptick in results from getting more specific inventory. But it also doesn’t take into account the additional infrastructure investments needed to get those benefits. Also, having centralized price discovery and streamlined inventory access would appear to provide many of those benefits even in a static pre-bidded environment instead of in a real-time bid environment.
In summary, RTB is still a work in progress both in terms of business model AND technology. Therefore clients who are working with vendors who are doing real-time bidding on their behalf (or plan to) will need to ask questions not only about how the tech works, but how it gets paid for (out of whose pocket) as well.