-
Notifications
You must be signed in to change notification settings - Fork 269
Description
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
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?