Could FLEDGE become a mechanism to keep buyers from building profiles from SDA on ad requests?

[alextcone]

Recently, IAB Tech Lab finalized the "Seller Defined Audiences (SDA)" specification which seeks to allow those with ad inventory to attract buyers based on what the site/app with ad inventory knows about its own audiences. The specification highlights that mechanisms are needed to keep buyers (advertisers and their technology providers) from building cross-site/app profiles with the broadcasted interest group + a granular cross-site/app ID. It occurs to me that FLEDGE could be one of those mechanisms. However, I think there might be a few current FLEDGE configurations presenting hurdles to this path for SDA. I think it's very much worth aligning on whether there are present FLEDGE design hurdles or not and if there are what they are because if we could make FLEDGE work for this use case I believe it would unlock a lot of opportunity for ad inventory sellers (and others) to feel comfortable with SDA.

Hurdles I think I see:

• interestGroup has a property called owner. The primary use case for this design seems to be the buyer's DSP being the owner of the interestGroup. This would not work for a seller defined interest group because the seller does not allow the DSP to own the interestGroup. The seller as the ad requestor owns the interestGroup. Buyers would just know that seller IGs exist and could chose whether, when and what to bid for a given pre-known seller IG. Sellers might define which buyers could bid on an interestGroup in the same way advertisers can currently define which DSPs can bid on an interestGroup created on their sites/apps.
• interestGroup has a few subsequent optional properties for specific bidders and bidding logic URLs. Presumably these would not be used in this case because the initiator of the ad request with a seller defined interest group may not have pre-defined which bidders they want to have bidding in SDA circumstances. Again the current design of FLEDGE really only takes into account a buyer's (and their bidder) interest groups and how that buyer creates and values them
• interestGroup has optional properties related to the ad creative itself called ads and adComponents the latter of which seems expressly intended for product retargeting or dynamic creative from the buyer. This for sure wouldn't be used in the SDA case, but I think it is yet again indicative that the current design of FLEDGE assumes the interestGroup is configured by the buyer. In the case of SDA, the publisher would very unlikely know in advance what ads would serve to that interestGroup and if they did, they wouldn't go to the trouble of using FLEDGE for SDA and they'd simply set up a direct sold line item in their ad server.

  What seems to work as is?

Beyond the hurdles above, the flow of the process to make a request of FLEDGE (runAdAuction and auctionConfig) seem like they would work as is. Even the buyer's bidding logic could be set up in advance to have generateBid()s for particular seller IGs. I would like people more familiar with FLEDGE than I am to check my logic.

Again, if the basic primitives, architecture, and cross-site/app profiling threat model of FLEDGE could address the SDA use case we might see a whole lot of value unlocked. I think we may not be that many configuration modifications away from addressing this use case. What am I missing?

[lukwlodarczyk]

Hi Alex, Thank you for submitting this! This sounds super interesting from the perspective of DSP and advertisers. I am afraid that the current design is not allowing to "lease" an interest group. In other words, a particular interest group is not available for multiple buyers and an interest group can not have multiple owners. So it will be hard to keep a common taxonomy.

Hopefully, I am missing something and Chrome folks might correct me that I am wrong or maybe they will suggest some mechanics allowing to satisfy this use case. Look forward to further discussion in this thread.

[michaelkleber]

@alextcone If publisher1 creates an SDA, is it supposed to be possible to target those people only while they are on publisher1.com? Or are you imagining publisher1 getting some cut of the action when its SDA is targeted even while they visit publisher2?

If you only want the same-site targeting capability ("first party data"), then I think FLEDGE is overkill: a whole lot of it is all about avoiding information leakage that just isn't relevant when the publisher already knows what SDAs its visitors are in. In that case it seems like what you're asking for is a perfectly normal auction that just doesn't include third-party cookies — neither at ad request time nor at ad rendering time. The rendering-time part of that could be addressed with Fenced Frames. The request-time part seems trickier since SSPs generally have code on the publisher page, so this seems best served by SSPs offering this feature of their own accord, rather than browsers trying to get involved.

@lukwlodarczyk You're quite correct that FLEDGE is not really set up for a single interest group to represent multiple buyers bidding against each other for the same impression. But my impression is that Alex's issue is about the first-party-audience use case, so let's keep your cross-site audience use case separate.

[alextcone]

@lukwlodarczyk writes:

I am afraid that the current design is not allowing to "lease" an interest group. In other words, a particular interest group is not available for multiple buyers and an interest group can not have multiple owners. So it will be hard to keep a common taxonomy.

I think of it as less of a lease and more of the following scenario:

• Publishers 1.com, 2.co.uk, 3.com, 4.co, 5.io, 6.com, 7.com, and 10.io each individually want to capitalize on being able to understand their own audiences
• Publishers 1.com, 2.co.uk, 3.com, 4.co, 5.io, 6.com, 7.com, and 10.io know many advertisers are interested in a demographic 25-29 year olds
• Publishers 1.com, 2.co.uk, 3.com, 4.co, 5.io, 6.com, 7.com, and 10.io have captured data in direct interactions with their users that allows them to categorize users into age demographics
• Publishers 1.com, 2.co.uk, 3.com, 4.co, 5.io, 6.com, 7.com, and 10.io use IAB's content taxonomy 5 "Demographic | Age Range | 25-29" to take advantage of the SDA specification and want to pass this information in an ad request, but are afraid to do so because even with 3pcs gone they know many pieces of technology may still use IP address, user agent information or other methods to identify users across sites, apps or even home devices.
• All of these publishers would love to be able to take advantage of advertiser demand targeted at IAB's content taxonomy 5 so they are looking for a mechanism to keep their audience from being recreated and either resold or cherry picked where it is cheapest
• None of these publishers is interested in audience extension (aka offering buyers to buy the publisher audience across other sites), each just purely wants to take advantage of demand already pointed at IAB content taxonomy 5 and their ability to understand that a given site/app visitor falls into that category

@michaelkleber writes:

If publisher1 creates an SDA, is it supposed to be possible to target those people only while they are on publisher1.com? Or are you imagining publisher1 getting some cut of the action when its SDA is targeted even while they visit publisher2?

Neither. Hopefully the above describes, but I will simply to try to answer directly. publisher1.com who creates IG 123 is looking to take commercial advantage of the fact that many advertisers would be interested in IG 123 and may already have campaigns running that target the taxonomy classification associated with IG 123. This is effectively giving publishers the ability to create Topics (instead of the user agent) in that we know that buyers are just generally interested in a lot of different topics that the publisher may be able to understand about their users that isn't necessarily directly contextually inferred because of the name or focus of the site/app.

I realize FLEDGE may be heavy for this, but the problem to solve for is that global ID surface area will not be completely gone for some time, but many publishers already want to make the transition to this world.

[alextcone]

Plus, if everyone has already done the work to build to FLEDGE anyway…

[JensenPaul]

@alextcone The scenario you describe sounds like the same-site targeting capability (“first party data”) that @michaelkleber describes.  FLEDGE isn’t designed to address this use case and doesn’t seem like the appropriate mechanism for this kind of targeting for all the hurdles that you listed.  Chrome has plans to address the publishers’ hesitancies you mentioned: GNATCATCHER for IP addresses and User Agent Reduction for user agent information.

If for some reason it is really important to support buying on SDAs with all of the information flow protection we're building for FLEDGE, then maybe a way to do it would be for a seller to pass SDA labels into the on-device auction, and a buy-side ad tech to create their own Interest Group whose bidding logic says "I want to buy Audience X."  But overall I'm pretty skeptical of this use case.