request.user.eids should not require unique sources

[patmmccann]

A request with non-unique eids sources generates error "Invalid request format: request.user.eids must contain unique sources"

https://github.com/prebid/prebid-server-java/blob/eefe82b27fc3fd625b9dedff99c5586f76001c8b/src/main/java/org/prebid/server/validation/RequestValidator.java#L353

There are a variety of use cases for non-unique sources:

eg https://github.com/prebid/Prebid.js/blob/4c2902f36759476482e4a0f9ab482e569b0efb7a/test/spec/modules/pairIdSystem_spec.js#L48

a single source could have multiple atypes (eg a person or a device identifier)

A single source, eg adserver.org, may have different ids with different ext.rtipartner.

We'd like to make this validation account level opt in or remove it altogether, or perhaps change it to be more nuanced.

[bretg]

Discussed in committee. Essentially, PAIR treats EIDs as if source is not a primary key for the EIDs array. However, the IAB spec indicates that there should be a single source. Putting this on hold while additional discussions take place.

[dgirardi]

However, the IAB spec indicates that there should be a single source

which spec, and where?

[bretg]

I can't find the specific doc that @SyntaxNode was sharing this morning, but this is similar: https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/extensions/2.x_official_extensions/eids.md

It's pretty clear from the design of the object that the IAB intended the source field to be a primary key. If there are different UIDs with different atypes, fine, use the fact that uids is an array.

instead of

user.eids: [{
   source: "a",
   uids: [{
     id: "1",
     atype: 1
   }]
},{
   source: "a",
   uids: [{
     id: "2",
     atype: 2
   }]
}]

The way the IAB would suggest representing would be to combine the uids into the one source object.

user.eids: [{
   source: "a",
   uids: [{
     id: "1",
     atype: 1
   },{
     id: "2",
     atype: 2
   }]
}]

[dgirardi]

If there are different UIDs with different atypes, fine, use the fact that uids is an array

My understanding is that server now does not allow this. IMO the ORTB spec does. Edit: I misunderstood - atype is not a problem since it's in the sub-object. Different values under ext would be, but I'm not sure if there's a use case for it. Either way I don't think the ORTB spec requires grouping uids by source.

It's pretty clear from the design of the object that the IAB intended the source field to be a primary key

I disagree. The field is not even marked as required in any version of the spec I can find. If we are to take hints on what should be unique from the structure of the objects, you could make the same argument for user data, which is essentially the same structure with the same lack of remarks on field uniqueness or optionality. Yet from my testing server accepts repeated values for both id and name (which, again, is correct is in my opinion).

[bretg]

Scott was just looking at the ORTB 2.6 spec which says

3.2.27 Object: EID

Extended identifiers support in the OpenRTB specification allows buyers to use audience data in
real-time bidding. This object can contain one or more UIDs from a **single source** or a
technology provider. The exchange should ensure that business agreements allow for the sending
of this data.

This is vague, but anyhow, it has been interpreted by Prebid Server as being a validation.

If the community wants PBS to stop doing this validation, it will be done.

[dgirardi]

If this is just validation I think it's an easy decision - it should be relaxed.
If the validation is also an assumption made by internal server APIs - for example if modules expect there to be one EID per source - then I'm OK with kicking this can down the road until we have a use case.

[bretg]

Discussed in committee - we will relax this validation.

[bretg]

Validation removed in PBS-Java 2.4

[SyntaxNode]

Implemented in PBS-Go v2.15