Feature: adUnitBidLimit

[ghost]

Type of change

• Bugfix
• Feature
• New bidder adapter
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Does this change affect user-facing APIs or examples documented on http://prebid.org?
• Other

Description of change

#3888

Prebid.js will offer a new config setting that will cap the number of bids made per ad unit when sendAllBids is enabled. This limiter setting will be called adUnitBidLimit which will be defaulted to zero which will allow sendAllBids to function normally. When the adUnitBidLimit is set to anything above 0, e.g. 2, only the targeting for the top 2 bids will be sent to the ad server for each adunit based on CPM.

An example of the setting:

pbjs.setConfig({ adUnitBidLimit: 2 })

[bretg]

I'd like to see the bid list randomized before sorting so that aardvark doesn't always win ties.

[bretg]

I've been told that the order of the list is chronological by time of bid response. This is ok.

[bretg]

@mkendall07 - would like you to take a look at this one:

1. this is another way of handling how many KVPs are sent to the ad server. It's arguably superior because it truncates cleanly instead of having a partial bid. Are the methods complementary, or would this obsolete the very recent auctionKeyMaxChars?

2. not sure I like the proposed setConfig of adUnitBidLimit -- maybe sendAllBidsLimit?

3. what order is the bids array in? I want to make sure ties don't always go the highest or lowest in the alphabet. If it's the order that the bids come back in, that might be ok.

[bretg]

Also - it's arguable -- at least worth discussing -- that deals should be given priority over bids with higher priority.

I would propose something like:

• always take the highest bid as the first block of targeting variables
• then sort on bids that contain a dealId and return the highest value deals in order
• then sort the remaining bids and them if there's room left

[bretg]

@r-schweitzer -- we're proposing the following:

1. push bid prioritization (including deals) to a different issue
2. generalize the configuration so we can work out additional controls in the (near future)

proposed config:

sendBidsControl: {
    bidLimit: 2
}

[bretg]

Ryan and I discussed in slack -- I think randomizing is the best way to go because it will resolve any question about ties and what order the bids are in now.

Apparently the list isn't in alpha-order, but it's not clear what order they're in. If they're in "first responded" order, that could be a defendable story. But if they're in "last responded" order, that would be bad. And in general, depending on the order of that list not changing might be risky.

[bretg]

Ryan found that the bid array order is based on timestamp when the bid returned.

My preference is that we still go ahead and randomize the list before picking the Top N.

1. eliminates the dependency on the order of the bids array
2. avoids any benefit from bidder ordering - as long as the response is in by the timeout, ties are random

@mkendall07 - are you good with this?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

I just wanted to bring this back to everyone's attention. Should we be randomizing the bid array or is it fair that the bidder who responds the quickest with the higher CPM be listed first?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

While I prefer randomizing from an algorithm perspective, I can accept the response-based ordering as long as we put a comment in somewhere to that effect. We don't really need to weigh down the browser with a sort for this edge case.

@mkendall07?

[mkendall07]

I'd prefer to keep the order as it reflects first in, first out. I'm good with keeping the scope small here and dealing with deal ids separately.

[mkendall07]

change LGTM, but needs a test case. Thanks

[mkendall07]

@r-schweitzer
Could you do a rebase off master? I think that might fix the circlci tests.

[mkendall07]

Just needs a docs PR