A first account of the auction mechanism in SPARROW is available in the README.md. We try to further illustrate in this document how the multiple actors interact.
In this diagram, the call to the ad server is intended to work exactly as of today. The new call to the browser (to get IG information) is a SPARROW addition. In this call, an SSP in charge of the auction is defined, and a shared opportunity id is given between the two calls, to be able to reconcile bids in the future.
As in the previous diagram, the new aspect is the browser/gatekeeper. As third party cookies disappeared, the "standard" bid request only contains contextual information.
DSPs respond with a bid as they do today; then gatekeepers all send their bids to the SSP defined in step 1.
Questions remain on what information is sent along with the gatekeeper bids.
The less disrupting option would be for the gatekeepers to send along with the bid the advertiser for which it is doing the ad. This would allow SSPs to handle ad quality.
Another option would be for SSPs to communicate ad quality guidelines to gatekeepers in advance so that it can handle ad quality on its side before transferring bids to the SSP.
Gatekeepers ads can only be rendered in a fence frame whilst standard bids have no such restrictions.
URL for rendering gatekeepers ads are anonymized and auctions are run by the SSP, as of today.
The ad, chosen by the ad server, is rendered. For SPARROW ads, view, click and rendering information is sent directly to the gatekeeper who will use it to generate reporting.
The reporting is sent to the various actors following the rules defined here