-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
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. |
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. |
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:
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 :
Personally, I prefer the original suggestion (noFloorSignalBidders), but would accept a community vote for to lift the current rule. |
Technically the price floors module already allows You can use the 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:
But I also totally understand the push back as well. |
@lcorrigall @jrosendahl do you have any written feedback? |
After community discussion, exceptions for floor enforcement have been removed. |
@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. |
Confirmed. Not a committed timeline. |
solved in #10867 |
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
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.
Behavior
The order of precedence for choosing the config would be the same as for skipRate:
data.modelGroups[CHOSEN]
,data
, thenenforcement
. 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 thedata
object and in theenforcement
object,data
would take precedence andenforcement.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.
The text was updated successfully, but these errors were encountered: