Seller-Defined Audiences Explained

Remember Project Rearc? The Interactive Advertising Bureau (IAB) formed the project in response to Google's decision to end third-party cookie support in Chrome. The initial announcement pledged that:

After two years and a global pandemic, the IAB Tech Lab has finalized its first technical specification to come out of Project Rearc, called Seller-Defined Audiences.

What are seller-defined audiences?

Seller-Defined Audiences or SDA is a technical specification that outlines a method for communicating first-party audience attributes in an OpenRTB bid request without revealing user identity.

The IAB Tech Lab held up the Project Rearc promise to address consumer demands for personalization and privacy by introducing SDA. They fulfilled the Rearc goals of creating new standards of behavior, codes of conduct, and enabling technologies to make it possible.

The specification is the culmination of several parallel efforts that coalesce into a privacy by design solution to facilitate interest and behavioral audience targeting without sharing user identifiers.

Seller-Defined Audiences is unlike universal identifier solutions since it does not require the exchange of user identifiers between publishers, SSPs, DSPs, and DMPs.

Instead, publishers will curate their audiences into standardized demographic, interest, or behavioral audience groupings that they will communicate in bid requests to a Demand-Side Platform bidding on their inventory.

Publishers utilizing SDA need to curate users into standardized audience cohorts based on interactions and data gathered on publisher-owned properties. SDA allows publishers to showcase their first-party data for buyers seamlessly and privately.

Publishers should not share user identifiers in bid requests if they use seller-defined audiences. SDA creates a paradigm where identifiers are not necessary to activate audience data, so advertising platforms do not need to track users across separately owned properties.

The solution is unlike Google Topics API, where Chrome algorithmically categorizes user interests at the browser level based on browsing history and broadcasts those topics out to all who listen. Instead, SDA requires publishers to implement a thoughtfully coordinated first-party data strategy.

The SDA proposal comes hot on the heels of the IAB Tech Lab announcing that they will not assume the needed UID2 Administrator role, indicating that the decision was due to a lack of scale and adoption.

The IAB is already in hot water in Europe since the Belgian Data Protection Authority deemed its Transparency and Consent Framework illegal, so they probably wanted to avoid any more legal exposure following that debacle.

Rather than introducing the responsibility and complexity required to be the UID2 Administrator, the IAB Tech Lab appears to be focusing on privacy by design solutions like seller-defined audiences.

How do seller-defined audiences work?

At a high level, the workflow to utilize SDA is simple:

1. Publisher segments audience

2. Publisher includes segment IDs in a bid request

3. DSP reads segment IDs and decides whether to bid

But this is ad tech, and nothing is that simple. Following SDA involves adhering to specific guidelines and separate but parallel processes to activate audience targeting.

The SDA workflow

Let's dive into each step of the SDA workflow to learn how everything comes together.

1. Publisher segments audience

First, publishers must segment their users into one or many of the 1,600 available demographic, interest, or purchase intent attributes that make up The IAB Tech Lab Audience Taxonomy.

Using a standardized taxonomy ensures all interested parties are speaking the same language. So when a DSP receives a bid request from ESPN.com that includes segment ID 608, they understand that is:

Interest | Sports | American Football

The IAB Tech Lab will also allow custom taxonomies, but they must approve each one via a pull request submitted to this Github repo. Publishers must still ultimately map a custom segment back to one of the standard IAB Tech Lab audience segments if they use a custom taxonomy. We will explore this further in a later section.

Many publishers already work with data management platforms (DMP) to segment their logged-in users into audiences using publisher-provided identifiers (PPIDs), universal IDs, device IDs, or cookies. Now publishers must work with their DMP to map users into a standardized audience cohort to enable SDA.

PPIDs are unique alphanumeric identifiers assigned to a logged-in user (email) that make an ideal first-party identifier since they can work cross-device (in contrast to a cookie or device identifier).

Publishers can segment identifiers into audience groupings based on data collected during registration or through behavior and interests expressed by the user on publisher properties.

The new challenge will be storing new SDA required fields alongside existing first-party segment metadata and populating outgoing ad requests with the necessary SDA metadata in real-time.

The approach here may depend on the environment where the ad is displayed.

2. Publisher includes segment IDs in a bid request

SDA requires that publishers pass along a set of required fields and associated metadata in a bid request:

• Provider name - Domain name of whoever determines segment membership

• Segment ID - The ID of the segment from the declared taxonomy

• Taxonomy name - The taxonomy where the segment ID can be found

Publishers must pass the metadata in an OpenRTB bid request using the existing user, data, and segment objects from the ORTB 2.6 specification.

For publishers using the open-source header bidding solution, Prebid, the IAB Tech Lab highlights a function that publishers can use to set relevant ORTB attributes in Prebid. SSPs (or The Trade Desk) can then resolve the SDA data to pass along to DSPs.

