Recent discussions have revealed disagreement about the expected use and origination of `buyeruid` and `ifa` attributes, and questions about how to convey the method of ID creation and insertion outside of the scope of “traditional” approaches (e.g. user IDs originating from browser cookie syncs or advertising IDs originating from mobile device or CTV operating systems). As sellers gain access to more data and capabilities to identify users and devices, adjustments need to be made for buyers to understand what they are bidding on.
Within the OpenRTB specification, The `buyeruid` attribute, found in the user object is defined as a Buyer-specific ID for the user as mapped by the exchange for the buyer. Similarly, the `ifa` attribute was simply an ID sanctioned for advertiser use in the clear (i.e., not hashed).
Cookie Syncing, RTB, and the Attributes in Question
In the world of web browsers, many, especially on the buy-side, understand the buyeruid to be the product of a process traditionally called a cookie sync. Here’s a common example: an SSP holds the relationship between their user IDs and DSPs user IDs. The SSP knows that ssp_cookie_id: 123 is “mapped” to dsp_cookie_id: abc. This mapping is usually created and stored in a process adjacent to RTB transactions called – you guessed it – cookie syncing.
In an RTB transaction, this enables the SSP to observe their own user ID cookie (ssp_cookie_id in our example) and then perform a real-time lookup to determine the DSP’s preferred ID (dsp_cookie_id), which was set during a previous cookie sync operation. The SSP then inserts that value in the ‘buyeruid’ attribute of bid request for the given DSP. The DSP then uses this cookie ID (the DSP’s preferred ID) for targeting, frequency capping, and attribution. In cookieless environments like Safari, CTV, or iOS, the process laid out above is not possible (as there are no cookies!), so other mechanisms to identify the user are used. The output could be various tokens or signals – it could be a hashed email, an inferred cookie or device ID, or other device-level signals like IP address.
For app environments, the `ifa` attribute was understood to be the made for advertising identifier that could be known only to the device Operating System and passed by an Application downloaded on that device.
In both the `buyerid` and `ifa` cases, the attribute descriptions were vague enough that they needed to be updated with the expected behavior when there wasn’t an agreement between the buyer and the seller about which methods were OK to use and when to put the id in a different field called EIDs that provide additional information around how and when a given identifier got into the bidstream.
Updates
These environments required new ways to identify users. Still, regardless of the methodology and user id type, these values continued to be stored in the same attribute – the `buyeruid` for web environments or ifa for cookieles environments.
Tech Lab has collected a significant amount of feedback about this behavior. While some parties are clear on the definition of `buyeruid` in these environments, many were not. Specifically, many buyers were surprised to learn the values in the `buyeruid` attribute no longer exclusively represented the result of a single, 1:1 cookie sync process between an upstream partner and downstream (DSP) partner. In practice, the value of the buyeruid was populated with different identifiers, or the same identifier sourced from alternative methods beyond the traditional cookie-sync pattern also known as ID Bridging.
It became apparent that improved transparency on identifier sourcing and application within the bidstream was needed. Specifically, the industry needs explicit declaration of id sourcing versus inferring patterns by historical id enrichment or offline agreements between partners. We’ve heard unanimously that publishers and their partners acting in good faith are more than happy to provide this level of transparency.
The March 2022 release of OpenRTB 2.6 promoted a popular extension for Extended Identifiers (EID), to the mainline of the specification. The Extended Identifiers object can contain one or more IDs from a single source or a technology provider.
In early February 2024, the IAB Tech Lab created a workstream across SSPs, Publishers, DSPs, ID providers, and others to define updated standards this kind of transparency requires. The updates to the OpenRTB standard currently in Public Comment until June 10th, 2024, aim to explicitly codify how the market operates today, in addition to supporting future scenarios where a seller may provide multiple Extended Identifiers, and a buyer can bid based on their preferences.
For any non-traditional cookie syncing behavior, the updates currently in Public Comment extend the eid object to ensure that any identifier listed within the object includes the necessary provenance details, such as eid sourcing methodology and which entity set the eid. These declarations provide explicit transparency beyond what is currently found in the eid object.
With this change, the ID Provenance sub-group, an offshoot of the Programmatic Supply Chain Working Group also proposed the buyeruid object remains explicitly used for browser-based cookie sync values between the buyer and seller unless other arrangements have been explicitly agreed to, and all other methods of id settings and retrieving should be specified with the eid payload.
These undertakings are important for the ecosystem as we look to the future of addressability. Implementers and stakeholders are encouraged to review the updates to the OpenRTB Specification in Public Comment until June 10th, 2024.
Co-Founder and CEO
Sincera