How are bidding conflicts avoided in a real-time bidding (RTB) environment with multiple ad exchanges and networks?
This question was asked on Quora.com, below is my answer.

The short answer is that bidding conflicts aren’t avoided. The DSPs have no idea that they are seeing the same impression from multiple sources – whether in serial or parallel. They don’t have anything built to detect such events.

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 of bidding conflicts, 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.