It is up to the publisher to figure out how to pass these values to Prebid. The IAB Tech Lab mentions using on-page data assemblers, and while they do not go into specifics, one could reason that a publisher needs to write code to assemble SDA data...on-page.

Curiously, the Seller-Defined Audiences specification designated using Prebid as a prerequisite:

I searched the spec high and low to figure out why Prebid was a requirement and came up short. So I took to Twitter and threw a hail mary, and the CEO of the IAB Tech Lab graciously answered my question:

So Prebid is not a prerequisite.

I had thought Prebid might have stripped identifiers and other fingerprinting vectors before making ad data available to auction participants. I thought this because SDA only maintains its privacy assurances if publishers do not include identifiers that could link individuals to an audience.

The spec calls for SSPs and header bidding wrappers (Prebid) to take an active role in preventing the "commingling of cohort signals with other identifiers." But that is still an open point that we will explore further in the conclusion of this article.

The IAB Tech Lab leveraged Prebid to create a turnkey solution to pass data in the bid stream. But in-app or CTV publishers could just as well pass seller-defined audiences via a server-side ORTB integration or even conceivably through VAST ad requests enriched with custom parameters.

SSPs should construct an outgoing bid request once they receive the SDA metadata from either Prebid or another integration. They would need to add a user, data, and segment object along with a new segtax extension populated with all the values set by a publisher.

Segtax is a new ORTB extension of the data object created for SDA. A publisher specifies an integer representing their chosen taxonomy in the segtax field.

Publishers can find the integer to taxonomy mappings in this Github repo.

OpenRTB Extensions

OpenRTB extensions allow updates and customizations to the JSON ORTB output. You can add ext nested under any object and add whatever the hell data you want. But you better make sure whoever is consuming the ORTB bid request / response knows to look for it.

The IAB Tech Lab has always had a notoriously difficult time compelling an entire industry to adopt new versions of any standards like VAST or ORTB. The IAB Tech Lab has tried to gain traction with ORTB 3.0, but many platforms chose not to adopt the new version

Extensions allow quick updates to ORTB between partners without committing to fully supporting another version.

Let's pretend that an ad view on adtechexplained.com generated an ORTB request, and I wanted to provide seller-defined audiences to any DSP bidding on my inventory. My SSP should construct an ORTB bid request to include the following user object:

