Closed github-maxime-liege closed 6 months ago
@alexsavelyev and @YuriyVelichkoPI can you look this over? I am a bit unfamiliar with what is going on here.
Hi @github-maxime-liege !
I think it makes sense to implement it in the following way. The plugin can put the supported api
values into the data
field using:
https://docs.prebid.org/prebid-mobile/pbm-api/android/pbm-plugin-renderer.html#take-advantage-of-the-plugin-renderer-fields
And the PBS adapter can enrich the bid request to the demand partner with the provided values.
In this case, the plugin will signal the exact supported api
s to the particular adapter. And adapter will transfer these values into the request body. So adapter shouldn't manage the map of supported api
s for each plugin's versions.
https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf
5.6 API Frameworks The following table is a list of API frameworks supported by the publisher. Value Description 1 VPAID 1.0 2 VPAID 2.0 3 MRAID-1 4 ORMMA 5 MRAID-2 6 MRAID-3
The pull request is being closed because we will follow Yuri's suggestion
Context
Using the new feature Prebid PluginRenderer, while doing some test, i encountered a problem where the delivery were not filled because of the incorrect api frameworks provided
Indeed, by default, Prebid Renderer does not offert the 2 api frameworks 1 and 2 which refers to VPAID 1.0 and VPAID 2.0
Proposal
Adding a new method to the PluginRenderer contract by allowing the SDKs to provide their ApiFramework inside the bid request, it will concat everything into the banner bid request.
Remaining Problem
Every provided APIs remains on the same level for every renderers, which is a problem if a SDK win but not compatible with an API used on the winning ad.
Question
Should it be on the adapter level on Prebid Server in the end ? knowing that this value is a pure rendering value and should normally be kept by the SDK that will render.