Prebid.js: shuffling bidders

Created on 13 Oct 2016 · 6Comments · Source: prebid/Prebid.js

I'm starting to hear comments from exchanges like the following:

A round robin would give every network and opportunity at starting first. Although you have a standard timeout, there seems to be a timing issue at times for the the last few networks when they have a high bid. Their high bids are not able to win in the gampad call. Round robin, may alleviate this a bit.

Exchanges seem to believe that not being at or near the top of the bidder array they are at a disadvantage. Is there any merit to this? It strikes me as splitting hairs, but perhaps I'm missing something.

If it is a valid concern, I have implemented a simple bidder shuffling algorithm that might be helpful to the general community (I'm implemented it in response to the above comment). It's not round robin but it takes bid arrays and just randomly shuffles them. If that's of interest to the broader community, I'm happy to contribute it to the code base.

feature help wanted

Source

eyedar

All 6 comments

@eyedar
It's valid I think. The reason we didn't implement is because we believed that the publisher should make those kinds of decisions based on what they believe would give them the best monetization. I think having a random shuffle on each requestBids would be nice to have as an option. Can you make PR for it?

mkendall07 on 14 Oct 2016

Yes, happy to take a hack at it. Thanks.

eyedar on 14 Oct 2016

@eyedar Any luck implementing this so far? I may start on a similar idea later this week but if you have anything I'll gladly review it

matthewlane on 26 Oct 2016

👍1

@matthewlane sorry haven't been able to get to it..I suggest you just go for it at this point...I don't want to hold anything up

eyedar on 26 Oct 2016

👍1

From running some experiments, the concern mentioned above seems to be valid, and more so when there are many bidders and/or the timeout is relatively low. In one experiment with 8 bidders and 700ms timeout, the last bidder was almost never able to respond in time, while the same bidder on the first position had a very high bid-rate.
As for the best way to handle this, I think there should be two options: random order as suggested above; and explicit order settable by the publisher outside of the configuration. The way things are now - (at least as far as I know) - with order settable by changing the bidder order in adUnits, this is both unclear to most publishers, and is easy to break when updating configuration, running a/b tests etc.