How are bidding conflicts avoided in a real-time bidding (RTB) environment with multiple ad exchanges and networks?
Here is how I understand the life of an RTB ad impression:
- A publisher works with an SSP who is hooked into multiple networks and exchanges.
- The SSP offers the same impression to multiple networks. (concurrently or sequentially via passback?)
- The networks may shop the impression around among other networks and are also connected to multiple exchanges.
- An exchange sees the same impression request coming in from several networks and collects bids from all connected DSPs.
- The exchange sends winning bid back to all networks.
- The networks each subtract their individual margin (or trim it to a pre-arranged CPM) and offer the remainder to the SSP.
- SSP selects the network with the highest bid (i.e. subtracted the slimmest margin) and serves the ad.
- How does the exchange know the request from the multiple networks is actually for the same impression?
- Even if an advertiser only works with one DSP/Exchange combo per campaign, the same impression could be offered via a different exchange to a different advertiser. The two exchanges run independent auctions. Now who makes the final decision what gets served? How do they account for winning a bid on the losing exchange?
- If the advertiser’s one DSP accesses multiple exchanges for each campaign, same question: How does the DSP determine the bid requests are for the same impression? Or, how can the DSP avoid bidding against itself by submitting bids to multiple exchanges for the same impression?
Within a single SSP/exchange the auction can be configured in such a way that if multiple DSPs are bidding for the same advertiser or seat holder then they are not allowed to set the second price for themselves. This is something that we’re considering at Rubicon as we learn more about the perceived problem. As the recent Econsultancy report shows, most buyers are working with more than one DSP.
I’ve seen another side of this problem happen on some of the publisher inventory on Rubicon’s platform after a deep dive on some of our logs for one of our publishers. The sequence happens like this: An impression comes to Rubicon. We send bid requests to the various DSPs. In this case we didn’t get any valid bids back so we awarded the impression to a network. That network then sent it out to DSPs and ran another auction. One of the DSPs won. Now we were perplexed because the winning DSP from the “network” auction did not choose to bid on the impression when we sent it over to them.
This reveals a second problem on the DSP side in that they cannot recognize inventory from different sources as the same inventory. There are 40,50,(100s?) of DSPs so maybe some of them don’t have this problem – but at least one of them does and they are not a small DSP.
At this time the problem, I think, is seen as an edge case. Some DSPs are not very concerned about it, others might be but don’t have time to address it because of the small impact it actually has. As more dollars move to RTB, though, things like this will become more common and some of the folks on the demand side will start solving for it.