Agent types
Agent types say what kind of user agent an extended identifier belongs to: a browser or single device, an app with a device ID, or a person across devices. OpenRTB 2.6 sends the value in UID.atype on each user.eids[].uids[] entry. Many DSPs keep app IDs and browser IDs in separate graphs, so a missing atype can stop an ID from resolving.
Values
| Value | Name | What it means |
|---|---|---|
1 | Browser or device | An ID tied to one browser or device, whether cookie-based, probabilistic or otherwise. |
2 | In-app | An ID from app traffic, usually a privacy-compliant form of the device advertising ID. |
3 | Person-based | An ID meant to identify the same person across devices. |
500+ | Vendor-specific codes | Vendor-specific agent types agreed between the parties. |
Fields that use this list
How to use it
Set atype on every UID, even though the field is optional. Choose it by what the ID identifies, not by where the request came from: a person-based ID in an app request is still 3. UID.atype describes the ID itself, while EID.mm describes how the seller matched it, and buyers read the two together. Values 500 and above are vendor-specific.
Common mistakes
- Omitting
atype. The specification strongly recommends it because buyers route IDs by type. - Labeling an ID derived from a hashed email as 1. If it is meant to be the same across devices, it is 3.
- Labeling a mobile advertising ID as 1 instead of 2.
- Using
atypeto say how the ID was matched. That isEID.mm.
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.