Closed YuriyVelichkoPI closed 3 months ago
Interesting problem @YuriyVelichkoPI .
Now that we have module capability, I'd like to propose that the Prebid Mobile committee could own a module that's entirely responsible for rectifying issues like this. You could imagine a "Prebid Mobile Adjustments" module that just does the specific things you guys need. No need to generalize into 'rewrite_config_ids'. Just have the module do the exact things it needs.
As you guys add the behaviors to the module, PBS host companies automatically get the update when they upgrade.
This is easier for everyone:
Closing this issue - will open a separate issue for a Prebid Mobile Adjustments module.
There's also a suggestion to move existing mobile-specific functionality like the IDFA hack into this module.
Motivation
Fix hardcoded client errors in requests.
Background
One of the biggest issues with mobile SDKs is their release cycle. Once it reaches the user's device, the particular SDK version can stay there forever.
Here is an example of a long-lived bug that leads to marking valid traffic as IVT: https://github.com/prebid/prebid-mobile-ios/issues/932. The SDK already has a fix, but not all users are updated to the latest version.
The error is obviously on the SDK side, but there is no way to fix it and restore monetization.
Objectives
PBS can introduce functionality that allows rewriting some parts of the request due to the stored rules.
For instance, PBS can introduce an additional object that the publisher can add to the stored request like
ext.prebid.rewrite_config_ids
, which will be an array of stored configs. The config will contain the following objects:ext.prebid.source
is equal to "prebid-mobile" andext.prebid.source
like2.*.*
.device.id
field.In both cases, the configs should contain the RTB key and the search or replacement rule, most probably in the form of regex.
The Rewrite module should read this config, detect whether a request is an object for replacement (meet the condition), and apply the rewrite rule.
Of course, the above description is highly general and serves as an entry point for the discussion. If someone considers such a feature valuable, I'll work on specification details.