-
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
Adapters preferring site.content.id for ecid #10861
Comments
Summary of Prebid 9 changes: Change jw player as documented Prebid.js/modules/jwplayerRtdProvider.js Line 87 in ef42add
Gumgum shouldn't need to take iris id as a param, it is in the ecid object, they can support both. |
@MartinGumGum this might be helpful.... If not we'll be deleting iris support in your 9.0 adapter. function getCids(site) { // Example usage: const cids = getCids(site); |
Proposal to update the ORTB spec to have |
Removing 9 flag as jw and gumgum changes are now pr'd on the 9.0 branch |
@patmmccann I'm preparing the suggestion provided above and fixing the Unit test. Please let me know how we will be affected and how critical this is. |
currently i've deleted your iris functionality from the 9.0 branch, i can revert that pr on 9 if you have a fix. We're looking to release this week or early next. |
@patmmccann what's the next step on this? are we waiting for someone to take action? |
The main purpose of this issue is to shame Index exchange and Microsoft and Magnite and Pubmatic into better standards adherence. |
Type of issue
Widespread bad practice
Description
When a bid adapter prefers site.content.id or an RTD module fills it in, that crowds out other designations of the content id. For example jw player boost module and iris may each have their own content identifier, but that isn't supported in this field as there is no room for collisions. If Prebid lets RTD modules fill in this field, it would result in a race and modules or entities affecting each others' monetization. Configuration may be getting blown away or modified in unpredictable ways.
Known issues: Index exchange ( https://prebid.slack.com/archives/C02C5BW8LGN/p1691768324940859 ) and Microsoft ( https://support.iris.tv/xandr-monetize-passing-contextual-data ) and Magnite ( https://support.iris.tv/magnitectv-passing-contextual-data ) and Pubmatic https://support.iris.tv/pubmatic-passing-contextual-data . The incorrect documentation for pubmatic there which passes ids on dctr param might have been fixed already in #9142 but remains in the wild.
Proposal, if prebid detects an rtd module or publisher filling in site.content.id with a pattern that looks like an iris identifier, it moves it to the correct place site.content.data.ext.cids. Also, we ask iris to please stop distributing documentation with content identifiers in the wrong place. Iris appears to be intentionally claiming this field to the exclusion of others in the community, as they sponsored the below proposal but continue to guide publishers to the legacy field.
https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/extensions/community_extensions/extended-content-ids.md
It seems Iris is comfortable with the correct location for Gumgum server side connections https://support.iris.tv/gumgum-ssp-passing-contextual-data but client side they recommend it as a parameter.
This mess is a great example of the most frequent publisher complaint we receive as a library, enormous variation in configuration to pass the same information to each partner. As such this param is a rules violation:
Prebid.js/modules/gumgumBidAdapter.js
Line 371 in cd787eb
Related: #9142
The text was updated successfully, but these errors were encountered: