Open alextcone opened 2 years ago
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.
@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.
@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:
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.5
so they are looking for a mechanism to keep their audience from being recreated and either resold or cherry picked where it is cheapest5
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.
Plus, if everyone has already done the work to build to FLEDGE anyway…
@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.
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 calledowner
. The primary use case for this design seems to be the buyer's DSP being theowner
of theinterestGroup
. This would not work for a seller defined interest group because the seller does not allow the DSP to own theinterestGroup
. The seller as the ad requestor owns theinterestGroup
. 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 aninterestGroup
in the same way advertisers can currently define which DSPs can bid on aninterestGroup
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 theminterestGroup
has optional properties related to the ad creative itself calledads
andadComponents
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 theinterestGroup
is configured by the buyer. In the case of SDA, the publisher would very unlikely know in advance what ads would serve to thatinterestGroup
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
andauctionConfig
) seem like they would work as is. Even the buyer's bidding logic could be set up in advance to havegenerateBid()
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?