Conflicting Truths About Auction Duplication

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

Today’s column is written by Ben Epstein, engagement manager at Jounce Media.

Auction duplication is the new normal, and it is getting worse, not better.  

A common publisher ad serving setup might look like this:

Exchanges A, B, and C all conduct concurrent auctions for the same impression. This auction duplication drives up operating costs for technology providers and introduces complexity for programmatic buyers. But it makes publishers more money and keeps Google’s dominance in check, so we’ve accepted it as the new normal.

What our industry has not accepted is an auction trick in which one of these three exchanges issues multiple bid requests for the same impression.

If, for example, Exchange A issued two bid requests for each available impression, it may be able to harvest the randomness of DSP bidding to extract a premium bid price and deliver above-market clearing prices to the publisher. If Exchange A issued three bid requests for each available impression, its odds of capturing a premium bid increase further.

This technique has been widely rejected by programmatic buyers as unfair manipulation of auction dynamics. The buy side has collectively taken a stand to hold sell-side platforms accountable, and MediaMath lists bid duplication as the first item on its Supplier Checklist.

But here’s the thing. There are two different ways that auction duplication happens: exchange-initiated bid duplication and publisher-initiated wrapper duplication. And while the first has been unanimously rejected, the second is widely accepted.

With the introduction of header bidding and the wrappers that enable it, publishers can and often do integrate multiple wrappers. With a multi-wrapper setup, publishers integrate a single exchange multiple times – once per wrapper. This setup, pictured below, causes a single exchange to issue multiple bid requests for the same impression.

From the seller’s perspective, auction duplication is ad tech’s equivalent of doping. Publishers that don’t engage in auction duplication are at a disadvantage and experience weaker monetization than their auction duplicating competitors.

Similarly, exchanges that are only integrated once with each publisher capture subpar share of wallet relative to their multi-integrated competitors. And all exchanges, both those with single integrations and those with multi-integrations, experience thinner bid density from DSPs whose pacing algorithms pull back bids from duplicate auctions to avoid overspending and frequency cap violations. It’s a wasteful cycle that injects infrastructure cost and complexity into an already challenged programmatic marketplace.

From the buyer’s perspective, wrapper duplication is not substantially different from exchange-initiated bid duplication. Both create duplicate bid requests from the same exchange for the same impression.

If buyers reject the first, why do they accept the second? What other similar scenarios walk the line between savvy yield optimization and auction manipulation? Could a server-side wrapper initiate duplicate requests to its downstream exchange partners? Could a publisher configure the same client-side header tag twice?

A modest proposal is simply to expect each ad exchange to conduct a single auction for each available impression. Publishers should, of course, have the flexibility to integrate each exchange through whatever configuration maximizes yield, but publishers should not integrate exchanges in a way that creates auction duplication.

Buyers are already burdened with navigating upwards of 10 duplicate auctions from 10 different exchanges for each available impression. That should be enough for publishers to achieve their monetization goals, shouldn’t it?

Follow Jounce Media (@jouncemedia) and AdExchanger (@adexchanger) on Twitter.

 

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>