这是indexloc提供的服务,不要输入任何密码
Skip to content

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

@alextcone

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions