Skip to content
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

Open
patmmccann opened this issue Dec 19, 2023 · 10 comments
Open

Adapters preferring site.content.id for ecid #10861

patmmccann opened this issue Dec 19, 2023 · 10 comments

Comments

@patmmccann
Copy link
Collaborator

patmmccann commented Dec 19, 2023

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.

image

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:

if (params.irisid && typeof params.irisid === 'string') {
, as are potentially the Microsoft perids as a documented workaround.

Related: #9142

@patmmccann
Copy link
Collaborator Author

Summary of Prebid 9 changes:

Change jw player as documented

// TODO: Prebid 9 - replace with ENRICH_WHEN_EMPTY

Gumgum shouldn't need to take iris id as a param, it is in the ecid object, they can support both.

@patmmccann patmmccann moved this from Blocked to Ready for Dev in Prebid.js Tactical Issues table May 9, 2024
@patmmccann patmmccann moved this from Ready for Dev to Tracking in Prebid.js Tactical Issues table May 28, 2024
@patmmccann
Copy link
Collaborator Author

@MartinGumGum this might be helpful.... If not we'll be deleting iris support in your 9.0 adapter.

function getCids(site) {
// Check if site.content and site.content.data are defined and are arrays
if (site.content && Array.isArray(site.content.data)) {
// Iterate over each data object
for (const dataItem of site.content.data) {
// Check if dataItem.name contains 'iris.com' or 'iris.tv'
if (dataItem.name.includes('iris.com') || dataItem.name.includes('iris.tv')) {
// Return the cids if the condition is met
return dataItem.ext.cids;
}
}
}
// Return null if the condition is not met or the structure is incorrect
return null;
}

// Example usage:
const site = {
content: {
data: [{
name: 'www.iris.com',
ext: {
segtax: 500,
cids: ['iris_c73g5jq96mwso4d8']
}
}]
},
page: 'http://pub.com/news',
ref: 'http://google.com',
publisher: {
id: 'p10000',
domain: 'pub.com'
}
};

const cids = getCids(site);
console.log(cids); // Output: ['iris_c73g5jq96mwso4d8']

@karimMourra
Copy link
Collaborator

Proposal to update the ORTB spec to have content exist in the video impression as well, to accommodate for multiple contents being rendered simultaneously on a page. site.content just doesn't scale well
InteractiveAdvertisingBureau/openrtb2.x#102

@patmmccann
Copy link
Collaborator Author

Removing 9 flag as jw and gumgum changes are now pr'd on the 9.0 branch

@MartinGumGum
Copy link
Contributor

@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.

@patmmccann
Copy link
Collaborator Author

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.

@dgirardi
Copy link
Collaborator

@patmmccann what's the next step on this? are we waiting for someone to take action?

@patmmccann
Copy link
Collaborator Author

patmmccann commented Nov 4, 2024

The main purpose of this issue is to nudge Index exchange and Microsoft and Magnite and Pubmatic into better standards adherence.

@robhazan
Copy link

@dgirardi - At today's Programmatic Supply Chain Working Group, we proposed moving Extended Content IDs from Community Extension to Provisional attribute in OpenRTB (which effectively mainlines it). Once that exists as a codified standard, then I think we just nudge folks to use it, as Pat said.

@robhazan
Copy link

Wrote up a proposal here for mainlining the Extended Content IDs concept. IAB Tech Lab members should be able to review and comment on that doc. If you're a member and don't have access to the doc, please reach out to Hillary Slattery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Tracking
Development

No branches or pull requests

5 participants