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

Option to avoid passing floors to defined bidders #10410

Closed
bretg opened this issue Aug 29, 2023 · 9 comments
Closed

Option to avoid passing floors to defined bidders #10410

bretg opened this issue Aug 29, 2023 · 9 comments
Assignees

Comments

@bretg
Copy link
Collaborator

bretg commented Aug 29, 2023

Type of issue

Enhancement

Description

Through many rounds of A/B testing, Magnite has uncovered a general issue with setting floors via the Prebid floors feature -- some bidders perform notably worse on some accounts when a floor is set... these bidders actually bid lower with a floor. We don't know for sure why this is the case, but one hypothesis is that these bidders might have their own internal floor settings that are bypassed when there's a floor on the request. This makes sense since some SSPs provide user interfaces for their customers to manage floors.

Anyhow, one of the founding principles of Prebid Floors is that we are not allowed to send different floors to different bidders. However, publishers are not getting the best value from some of these bidders that have non-standard floor behavior. And it may well be that they've set up their floors in some SSP's user interface, so might not need Prebid to set the floor for that SSP.

So we would like to explore a compromise with the Prebid Community: update the Floors feature to allow configuration for whether to remove floor signaling before sending it to a particular bidder. i.e. we keep the "can't send different floor" rule with the caveat that Prebid could decide not to send a floor at all to certain bidders.

Anticipating the community reaction, we realize that not signaling the floor raises the question about whether such a bid should have the floor should be enforced even if it's not signaled. It's easy to argue either side of this question, so originally we proposed adding bidder-level floor config for both signaling and enforcement, but after community discussion, use cases covering exceptions for floor enforcement were removed.

Use Cases

  1. As a publisher, I want to define which bidders which should not receive floor signals because I've already entered floors for that provider in a different interface, or some other reason.
  2. As a floors provider, I want to define which bidders which should not receive floor signals because the data shows that setting a floor on that bidder results in lower bids.
  3. As an analytics provider, I need to know whether floor signaling was skipped for a bidder due to this configuration so I can monitor bidder performance.

Proposed Floors Extension

We propose that Floors Schema 2 should be extended to support configuration by either the publisher or the floors provider. So we would add 2 fields to the schema at 3 levels: top, data, and modelGroups.

  • enforcement.noFloorSignalBidders: ["bidderA", "bidderB", "bidderC"]
  • data.noFloorSignalBidders: ["bidderA", "bidderB"]
  • data.modelGroups[].noFloorSignalBidders: ["bidderA"]

Behavior

The order of precedence for choosing the config would be the same as for skipRate: data.modelGroups[CHOSEN], data, then enforcement. If a value is specified at a level, it defines the entire value -- there is no array merging. e.g. if noFloorSignalBidders is specified in both the data object and in the enforcement object, data would take precedence and enforcement.noFloorSignalBidders ignored.

noFloorSignalBidders - If a bidder is listed in the noFloorSignalBidders array, the system removes imp.{bidfloor,bidfloorcur} from the request for that bidder and the getFloors() call returns empty. If the skipRate skipped value is true, then noFloorSignalBidders has no effect. In debug mode, a short message should be emitted to the console when this control is activated: "noFloorSignal to bidderA".

No validation is done on either array to ensure every member is a valid bidder. If an unknown bidder is mentioned in either array, it will not cause any warnings. The arrays are utilized as lookups in precisely two places: determining whether to signal the floor to the current bidder and determining whether to enforce the floor for the current bidder.

Analytics adapters must have a way of obtaining the noFloorSignalBidders values actually utilized.

@dgirardi
Copy link
Collaborator

My reaction is that the proposed schema changes are a thinly veiled "floor buyer blacklist" to warn consumers about who doesn't behave well with floors. I think it'd be better to make that more explicit, and simpler, by adding a single list of bidders that by default shouldn't get floors, and keep all the rest in config.

This because we want those bidders to eventually behave better, and it seems odd to add a bunch of support for what's essentially a bug.

@bretg
Copy link
Collaborator Author

bretg commented Aug 30, 2023

single list of bidders that by default shouldn't get floors

Unfortunately it's not that easy. The data we have shows that sspA performs worse with floors for publisherX, but not necessarily for publisherY.

Again, our hypothesis is that some publishers have chosen to utilize an SSP-specific floor feature and others have not.

As discussed in committee, I will try to get permission to pull specific SSPs and publishers into discussions and share the data with them. The goal being to get confirmation of this hypothesis or alternate mechanisms.

@bretg
Copy link
Collaborator Author

bretg commented Sep 5, 2023

The investigation of this will take some time. What's become clear already is that different SSPs have different rules about what to do about multiple competing floors:

  • some prefer their internal floor
  • some will take the highest of available floors
  • it's likely that some may prefer the externally set floor

It is not likely that Prebid is going to be able to get 300 bidders to agree on a single way of handling multiple floors. It might be reasonable for us to work with the IAB to make a recommendation about a best practice and document metadata for who does what, but even if that happens, it could take a while (years) for everyone to align.

In the meantime, we still have the issue described above and would like a way to improve publisher revenue in the meantime.

An alternate solution to what's proposed above would be related to issue #10432 :

  1. add the feature to allow "bidder" to be part of the floor schema. This is giving up on our current rule and open the possibility of setting different floor values for each bidder.
  2. treat a "null" value for bidder as "don't send floor"

Personally, I prefer the original suggestion (noFloorSignalBidders), but would accept a community vote for to lift the current rule.

@robertrmartinez
Copy link
Collaborator

robertrmartinez commented Sep 8, 2023

Technically the price floors module already allows bidder to be part of the schema.

You can use the additionalSchemaFields hook to basically floor on anything you want.

I agree, explicitly allowing different floors to different bidders feels wrong.

If we are to support something like this, a list of bidders to not send floors to seems the best option.

Some reasons may be:

  • I have a setup with my SSP partner where I use their floors and don't want prebid floors to interact with them
  • I have agreed to not send them floors for some reason
  • A bug introduced by SSP has caused revenue to tank (only for them) when a floor is present

But I also totally understand the push back as well.

@patmmccann patmmccann moved this from Triage to Needs Req in Prebid.js Tactical Issues table Sep 11, 2023
@patmmccann
Copy link
Collaborator

@lcorrigall @jrosendahl do you have any written feedback?

@patmmccann patmmccann moved this from Needs Req to Ready for Dev in Prebid.js Tactical Issues table Oct 11, 2023
@bretg
Copy link
Collaborator Author

bretg commented Oct 16, 2023

After community discussion, exceptions for floor enforcement have been removed.

@patmmccann
Copy link
Collaborator

@bretg we have this marked as in progress; can you confirm magnite is working on this? I'm asking this on all in progress tickets to confirm accuracy.

@bretg
Copy link
Collaborator Author

bretg commented Dec 11, 2023

Confirmed. Not a committed timeline.

@patmmccann
Copy link
Collaborator

solved in #10867

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

No branches or pull requests

4 participants