What does User-Agent deprecation mean for OpenRTB?
Short answer
The User-Agent header was not removed; it was frozen. Chrome's UA reduction replaced the informative parts of the string (exact browser version, platform version, device model) with fixed placeholder values, so parsing device.ua now yields stale or generic answers. OpenRTB 2.6 added device.sua, a structured UserAgent object populated from User-Agent Client Hints headers, carrying browser brands and versions, platform, mobile preference, architecture, bitness, and model as separate fields. When both are present, the spec says to trust sua and ignore ua.
What was actually deprecated
The phrase “User-Agent deprecation” describes an information reduction, not a removal. Chrome rolled out UA reduction between 2022 and 2023: the browser version in the string is frozen at the major version (a Chrome 138 string reads Chrome/138.0.0.0), the reported platform version no longer moves, and the Android device model is replaced by the single letter K. Safari froze parts of its string years earlier. The header still arrives on every request and exchanges still copy it into device.ua; it just answers fewer questions than it used to.
For a bidder that means any pipeline still deriving device type, model, or exact browser version by parsing device.ua is consuming placeholder values on a large share of traffic and treating them as measurements.
The structured replacement: device.sua
Browsers that reduced the string expose the same information through User-Agent Client Hints: low-entropy headers (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) sent by default, and high-entropy headers (full version list, model, platform version, architecture, bitness) available on request. OpenRTB 2.6 added device.sua, a UserAgent object that carries those values as structured fields instead of a string to parse:
| Field | Type | Populated from |
|---|---|---|
browsers | array of BrandVersion | Sec-CH-UA-Full-Version-List: each entry is a brand plus a version array in descending order (major, minor, micro) |
platform | BrandVersion | Sec-CH-UA-Platform and Sec-CH-UA-Platform-Version |
mobile | integer | Sec-CH-UA-Mobile: 1 if the agent prefers mobile-optimised content |
architecture, bitness | string | Sec-CH-UA-Arch and Sec-CH-UA-Bitness (high entropy) |
model | string | Sec-CH-UA-Model: the real device model the reduced string no longer carries |
source | integer, default 0 | How this object was built (see below) |
sua has been part of the Device object since the first OpenRTB 2.6 release. The blog post on the sua object walks the history in more detail.
What the spec tells each side to do
The 2.6 Device definition is explicit in both directions. Exchanges should keep populating ua with the raw User-Agent string whenever the device provides one, for backwards compatibility, and should never put an inferred or approximated string there. Bidders should do the opposite of the old habit: when both fields are present, rely on sua for device and browser detection and ignore ua, because the string may be frozen or reduced while the structured object is not.
sua.source is the data-quality label
| Value | Meaning | What it implies |
|---|---|---|
| 0 | Unspecified or unknown | No provenance claim at all |
| 1 | Client Hints, low-entropy headers only | Brand, platform, and mobile flag are real; no model or full version |
| 2 | Client Hints with high-entropy headers | The richest case: full version list, model, architecture |
| 3 | Parsed from the User-Agent string | Inherits the reduced string's placeholders; treat with the same suspicion |
The values come from the AdCOM User-Agent Source list. A sua with source: 3 on Chrome traffic is a repackaged reduced string, not new information, which is why the field is worth reading before trusting the rest of the object.
Checking what your requests actually say
Paste a live bid request into the tester to see how the device object validates, and use the bid request reference for the surrounding fields. Consistency is worth a manual look too: a request whose sua.mobile says desktop while devicetype claims a phone is telling you one of its sources is stale.