Multi Tag Auctions Support in Fledge (B & A in Particular)

[kevinkiklee]

From fledge-docs created by thegreatfatzby: privacysandbox/fledge-docs#51

Background SSP clients will often send a single request to the SSP server with multiple slots for ads available. In our case, this allows us to save significant time and resources on various upfront phases of the auction (traffic filtering, consent, deal eligibility) and has proven empirically important with several important clients. The way this works in our system is that the tech on page collects all of the tags, sends in a single request, generates a request_id that covers the entire request, the SSP server side does the common processing, and then auctions with their own auction_ids are spawned and run in parallel. OpenRTB has support for multi tag as well, although makes no comment on how it should work.

Initial thoughts for B & A flow were that we'd continue to generate the request_id, run the traffic filtering, consent, deal eligibility, etc, in our SSP server, and then coordinate multiple requests to the seller front end.

Concern After some internal discussion today we're curious how this will work in the Fledge B & A flow. We see that there is a UUID generated client side and the idea is to prevent replay attacks, and are now wondering if that would stop us from invoking auctions with the same interest groups for multiple slots.

Thoughts If that is currently the case we'd strongly ask that multi-tag support within a single request be made possible via these APIs. Since the thing we want from a privacy perspective is to prevent replay attacks, I think this could be accomplished by having the SFE's return errors on the UUID in a more nuanced way. The client could generate the UUID and the number of tags on the page, generate a UUID for each auction, or some such, and allow them to be run in parallel within some fairly short amount of time.

[kevinkiklee]

Original comment by chatterjee-priyanka: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1661768433

---

Hi,

Thanks for the issue.

Great questions and I totally agree with your concern.

Please note, multi slot ads are non impacted and will work fine with Bidding and Auction services. We do not plan to enforce anti-abuse / replay attack mitigations until sometime in 2024. Before we enforce those mitigations, we will discuss with adtechs for viable solutions and incorporate those well ahead of time so that the feature is not broken.

Your solution seems viable, however it would be great if we can discuss this in more depth.

One other solution, is if the seller's ad server joins the requests from all ad slots and makes a single request to Bidding and Auction services with ProtectedAudienceInput and other required data for all ad slots. This may help B&A generate ads such that they are different per slot. However, this may require substantial amount of work in seller's ad server and in B&A.

Happy to brainstorm more. Feel free to share more suggestions / feedback. Thanks!

[kevinkiklee]

Original comment by thegreatfatzby: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1662211017

---

Thanks! 2024? Isn't that when everything is going out :)

[kevinkiklee]

RE the SFE handling the split, that is interesting indeed...I guess from the perspective of an API/System developer, who is trying to support different approaches within a coherent framework, my initial thinking out loud responses are:

• Flexibility is likely important here as the ad tech will need to compare the N contextual bids to the N opaque bids, so the ability to link the relevant bids together for final ranking is important. I could see that happening on an auction_id or just happening within the Worklet...auction_id is pprrrrobbbbbaly more flexible b/c it would support the contextual/opaque running either in parallel or sequentially, which different techs may choose differently on to tradeoff performance and logic sharing.
• This would be worth discussing in tandem with my colleagues question in https://github.com/WICG/turtledove/issues/739. If the final choice has to be made in the ranking functions as discussed here then that may box us in a bit.
• Yeahhh...interesting.

[kevinkiklee]

Original comment by thegreatfatzby: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1703979494

---

@chatterjee-priyanka has there been any additional thinking on the multi-tag support? It's come up again as we've gone through some of our ranking cases, and your idea of trying to run it through SFE/BFE as one request and let things kind of get coordinated with as few requests as possible, was discussed as well.

[kevinkiklee]

Original comment by chatterjee-priyanka: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1707679007

---

Hey,

Sorry about the delay.

• Overall Multi Tag auctions are supported with B&A (we recently tested that). As I confirmed before, we will not enforce anti-abuse mitigation and break this feature (or find other workarounds for anti-abuse mitigation after additional review with Security experts). If we plan to enforce anti-abuse mitigation with generation_id (request id), we would work well in advance with all SSPs engaged with B&A.

• Regarding my earlier suggestion "seller's ad server joins the requests from all ad slots and makes a single request to Bidding and Auction services with ProtectedAudienceInput and other required data for all ad slots." There may be a few reasons why this can be interesting / good to support. However, this would be an option for SSPs who may want to pursue this; we can possibly accommodate both this option and multi request multi tag option currently supported, at least for a while. Reason 1: This can optimize number of calls from seller's ad server to B&A to one and therefore seller won't have to send same contextual signals and other data in AuctionConfig over the wire in different requests (possibly optimize latency even further and save on network cost). Reason 2: This can potentially lead to a solution where different Protected Auction / Audience ad can be selected for different ad slots on the page. Reason 3: This can allow enforcing anti-abuse mitigations with generation_id.

I see the above as an enhancement and optimization to existing multi tag auctions capability with B&A. We should definitely brainstorm the enhancements with SSPs and try to come up with requirements and design for supporting this in B&A. However, support for this may take a while. Let us know if you think this should be higher priority. Thanks.

[kevinkiklee]

Original comment by thegreatfatzby: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1707720205

---

Thanks and NP, we're all super busy.

On the multi tag, am I correct in saying it's supported in the sense that the Seller Ad Service can kick off multiple auctions (which will allow for reduced latency) but they will all be separate auctions and not have any ability to coordinate as described here?

[kevinkiklee]

Original comment by thegreatfatzby: https://github.com/privacysandbox/fledge-docs/issues/51#issuecomment-1712720003

---

@chatterjee-priyanka thinking about it more, the unification above, or something like it, would open up huge opportunity for parity with current First Party Ad Server functionality for things like Competitive Exclusion, Page Caps, and Roadblocks (see same ticket from above).

By making multiple auctions a "first class citizen" in the design, we get to a place where we could allow state to be shared during bid ranking, but still constrained by the DP/K output gate. I suspect the lack of Competitive Exclusion and Page Caps (less so Roadblocks) will be a big problem for many 1PAS's.