Publishers should be able to filter the bids entering the auction

[pm-harshad-mane]

Feature request

After receiving the bids from bidders , there should be a way for publishers to enforce a filtering logic on given bids to decide which bids should be used in auction per slot, discarded bids can be optionally sent to cache.

Use cases:

• Across ad slots ensure that we do not serve more than one creative with same bid.meta.clickUrl ...
• Across ad slots ensuring competing brand ads like Coke and Pepsi don’t appear on the same page ( at least in the given auction )
• Similar AQ scenarios

How?

• How can we implement this?
• Is it already supported somehow?
• Are there any Prebid js events that can be used to decide which bids should not be considered in final auction but let that bid be in cache?
• Bids should be updated with appropriate rejection status so that bidders are also made aware

If not supported already, we can introduce new event that is triggered right before running the auction logic on the received bids

[pm-harshad-mane]

@patmmccann @dgirardi what do you think? We can discuss this on next PBJS PMC meeting

[dgirardi]

Is it already supported somehow?

Right now publishers can choose which bid wins, if they're prepared to write code. It's trivial when using renderAd (you just pass it a bid of your choosing); with GPT I believe targeting needs to be set manually (which we could improve). It's probably easier to adjust CPMs for a similar effect.

This is not the same as rejecting bids - but all rejecting does is generate an analytics event; it doesn't notify bidders. Rejected bids are also not kept in cache; that seems a contradiction.

[patmmccann]

possible dupe of https://github.com/prebid/Prebid.js/issues/6453

Would https://github.com/prebid/Prebid.js/issues/6453#issuecomment-804268606 solve your concerns?

[patmmccann]

perhaps this could be an extension of the recently released #12147

pbjs.requestBids({
    bidsBackHandler: (bids) => {
        // loop through ad units
        Object.entries(bids).forEach(([adUnit, bids]) => {
            // invalidate blocked ads
            bids.forEach(bid => {
                if (inRejectScope(bid.meta.adomain[0])) {
                    pbjs.markWinningBidAsUsed({ adId: bid.adId });
                }
            })
        });
        // continue normal logic
    },
});

[pm-harshad-mane]

@dgirardi I would like the filtered bids to be pushed in the cache and be used in the next auction. @patmmccann the solution mentioned above is first good step, we need to improve :

• with an API that sets a flag on bid to mark bid as filtered for auction so that analytics adapters log it accordingly
• saves bids in cache to reuse
• handle the key-value generation automatically

[dgirardi]

If filtered bids are to be kept in cache, is "mark bid as filtered" different from "bid didn't win yet"? It looks the same as loss notifications to me, with the same problem, namely that any bid could still win in the future. Also, if it was filtered from an auction, why would it not be filtered again from the next auction?

I think we can separate out the targeting problem (it should be easier to pick any particular bid as winner when using GPT); but I don't understand the goal for analytics. If publishers need to write custom logic to pick this new type of losing bid, does it help them to notify themselves through their analytics?

[pm-harshad-mane]

@dgirardi yeah we can consider, "mark bid as filtered" NOT different from "bid didn't win yet".

Why a filtered bid may win later?

• Coke on Slot1 is paying more than Pepsi on Slot2 in this auction, pub doesn't want to display both at same time on page. So save Pepsi bid in cache, in next auction we may not have a Coke bid or Coke bid is lower than cached Pepsi bid.

Finding the highest bid for an adslot after custom filtering of bids by publisher should be done by Prebid logic. Pub should not decide which is winning bid. Targeting key-value generation should also be done by Prebid post filtering.

Analytics use case: Yes, notifying themselves will be useful to know the impact of the implementation at scale.