Account specific fetchRate to select source of floors

[pm-jaydeep-mohite]

This proposal is for selecting source of floors i.e. fetched dynamically or from request req.ext.prebid.floors.

Issue

As per floors feature PRD https://docs.google.com/document/d/1YAt00RfQaU2Ugciqw1LnirLgjyUz9ibfyjfxWUHR_P0, If floors data is fetched successfully then it should be used and due to this fetched floors data will get used for 100% of the requests. There is no option to use fetched floors data for limited requests (e.g. 50%) and static floors data from req.ext.prebid.floors for remaining requests (i.e. 50%)

Proposal

We can have account specific fetchRate to select source floors from dynamically fetched data and from request. Range of valid values can be 0 to 100, 0 means do not use fetched data and 100 means use fetched floors data for all the requests. Default value : 0

[bretg]

PRD updated with fetch.use-data-rate feature. https://docs.google.com/document/d/1YAt00RfQaU2Ugciqw1LnirLgjyUz9ibfyjfxWUHR_P0/edit#heading=h.yglzagui7gzp

[pm-jaydeep-mohite]

Can we have some field in floors JSON to control source of floors i.e. req.ext.prebid.floors.dataRate ?

This would help in updating data rate through dynamically updated floors data, consume updated dataRate dynamically and no need to update account config as per updated floors data. If no value provided for req.ext.prebid.floors.dataRate would be considered as 100 (default value), and based on valid value (0-100) source of floors shall be selected.

Having data-rate at account config and floors data would be same as existing enforceRate field.

[bretg]

@pm-jaydeep-mohite - sorry, I'm not following. You want both dataRate and fetchRate? This feature is already complicated as it is. Please simplify and propose a minimal working solution for your use case.

[pm-jaydeep-mohite]

In current PRD version, we have dataRate which is account level config parameter. and dataRate should be adjusted based on stability/confidence of dynamically fetched floors data generator. Suppose, if floors provider is confident to use dynamically fetched floors for 100% (from 5%) of traffic then floors provider can intimate in floors JSON than prebid server maintainer updating account config to change it to 100 (from 5). To avoid this manual process of updating dataRate in account configuration, we can have dataRate as part of floors data i.e. req.ext.prebid.floors.dataRate so that dynamically fetched floors can update this value based on confidence of floors provider.

If the value of dataRate is not provided then default value 100 shall be considered to be backward compatible. Field dataRate should be considered only from dynamically fetched floors data and in case of floors data provided in req.ext.prebid.floors, dataRate should be ignored

[bretg]

Thanks, but I'm going to push back on this as overly complicated. If fetchRate is a publisher control that essentially indicates they don't fully trust the provider, then it doesn't make sense for the provider to be able to override that.

This floors feature is already stupendously complicated and having two interacting flags adds a bunch of edge cases that would require documentation and testing.

[pm-jaydeep-mohite]

In this case we can eliminate one flag from account level config and keep only field from floor data. This can be added as optional/advanced feature to avoid process of updating dataRate in account configuration based on dynamically floors recommendation performance.

[bretg]

I'm going to challenge you a bit more on this. The feature doesn't seem useful to me.

I get why a publisher might want to ease into fetched data, but why would a floors provider say "Only use my data X% of the time." ? It seems similar to "skip rate". How would analytics know which data is used? How would a floors provider know when to change this value?

[pm-jaydeep-mohite]

1. floors provider say "Only use my data X% of the time." in testing phase and during this phase they want to ensure that static floors getting used from req.ext.prebid.floors. Skip rate would not help as whenever dynamically fetched floors JSON is used and floors signalling is skipped due to SkipRate then neither dynamic floors nor static floor would get used in such skipped requests.

2. Analytics would know source of floors from selected floorRule.

3. Floors provider would be using feedback mechanism for floor recommendations, based on positive or negative impact in cpm provider could adjust data-rate.

[bretg]

Very well. The analytics adapter could use ext.prebid.floors.location to tell whether 'request' or 'fetch' floors were used.

• updated the PRD to remove the account-level 'use-data-rate' and replaced it with data.useFetchDataRate
• updated the published "Schema 2" with the new optional data.useFetchDataRate

Please review both documents to make sure this is what you want. Would prefer not to have make another round of changes here.

[bretg]

Can we close this issue @pm-jaydeep-mohite ?