Actually, reading over your claims of SPARROW support in w3c/web-advertising#64, I see that you're asserting way more than that! For example, you say

Multi-toucht attribution available as of today thanks to the ranked k-anonymous granular report described here

To support multi-touch attribution, the Gatekeeper would need to know about every ad this advertiser showed to a particular user. Are you imagining the browser attaching a persistent ID to all of its Gatekeeper requests? That's not mentioned anywhere in the proposal — and indeed the fact that you talk about a bucket for A/B testing makes it seem like you do not have such an ID.

So I think the reporting you imagine may not be compatible with the design you've described, or else you need more explanation about how it could possibly work.

This is indeed a mistake on our part. Multi-touch is not fully supported, only post-click multi-touch. We will update to fix this error. Conversions are not reported to the Gatekeeper. They are reported to the advertiser, and we will be able to join them with the report, thanks to a click id.
The persistent id that would be used for multi-touch is the first party id of the advertiser, and this is why we can support multi-touch post-click, but not post-view.

Backing up a step, how about viewability: Does the Gatekeeper learn which ads end up viewable in the publisher page? If so, how? If not, how does the advertiser join viewability information with Gatekeeper information (for the ranked k-anonymous granular report)?

Following our workshop, please find below a summary of the discussions around this issue. The full video can be found here, password:0Y$y0.R$. We invite participants to comment if they want to add a specific point or want to correct the following summary of the discussions.

Gatekeepers should not be involved in conversion as the delay can be quite high between conversion and display/click.

However, it should be involved in viewability (but not post-view conversion). Notification of a view should be sent directly to the gatekeeper.

This should be done without exchanging PII. We think it should be possible by firing a pixel directly to the gatekeeper including a display id in order for it to be able to join the view information with the display.

Additional work is needed to ensure feasibility and privacy of the proposed solution.