ID match methods
ID match methods say how an extended identifier was tied to the user in this request: read directly, synced, matched on a login, observed first party, or inferred. OpenRTB 2.6 carries the value in EID.mm on each user.eids entry, alongside EID.matcher, which names the party that did the matching. Buyers use it to weigh how much to trust an ID before joining it to their own data.
Values
| Value | Name | What it means |
|---|---|---|
0 | Unknown | The match method is not known or not reported. |
1 | No Match | No matching took place: the ID came straight from a third-party cookie or the device's resettable advertising ID. |
2 | Browser Cookie Sync | The ID was matched through a real-time browser cookie sync between two platforms. |
3 | Authenticated | The match was based on user authentication, such as an email login or hashed personal data. |
4 | Observed | The match came from a first-party observation without authentication, such as a first-party cookie or local storage ID. |
5 | Inference | The match was inferred from signals such as IP address and user agent across browsers or devices, without authentication. |
500+ | Vendor-specific | Match methods defined by an ID provider or exchange and agreed with buyers outside the specification. |
Fields that use this list
How to use it
Set mm on every EID you add, and set it for the method actually used by the matcher, not for the ID provider's general product. EID.matcher may be left out when mm is 0, 1 or 2; for 3, 4 and 5 the buyer needs to know who did the matching, and when matcher is blank it is read as the same party as EID.source. EID.mm describes how the match was made, while UID.atype describes what kind of agent the ID belongs to (browser, app or person). They answer different questions, and buyers read both.
Common mistakes
- Copying one
mmvalue onto every EID. The method belongs to each ID source and each matcher, and differs between a device ID, a synced cookie and an email-based ID in the same request. - Sending 3 (Authenticated) for an ID that was resolved from IP address and user agent. That is 5 (Inference), and buyers who find out stop trusting the seller's labels.
- Leaving
EID.matcherempty for 3, 4 or 5 when the matcher is not the ID source. The buyer then credits the wrong company with the match. - Confusing
mmwithUID.atype. A person-based ID (atype3) can still be matched by inference, and a device ID (atype2) is normally 1 (No Match).
Validation
On OpenRTB 2.6 snapshots, RTBlint reports a value outside this list as openrtb.value.invalid. Paste a request into the tester to check the values you send.
Related lists
All lists are on the enumerated lists index.