"user": {
  "data": [
    {
      "name": "adtechexplained.com",
      "ext": { "segtax": "4" },
      "segment": [
        { "id": "306" },
        { "id": "330" },
        { "id": "687" }
      ]
    }],

So what does this object communicate? Adtechexplained.com determined that a user belonged to three segments within the IAB Tech Lab audience taxonomy (4).

If someone referenced the IAB Tech Lab taxonomy they would know those segment IDs represent:

• 306 - Interest | Business and Finance | Advertising Industry

• 330 - Interest | Business and Finance | Technology Industry

• 687 - Interest | Technology & Computing

3. DSP reads segment IDs and decides whether to bid

DSPs that support SDA will look out for the segtax extension. If the segtax extension is populated, that signifies that the seller is defining an SDA audience. But how will a DSP know what the segtax integer or the nested segment IDs represent?

Transparency Center

DSPs or any interested ad tech vendor can pay the IAB Tech Lab an annual fee to access the Transparency Center to query audience metadata via a UI or API.

The Transparency Center is not a new-age temple where you align your chakra, but it could provide equally valuable clarity. DSPs or ad platforms can query audience metadata via a UI or API to map segment IDs to human-readable names.

When DSPs or ad tech platforms offer audience targeting to their clients, they need to display human-readable names of audience segments in their platform UI. Users want to target Interest | Technology & Computing, not segment ID 687 from standardized taxonomy 4.

DSPs typically receive audience metadata from DMPs (you can learn more about that process here). But for seller-defined audiences, DSPs can pull metadata from the IAB Tech Lab Transparency Center.

Platforms can also grab segment names and associated segment IDs of the IAB Tech Lab audience taxonomy from the publicly available list. But the Transparency Center can also reveal more insight into seller-defined audience segments.

Data Transparency Standard

How can a DSP trust that a publisher is not spamming bid requests with valuable audiences that command a high price?

I could populate every bid request from adtechexplained.com with the ULTRA HIGH NET WORTH BUYS EVERYTHING segment and start rolling in cash, right? Wrong.

Well, I could do it. But DSPs may not choose to trust my segment unless I pass muster with the IAB. The industry trade group offers a compliance program that allows:

The labeling they refer to is The IAB Tech Lab Data Transparency Standard (DTS). DTS contains 20 different fields that data providers must populate for each segment ID to provide more information about each segment.

Data providers must fill out a required taxonomy_id_list field. The field is a comma-separated list of IDs from the standard IAB Tech Lab audience taxonomy that best describe the segment. If a publisher is already using the standardized taxonomy in their bid request, this will presumably be a 1 to 1 mapping.

The DTS will help answer questions like:

• What is the human-readable name and ID of the audience segment?

• Where did the data originate?

• How old is the data?

• What identifiers is the data based on? (Cookies, device IDs, PPIDs, etc.)

• What rules were used to segment this audience?

• And much more

DTS creates a model of accountability for anyone providing seller-defined audiences. The IAB Tech lab Transparency Center will ingest DTS metadata from participating data providers. DSPs could then browse and search through the DTS labels in The Transparency Center or retrieve any information via an API.

DSPs could use that metadata for internal audits or make it available to their clients to assist in audience targeting decisions. Remember, this is only metadata, so no identifiers are ever shared.

Once DSPs verify the data, they can store the Segment ID <> Segment Name mapping in their system and make the SDA segment names available for targeting in their UI. DSPs can then match incoming bid requests that contain SDA segment IDs with SDA segment names that their clients target on their campaigns.

Why use seller-defined audiences?

Publishers will not have to share user identifiers with external platforms and companies to activate first-party data for buyers if they use seller-defined audiences.

Typically, if a publisher wanted to activate first-party audience data and allow advertisers to buy against it, they would have two routes:

1. Push the data from a DMP to a DSP and make it available for buyers.

2. Push the data from a DMP to an SSP and create a private marketplace deal (PMP) segmented by audience attributes

Either path requires a publisher to share audience data (User identifier <> Segment ID) and segment metadata (Segment ID <> Segment Name) with another platform.

A publisher may not want to share identifiers for two main reasons:

1. Privacy concerns

2. Business concerns

When you share data with a business partner you entrust them to maintain the privacy of your users. You also trust them to not exploit the business value of your preciously collected first-party data.

As soon as user identifiers (cookies, device ids, universal IDs, PPIDs) leave a publisher database and enter an external database, the publisher relinquishes control of that data. They can no longer guarantee the protection of user data since they do not control the external system that data now lives on.

Publishers can also not technologically prevent a DSP or SSP from repackaging that data to sell it to someone else. Sure, you can legally lock down data through contracts but is that enough?

Data Leakage

Data can spill out even if a publisher chooses not to push data directly to another platform via a DMP. Any platform receiving bid requests with identifiers can package together inventory based only on the signals from the bid request, a concept called data leakage.

Data leakage concerns may have caused some publishers to pump the brakes on adopting universal identifier solutions like The Trade Desk UID2. Some publishers fear that ad tech companies could farm universal identifiers, like a UID2, from bid requests and repackage them to sell elsewhere.

For example, if ESPN.com sends ORTB bid requests to a DSP with decryption keys to convert a UID2 token from the bid stream into a UID2, they can now place all ESPN UID2s into a sports enthusiast segment of their own and sell against it.

Nobody may ever have the audacity to do such a thing, but it is technically possible. With seller-defined audiences, publishers do not need to push data or share a user identifier in a bid request to activate first-party data.

What are the drawbacks of seller-defined audiences?

The main drawback to SDA originates from the level of accountability and trust required from participants. The IAB Tech Lab even emphasizes four points of accountability in the specification:

Accountability of cohort developers to consumer privacy preferences

Are publishers respecting consumer choice and transparently informing users that they use data for ad targeting? The IAB Tech Lab has yet another specification for auditing the supply chain on this topic.

Accountability of supply chain participants to minimize commingling of cohort data with other sensitive data types

SSPs should never include user identifiers (cookies, device IDs, UIDs) in bid requests leveraging SDA to maintain user privacy and prevent data leakage. Even including a user agent or IP address can give malicious actors a vector to track users via fingerprinting.

Ultimately publishers must trust that SSPs or header bidding wrappers, like Prebid, do not comingle identifiers with SDA signals.

The IAB Tech Lab is actively exploring using a trusted server that would sit between a device and the ad tech ecosystem, but they have not shared many details about the idea. Other privacy-focused advertising solutions like Interoperable Private Attribution can offer a sneak preview of how trusted server systems can work for ad tech applications.

Accountability of cohort developers to “sufficiently large” cohort threshold

If a group is small enough, advertising platforms can tie together other bid request information and include an SDA segment ID to form a more accurate fingerprint of a user to track them elsewhere. Offering an additional vector to fingerprint (audience group) is the same problem Google faced with its FLoC proposal and ultimately led them to abandon the effort and pivot to the Topics API.

Accountability of cohort developers to the accuracy of self-attested labeling

Ad platforms can blindly trust SDA signals or only trust those certified by the IAB Tech Lab compliance program.

Even if you only buy data from those who pass the IAB Tech Lab compliance program, you still need to trust...the compliance program. No matter which way you turn, trust is required on multiple fronts.

Despite the multiple levels of trust required, the seller-defined audience approach offers the potential to enhance user privacy and secure the business value of first-party data.

Subscribe to the Ad Tech Explained Newsletter

Ad Tech Explained provides explainers, insights, and analysis on the latest trends in advertising technology.

Photo by mauro  mora on Unsplash