We Must Fix The Runaway Infrastructure Chain Before It Derails The Programmatic Market

The Sell Sider” is a column written by the sell side of the digital media community.

Today's column is written by Ian Davidson, vice president of platform demand at OpenX.

Why would exchanges add to their enormous server-farm costs by sending multiple bid requests to a single demand-side platform (DSP) for the same impression opportunity?

Why did publishers implement double-digit header bidder exchanges?

Why are publishers and app developers now implementing multiple containers?

The answer to each of these questions is part of a phenomenon in programmatic advertising that is creating massive inefficiency in the space. I call it “the runaway infrastructure chain.”

It all started when many publishers concluded that the more bid requests they sent to DSPs, the more money they made. Publishers started to seek and implement new infrastructure partners that allowed them to keep increasing total bid requests. As long as a new partner could deliver even marginally more revenue, it was worth adding them.

Publishers didn’t have ulterior motives outside of maximizing monetization, and this tactic of adding more and more partners seems harmless on the surface, but it actually can have a profoundly negative impact on DSPs.

Why increasing bid requests matters

The reason why publishers want to send as many bid requests as possible is because DSPs have pacing algorithms to ensure advertisers don’t spend their campaign budget too quickly. Pacing algorithms regulate and pace the number of requests advertisers bid on.

However, a certain number of bid requests must get through the pacing algorithm for the campaign to deliver, so the more requests a publisher sends, the more likely they are to get around the DSP’s pacing algorithm and receive a bid.

For example, let’s say Publisher A sends five bid requests. Traditionally, only one may be considered for bid by the DSP (see image 1), but if publishers were to significantly increase their bid requests, more of those requests would then be considered by the campaign logic (image 2).

From Publisher A’s point of view, the more bid requests it can get through a DSP’s campaign logic, the more bids it will receive, which in turn will lead to more revenue from that DSP.

While this may seem like a publisher is “gaming the system” most publishers are not aware that by sending more bid request volume, they are actually reverse-engineering a way to get around pacing algorithms. Publishers simply add more partners because it drives more revenue.

The role header bidding plays in request inflation

Publishers initially flocked to header bidding because it broke Google’s structural inventory-access advantage. However, it only took adding one to two header bidding exchange partners to significantly increase yield.

The problems started when publishers added a third or fourth exchange (or more), which continued to deliver marginal gains. Even though those gains had diminishing returns, publishers seemed to bring in every incremental header bidding partner in the ecosystem. In the process, they reverse-engineered the DSP pacing algorithms.

For example, consider two publishers that each have five users visiting their page, with every person creating one impression opportunity. If there is one DSP campaign with $10 of budget to spend, each publisher should get about $5 of spend.

But when one publisher amplifies its five impression opportunities into 20 requests, spend shifts substantially:

This is the phenomenon of request inflation. By elevating bid request levels, publishers increase the percentage of a marketer’s wallet they receive. This is why publishers implement so many header bidding exchange partners and why publishers are willing to work with multiple containers, each of which calls exchanges separately. It all leads to rampant request inflation to DSPs:

Stopping the problem

The consequences of this request inflation are enormous. To keep up with requests, DSPs now have to spend millions of dollars on server infrastructure and invest further in load balancing and QPS throttling tools to maintain access to inventory without slowing down their core technologies. This has led to declining exchange win rates, lower publisher fill rates, blurred forecasting capabilities and growing inefficiencies between exchanges and DSPs.

Header bidding itself is not a bad thing and still delivers enormous value to the industry but the unintended consequences of the technology, including bid request inflation, need to be addressed head-on for the long-term sustainability of the industry.

This can be achieved through three actions.

First, DSPs need to contractually require that exchanges do not add their own request inflation to the problem.

Second, publishers and buyers need to consolidate around exchanges that bring the most value.

And finally, exchanges and DSPs must work together to convince publishers to cap the number of containers they work with and the number of exchanges per container, potentially limiting the inventory they are willing to monetize to one client-side container and one server-side container.

These actions would cut request inflation by more than half and greatly improve unit economics for every programmatic participant while preserving the structural gains of header bidding.

Follow OpenX (@OpenX) and AdExchanger (@adexchanger) on Twitter.

1 Comment

  1. I blame pacing algos. In the PPC world it is well known that better results come from setting AdWords to spend as quickly as possible and controlling spend via bid. That requires more work in bid management and targeting. Is it not best practise in programmatic display to do the same? It seems pure laziness to expect the DSP to pace your spend for you, rather than controlling bid, frequency and targeting yourself. In addition, how is the DSP supposed to pick the appropriate impressions for you?


Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>