Support For OpenRTB 2.6-202409

[bretg]

OpenRTB 2.6-202407 contains a few of additions to OpenRTB that Prebid Server should support in the JSON schema validation.

InteractiveAdvertisingBureau/openrtb2.x#103

• user.eids[].inserter - string
• user.eids[].matcher - string
• user.eids[].mm - int

No special logic or validations. When an eids object is passed to a bid adapter, these are just additional data. If an eids object is removed for any reason, these values would be removed with it.

[SyntaxNode]

The changes to the EID object as part of OpenRTB 2.6-202407 (not yet merged) is designed to provide sellers with better clarity on the buyeruid. This ID Generation Provenance and Clarification IAB article discusses the objective, also known as ID Bridging.

There is new logic needed in Prebid Server to support this objective. When the buyeruid is inserted by Prebid Server as the result of cookie syncing (from the PBS cookie), Prebid Server is expected to add a new eid object with the inserter and (likely) matcher identifying the host company and mm (match method) set to 2 / Browser Cookie Sync. This duplicates the buyeruid value in the request, but the long term preference is to deprecate buyeruid.

The inserter should match the host company's ads.txt domain. I'm less certain on if it's appropriate or necessary for Prebid Server to set the matcher.

[bretg]

Note: as discussed on Friday, split out OpenRTB 2.6-202402 into a separate issue.

[bretg]

Discussed in committee. There's an open question about how we should set eid.source -- all we have is the cookie family (normally biddercode), not a domain.

We propose add a new field to the YAML file to specify:

    usersync:
      cookie-family-name: bidderA
      eids-source: bidderA.co.uk
      iframe:
        url:
      redirect:
        url:

If eids-source isn't specified, it defaults to URLSYNCBASEDOMAIN, which would be the eTLD+1. e.g. if the iframe is sync.foo.co.uk/sync?blah, then the source would be foo.co.uk.

An example:

  "user": {
      "eids": [
        {
          "source": "CONFIGURED-EID-SOURCE or URLSYNCBASEDOMAIN", 
          "inserter": "hostcompany.com",
          "mm": 2,
          "uids": [
            {
              "id": "ID-FROM-UIDS-COOKIE",
              "atype": 1
            }
          ]
        },

Finally, we would want to add an opt-in configuration, e.g. cookie-sync.add-to-eids. The addition of the eid would only happen if this config is true -- the default is false.

[bretg]

This was discussed in the identity committee last week. We changed the proposed default from BIDDERCODE.com to being derived from URLSYNCDOMAIN

[bretg]

@patmmccann - do you have a sense for what's worse here: the wrong eid.source or no entry at all?

[bretg]

Looking to move this to ready-for-dev

[bretg]

Also adding @jdwieland8282 - would like to bring this one to a conclusion.

[jdwieland8282]

The identity committee believes that it is not necessary to copy the output of a traditional user sync to the eids array. Identifiers derived from a user sync may continue to be used in the user.buyeruid.

[bretg]

As the Identity Committee suggests, this issue now just tracks expanding the schema to allow these new fields.

They also noted that interested community members could build this if they insist -- the technical details of the proposal are ok but that PBS Host Companies would require opt-in configuration for whether the EIDs were added.