IAB OpenRTB 2.6 and DeviceAtlas support

The IAB OpenRTB 2.6 release – the SUA object

The most recent revision of the IAB OpenRTB release, 2.6, has been widely communicated. A key benefit of the release is support for ad podding, for example. The purpose of this post is to provide more detail on a less well-publicized update in OpenRTB 2.6: the addition of the SUA object in the Device Object and its purpose.

For background, the Device Object is an important component of the OpenRTB model, since it provides for communication of the characteristics of the end user device originating the impression. This is where DeviceAtlas plays a role: it enables exchanges to populate the Device Object and enables DSPs to interpret or extend the device information in it, for targeting and ad serving purposes.

The SUA Object is the means by which User-Agent Client Hints are communicated as part of the Device Object, to supplement the user-agent string as the identifier of the device model, OS and browser.

User-Agent Client Hints background

Google have been working for some years to provide additional contextual information about the client and its capabilities to web servers; this is its Client Hints initiative, which is manifested as additional parameters in headers and JavaScript contexts. Until last year, these Hints were an addition to the HTTP specification, and hence represented added value. Examples are provision of Round Trip Time, Effective Connectivity Type, Save-Data status.

More recently, Google introduced a new variation on the initiative, by introducing what it terms User-Agent Client Hints. These contain information traditionally included in the user-agent string, and, invoking privacy as the rationale, Google reduced the information available in the Chrome and Chromium user-agent string, placing the information instead in Client Hints. Since Chrome 110, user-agent strings appear as below (green highlights reflect frozen elements)

There are two types of Hints: low entropy and high entropy. The low entropy hints include browser name, OS name, Mobile identifier. The high entropy hints, which require a second request, include the device model, the OS version, and browser minor and patch versions. In order to resolve the device, OS and browser information fully, it is therefore necessary to capture and process the low entropy and high entropy hints, where before it was sufficient to just parse the user-agent string. Hence the environment has materially increased in complexity since it continues to be necessary to parse the user-agent string for all non-Chromium and non-Chrome traffic, while also parsing the multiple hints required in Chrome and Chromium browsers.

Impacts on web ecosystem

The main impacts of the changes are manifested in three ways:

• Increased complexity, leading to higher friction and ultimately reduced overall understanding of traffic, limiting the ability to cater to diverse device owners
• Reduced performance, since it becomes necessary to add a round trip in order to understand the nature and capabilities of a device or browser
• Reduced monetization, since the ability to target by device is restricted.

Open RTB 2.6 solution

An important addition to the IAB OpenRTB 2.6 specification is the SUA Object in the Device Object. This carries a representation of the hints available from the client, albeit in a different format to hints retrieved from the headers or via JavaScript. (This necessitates handling a third method of parsing hints)

Since the UA string in the device object will only suffice for a reducing proportion of traffic, the SUA object needs to be populated by exchanges to enable downstream DSPs to fully understand the nature of the impression, for example to identify if it is a match with an advertising campaign, or to support delivery of appropriately-tailored creative.

For the exchange or SSP to be able to populate the SUA object, they in turn need to be able to capture the Client Hints from the publisher via their publisher integration. The user-agent string is no longer enough.

If exchanges do not move to OpenRTB 2.6, or do not populate the SUA object, downstream DSPs have an incomplete understanding of the impression, which can be expected to reduce the number and value of bids on average.

Hence in order to ensure continuity of ad revenues, publishers, exchanges and DSPs need to cooperate to capture, make available and leverage Client Hints respectively. This requires adoption of OpenRTB 2.6 as a foundational step.

DeviceAtlas support for Client Hints

DeviceAtlas provides the ability to reliably parse HTTP headers and identify the device model, OS and browser originating the request. It used to be the case that the user-agent string was, for the most part, sufficient. However, with the Google changes, it is necessary to factor in the Client Hints headers also. DeviceAtlas released an update in 2022 to enable its customers to ensure continuity of functionality in the new landscape, and it is now in widespread use. In the OpenRTB ecosystem, DeviceAtlas is used by SSPs, exchanges, DSPs, DMPs and ad servers. This is in addition to its usage by publishers (to optimize content in real time) and analytics platforms (to provide deep insights on end user devices to their customers).

DeviceAtlas updates its data daily to fully reflect the rapid emergence of new connected devices in the landscape.

Sample code, resources

Since it is vital that the interpretation of the SUA object is consistent between the SSP (who populate the SUA object) and the DSP (who read the SUA object), the following code samples are provided by DeviceAtlas for the use of SSPs and DSPs:

1. SSP – write to OpenRTB 2.6 SUA object from HTTP Headers
2. SSP – write to OpenRTB 2.6 SUA object from JS-originated Client Hints
3. DSP – read from OpenRTB 2.6 SUA object and convert to Headers format appropriate for use with DeviceAtlas APIs.

A further JavaScript code sample is provided, for use by publishers to capture Client Hints via JavaScript. This might be a useful sample for exchanges to share with their publisher partners, or for use as part of their own integrations. Description and snippet here.

Summing up

The visible manifestation of the changes introduced by Google is that if businesses do not update how they interact with traffic, or support OpenRTB 2.6, a progressively increasing proportion of Android traffic will be for unknown devices and brands, and the OS version of desktop traffic will appear to increasingly be ‘10’. Accordingly, DeviceAtlas recommends to its customers in the adtech ecosystem to update their implementations to support OpenRTB 2.6.

The web landscape is characterized by constant change. DeviceAtlas provides its customers with the tools to navigate the web, taking care of complexity so that its customers can focus on their specialized areas of value add, in full confidence that their device intelligence needs are supported.

Follow us on Twitter or LinkedIn for ongoing updates.

Written by: John Leonard, Director of Product Strategy at DeviceAtlas