Reconciling proposals for more complex identity in OpenRTB 3.0

OpenRTB-3.0-IDs.markdown

Objectives of this Doc

Reconcile the known proposals for identity in OpenRTB 3.0.

Source Material

• OpenRTB 2.6/3.0 proposal: Person-based Identifier from LiveRamp
• OpenRTB 2.6 or 3.0 proposal: Cross-device matches from ShareThrough
• DigiTrust OpenRTB extension from DigiTrust

Use Cases We Should Solve

• Support for x-device models in bid-stream
• Allow for the ecosystem of "single IDs" (lol)

Differences

These three proposals are extremely similar but differ in two basic ways

1. Definition of what an ID represents (IDFA vs cookie)
2. Array vs single value

Questions

• Are these the right problems to solve and is it the right time to solve them?

• (2) is clearly necessary for the x-device use cases (many "users" will have multiple browsers or devices).

• Is (1) necessary or helpful in any way?

• The Sharethrough proposal calls for the inclusion of a make attribute ("Apple"). Is this useful in any way?

• What level of complexity are DSPs prepared to accept?

Suggestions

1. Call these eids rather than tpid. These may not necessarily be "third party IDs" ("tpid") at all. They are likely to be "first party" IDs which belong to the DSP but were sourced or linked by a technology provider.
2. Allow for an array of values by source.
3. Allow for extensions at the ID level rather than source.
4. Standardize the source value as a top-level domain without www.
5. Keep it simple.

Object Model

Field	Scope	Type	Default	Description
eids	optional	array	-	An array comprising various third party IDs for the user
eids.source	required	string	-	Source or technology provider responsible for the set of included IDs. Expressed as a top-level domain
eids.uids	required	array	-	Set of IDs from the given source.
eids.uids.id	required	string	-	Cookie or platform native identifier
eids.uids.atype	recommended	integer	-	Type of user agent the match is from. See agent types table.
eids.uids.ext	optional	object	-	Exchange-specific extension object

Agent Types

Type ID	Name	Description
1	Web	Web browser (on any physical device), would signal to expect a Cookie id - typically sent in the format of the buyer’s id previously determined via cookie sync.
2	App	In-app impressions, which will typically contain a type of device id (or rather the privacy-compliant versions of device IDs).
500+	Exchange specific

Example

"user": {
  "id": "aaa",
  "buyerid": "xxx",
  "eids": [
    {
      "source": "x-device-vendor-x.com",
      "uids": [
        { "id": "yyy", "atype": 1 },
        { "id": "zzz", "atype": 1 },
        { "id": "DB700403-9A24-4A4B-A8D5-8A0B4BE777D2", "atype": 2 } ]
    },
    {
      "source": "digitru.st",
      "uids": [
        {
          "id": "IPl4zj44Rhez/VyNE83bYfoz59H5GCIQrfCdAVyN51zcsme0faoH/qfLBijMQEazqGewXTZsMwMfZqwne8x4eAVeNmAx7iPpk7bpGYp71GUZyysbEEReDYEMJ2hNSldGTT9UExI62HvXuBM16X121r0i8Tko2Bps84tQFWb4lJeun/nRzYwj3ehUGjkE3UOxvHoplNqA43n25pRjgUkUVTR6i/UBWwD4C9dN0bXALC+grpTVLv5Vl4PJ4ir7twHLLow539N3ETb0cHt8GN+VweHBc2dGmqUTNQxGUZxBA21omEmotXpfqRKrHUo4fm/O9NFgYRN6W8LaCy3USy8dPQ==",
          "atype": 1,
          "ext": {
            "keyv": 4
          }
        } ]
    },
    {
      "source": "stat-id-vendor-z.org",
      "uids": [
        {
          "id": "0db20294a3908612bc7e732c2022095391074cf3",
          "atype": 1,
          "ext": {
            "confidence": 0.75
          }
        } ]
    }
  ]
}