prebid
Prebid Server should concat, not discard, user.ext.eids when user.eids is also present
As a publisher, I want Prebid Server to concatenate user.eids and user.ext.eids, so that IDs in the ext are not excluded in bid requests where some IDs exist in both locations.
At Optable, we have observed a scenario where a publisher works with a vendor that is populating an array of eids into user.ext.eids, but these eids are rejected by server when the publisher begins populating other IDs into user.eids. This can result in a decline in monetization where the values in user.ext.eids are providing tangible revenue uplift.
To support efforts to upgrade ID signals in the bidstream to the 2.6 standard (with provenance fields), while maintaining backwards compatibility with 2.5, Prebid Server should concat (without trying to dedupe or validate) rather than discarding the 2.5 values.
cc @bretg
when the publisher begins populating other IDs into user.eids
this is the mistake, the publisher should write to user.ext.eids; prebid.js hasnt upgraded off the ext field. we don't usually like moving things around. same with schain.
the publisher should write to user.ext.eids
Nothing prevents a publisher from inserting to what is the current oRTB version location for eids. Regardless, PBS should not be discarding what is in ext.eids when they do.
@mark-dixon - we discussed in the PBS committee - can you see a Prebid.js-based solution working for you here?
If PBS doesn't perform deduplication, there might be a situation where we have EIDs with duplicate sources with different UIDs or other attributes, so it shouldn't be a simple concatenation on the server side.
Appreciate the input @linux019 , but that opens the problem of which duplicate to accept. PBS is not going to get in that business. IMO, it should be either simple concatenation or nothing. Let something else decide the edge cases.
@bretg sorry to have missed the discussion in PMC yesterday, as I was out attending an event. I'm not clear on what a Prebid.js solution would look like or how would it solve what I see as the root issue... that PBS is discarding what should be considered valid fields.
WIth PBS doing upgrading/downgrading of requests by oRTB version, shouldn't a 2.6 request still maintain the ext locations (so there could be eids in both user.eids and user.ext.eids)? Downgrading for a 2.5 bid adapter is where I could see the concat happening in user.ext.eids.
@linux019 eids for the same source do exist in the same request, especially in cases where a publisher may work with one or more vendors, perhaps using different match methods. This is also why the oRTB 2.6 provenance fields need to become an adopted standard, so there is transparency on where and how the IDs are being generated. The provenance fields can then inform decisioning on which values an upstream bidder chooses to accept.
the root issue... that PBS is discarding what should be considered valid fields.
A talented debater could take an alternate stance. :-)
what a Prebid.js solution would look like
Just have the pbsBidAdapter deal with merging the EIDs.
So the question to you @mark-dixon is: what is your source of EIDs -- is it always sourced via Prebid.js? Or is there a mobile app component? Or a custom caller?
@bsardo what was the final resolution on this issue during the committee discussion? We decided to leave the implementation to Prebid.js as per this issue: https://github.com/prebid/Prebid.js/issues/13006 . Did I remember it right?
@Net-burst yes that's correct. The committee is in agreement that we add the concatenation logic upstream in PBJS rather than in PBS. https://github.com/prebid/Prebid.js/issues/13006 is the related issue. @mark-dixon indicated that his issue has been resolved through other means. There was some concern as to whether PBS notifies the publisher in any way when the 2.5 location is dropped due to the presence of data in the 2.6 location. I will check on that while @mark-dixon gathers more information on how the issue surfaced at Optable.
Let's document this discarding behavior when both 2.5 and 2.6 eids are present. Maybe it is general to any data that can come in a different location for 2.5 and 2.6. A related documentation issue: https://github.com/prebid/prebid-server/issues/4312
I'm keeping this open until we actually document this. Looks like Prebid.org lack documentation about up/down-conversion between different OpenRTB versions.