Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Record a default core bid ranking #4150

Open
bretg opened this issue Jan 14, 2025 · 2 comments
Open

Record a default core bid ranking #4150

bretg opened this issue Jan 14, 2025 · 2 comments

Comments

@bretg
Copy link
Contributor

bretg commented Jan 14, 2025

As described in the response to the Audio/CTV committee requests, there's a proposal to define seatbid.bid.ext.prebid.rank as a way to flag the highest priority bids. A rank of "1" would mean highest priority. Note that highest priority doesn't always mean "highest price". Sometimes deals are prioritized over open market.

The 'response' document imagines a "bid ranking module" which would assign these ranks based on account configuration to cover advanced scenarios like "open market bids more than $5 above the deal price can beat out the deal, except for deal 123"

But at this point, neither Audio nor CTV needs support for that type of advanced scenario.

Since PBS-core is already sorting bids to apply ad server targeting, I'd like to explore adding the default seatbid.bid.ext.prebid.rank to every bid. Then someday, a more sophisticated bid ranking module could be built to override this default value.

The algorithm would be very basic:

  • If ext.prebid.targeting.preferdeals is true, then sort by isDeal (true first) and then bid.price (highest first), else just bid.price (highest first).
  • If bid.price is tied the sort order can be indeterminate
  • loop through sorted bids
    • assign the current index to seatbid.bid.ext.prebid.rank. i.e. first bid gets 1, second 2, etc.
@bretg bretg moved this from Triage to Community Review in Prebid Server Prioritization Jan 15, 2025
@bretg bretg changed the title Default core bid ranking algorithm Default core bid ranking attribute Jan 15, 2025
@bretg bretg changed the title Default core bid ranking attribute Record the default core bid ranking Jan 15, 2025
@bretg
Copy link
Contributor Author

bretg commented Jan 28, 2025

This was discussed in committee, and then more in a slack thread. Here's a summary of where we stand:

  1. The Prebid proposal is that PBS should not be in the business of picking 'winners'. It currently has a primitive algorithm for doing this, but we are emphatically not an ad server, and do not provide enough enough controls around this choice to consider ourselves authoritative.
  2. There's a community requirement that some host companies don't want to cache bids that don't "win".

So the proposed vision for the future is:

  1. Caching behavior could have a flag that can disabled so PBS-core doesn't cache and a module can handle caching and updating the ORTB with the cache IDs.
  2. PBS-core will supply a default "response ranking algorithm" and write the values into seatbid.bid.ext.prebid.rank
  3. If turned off, PBS-core will not cache bids to PBC.
  4. A 'processed auction response' module can refine the ranking however it wants.
  5. A separate 'processed auction response' module can call PBC for whatever bids it care to call winners and add whatever ORTB it wants to the results. Specifically, this module would need to:
    1. add the ext.prebid.cache object where relevant
    2. update seatbid.bid.ext.prebid.targeting to add hb_uuid, hb_cache_id, hb_uuid_BIDDER, and/or hb_cache_id_BIDDER where relevant. (unless we already have a targeting module that can do this)

It's understood that there's some legacy cruft in core. At some point in a major release, we should pull the "winning bid" logic and the "targeting" out and make them modules. PBJS doesn't use our targeting anyhow. AMP and App do.

@bretg bretg changed the title Record the default core bid ranking Record a default core bid ranking Feb 6, 2025
@bretg
Copy link
Contributor Author

bretg commented Feb 6, 2025

I promised to do another take on this with more details.

Here are the use cases:

  1. Legacy web - the client just wants PBS to supply seatbid.bid.ext.prebid.targeting as defined today: includebidderkeys, preferdeals, etc. A winning bid is chosen for each imp and the hb_pb targeting is applied to that bid.
  2. Legacy AMP - a single winning bid is chosen and a simplified JSON format is emitted that includes defined targeting values.
  3. Audio - the Audio committee wants to filter bid responses that don't match the request and choose the "best" remaining bid.
  4. CTV - the CTV committee wants to filter some bid responses and convert others, then choose the "Top N" bids.

Assumptions:

  • Prebid Server should not attempt to create an algorithm to pick "winners". We are not an ad server and there are too many edge cases to get this right.
  • It would not be a good design choice to jam decisioning logic into a formatting module.
  • Some host companies want to limit the caching of VAST and bids to the "winning" bids.
  • The ad-server targeting logic doesn't really belong in PBS-core as it assumes certain ad server capabilities.
  • It's not currently feasible to deliver a "required" module. i.e. we can't rip the targeting functionality out of core into a module.

Long Term Proposal

  1. Bid response validation is enhanced to support enforcing the VAST protocols field and other rules.
  2. Winning, caching, and targeting logic are removed from PBS-core
  3. PBS supports delivering certain "core modules" pre-configured as defaults.
  4. A new "pb-bid-ranking" module at the processed-auction-response stage ranks the bids in seatbid.bid.ext.prebid.rank. It uses signals like preferdeals to influence the ranking. The details of this module would be in a separate issue.
  5. Host companies can turn this off and supply their own if they'd like.
  6. A new "pb-targeting" module runs after ranking. It applies seatbid.bid.ext.prebid.targeting values per existing rules: includebidderkeys, multibid, etc. This can depend on the source of the request. e.g. nothing needed for Prebid.js calls. The details of this module would be in a separate issue.
  7. A new "pb-cache" module runs after targeting. It can take options for how how many bids should be cached for each imp. e.g. ("all", "top 1", "top N"). After receiving the cache keys, it can be configured to update the targeting -- seatbid.bid.ext.prebid.targeting.{hb_uuid, hb_cache_id, hb_uuid_BIDDER, hb_cache_id_BIDDER}. The details of this module would be in a separate issue.
  8. Exitpoint formatting modules like those developed by Audio and CTV committees can run.

Interim Proposal

There are quite a few changes in the Long Term Proposal and I'm expecting pushback on the "required default module" idea.

So here's a compromise:

  1. New account-level config flag to disable default caching. This is for Yahoo so they don't need a new module hook. If this flag has disabled caching:
    1. Exclude calls to the /vtrack endpoint - those should be cached
    2. VAST creatives should still get modified with tracking as appropriate.
    3. The hb_uuid and hb_cache_id targeting values should not be added.
    4. It's entirely up to a host-company supplied module to implement caching and adding hb_uuid and hb_cache_id targeting values.
  2. New account-level config flag to enable default bid ranking. PBS-core sets seatbid.bid.ext.prebid.rank:
    1. If ext.prebid.targeting.preferdeals is true, then sort by isDeal (true first) and then bid.price (highest first), else just bid.price (highest first).
    2. If bid.price is tied the sort order can be indeterminate
    3. loop through sorted bids - assign the current index to seatbid.bid.ext.prebid.rank. i.e. first bid gets 1, second 2, etc.
  3. Another processed-auction-response module can override seatbid.bid.ext.prebid.rank
  4. Audio and CTV committee modules operate on seatbid.bid.ext.prebid.rank

This issue would track only #2 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Community Review
Development

No branches or pull requests

1 participant