Guides

OpenRTB user identity: eids, buyeruid, and the cookieless transition

Identity is the most contested part of a bid request. A buyer wants to recognize a user; privacy rules and the decline of third-party cookies keep changing what it is allowed to see. OpenRTB carries several identity mechanisms at once, from a legacy cookie-synced ID to the modern extended-identifier array. Here is what each field is and how they relate.

The legacy mechanism: user.id and buyeruid

The User object has carried identity since the earliest OpenRTB versions through two fields:

user.id: the exchange's own identifier for the user.
user.buyeruid: a buyer-specific ID, mapped by the exchange for a particular buyer. Unless the two parties arranged it directly, this value comes from a cookie sync, the ID-matching process described in the spec's Appendix on cookie-based syncing.

This model depends on third-party cookies and match tables, exactly the plumbing that has been eroding across browsers. That is why the extended-identifier model exists.

The modern mechanism: user.eids

user.eids is an array of Extended Identifier (EID) objects, each grouping one or more IDs from a single source. It is the standard way to carry third-party and first-party identity solutions (the various universal ID initiatives) in a single structured field instead of a tangle of extensions. Each EID carries:

source: the canonical domain of the ID provider, so a buyer knows which identity system a value belongs to.
uids: an array of UID objects, each with an id (the actual identifier) and an atype (the agent type the ID came from, a browser versus an app-native context, which DSPs need for resolution).
inserter, matcher, and mm: provenance fields that record who added the ID to the array and by what match method, so a buyer can reason about how trustworthy a match is.

"user": {
  "eids": [
    {
      "source": "idprovider.com",
      "uids": [
        { "id": "a1b2c3d4", "atype": 1 }
      ]
    }
  ]
}

Why the shift matters

Cookie-synced buyeruid is tied to the browser cookie and the exchange's match table; when third-party cookies go away, so does that ID. Extended identifiers are deliberately source-agnostic: a universal ID, a hashed-email-based ID, or a publisher-provided ID all travel the same way in eids, tagged by source so the buyer knows what it is looking at. The bid request format did not have to change per identity vendor; they all fit the same object.

Identity does not override privacy

None of these fields exists in isolation from consent. Whether an exchange may send an ID at all depends on the regulatory signals in the request, and sending identity without the consent to back it is a compliance problem, not just a data one. The exact paths for regs.gdpr, user.consent, GPP, and US Privacy are in the privacy signals reference. Treat identity and consent as a pair.

Common mistakes

eids in an extension. It is a first-class user.eids array, not user.ext.eids. Buyers reading the standard path miss IDs stuffed inext.
Missing atype. Many DSPs require the agent type to resolve an ID; omitting it can make an otherwise valid ID unusable.
Unnamed source. An ID with no source domain is unmatchable; the buyer cannot tell which system it belongs to.

Validate the identity block

Paste a request with a user.eids array into the tester to check structure and paths, or run the CLI over sampled traffic. Identity errors are silent: a misplaced or malformed ID just fails to match and lowers your bid density with no error.