multiple aggregation server calls from component seller

[patmmccann]

Can a component seller call multiple aggregation server calls if there are multiple aggregation servers in a TEE? eg themselves.com and publisher.com?

If not, please take this as a proposal that one could

I ask bc the text in this document:

Publisher Revenue Accrual and Impression Validation

Tech Lab report: | Privacy Sandbox response: -- | -- “a publisher can not listen to events exposing that a PAAPI ad rendered” | The Protected Audience API feature "allowedReportingOrigins" was built to enable reporting to additional independent entities.  Its design was driven by a buy-side feature request, so if it does not meet sell-side needs,

Publisher Revenue Accrual and Impression Validation

Tech Lab report: | Privacy Sandbox response: -- | -- “a publisher can not listen to events exposing that a PAAPI ad rendered” | The Protected Audience API feature "allowedReportingOrigins" was built to enable reporting to additional independent entities.  Its design was driven by a buy-side feature request, so if it does not meet sell-side needs, we would be happy to add another corresponding reporting destination mechanism.

How does a component seller use this feature to provide reporting to publisher.com? Is there an event we can spec out?

Thanks so much for saying we would be happy to add another corresponding reporting destination mechanism. !

[MattMenke2]

You'd probably have more luck asking over at https://github.com/patcg-individual-drafts/private-aggregation-api, the spec for the private aggregation APIs. That having been said, I'm not seeing any URL or origin parameter in the private aggregation hooks for FLEDGE.

[patmmccann]

if it does not meet sell-side needs, we would be happy to add another corresponding reporting destination mechanism.

@MattMenke2 I'm confused by your redirection here. This request is about who the component seller worklet can call when it is reporting results. You guys said come here in your response to the iabtl document and now you are saying go somewhere else?

We're not looking for functionality to change on the aggregation api, we're looking for the PAAPI seller worklet to be able to call their own aggregation server as well as another.

An alternative solution is to emit a javascript event a publisher could listen to from runAdAuction() saying if an auction occured, if so did it select a winner, if so which component won.

[MattMenke2]

Sorry, it's been a month, and I've completely lost context.

[patmmccann]

Fair enough, let me try and reframe, publishers are attempting to request a feature that component sellers can call publisher.com aggregation api from the report result worklet, OR that runAdAuction surfaces a javascript event with the component seller identified as winning a PAAPI auction, so publishers can count PAAPI auctions and their respective components without relying on ATP, or that they can confirm their ATP integrations are working as expected.

[michaelkleber]

Hi Pat, my apologies that I missed this issue last month!

This is a very interesting question. It seems like there are two different things we'll need to work out to meet this:

1. What are your use cases for the information you want from the reporting aggregates? You specifically asked about a component seller generating the report that is sent to a publisher endpoint, but I'm wondering in particular whether your needs could instead be met by the browser sending the report without the seller's direct involvement (e.g. based on some kind of static page-level configuration).

2. Use of the Privacy Sandbox APIs is currently gated by an Enrollment flow which requires some core privacy attestations. That was all built for a third-party use case, as I'm sure will jump out at you when you hit the part about multiple enrollments for one entity. What you're asking for would require some kind of first-party version, in which activity on website W gets reported to a reporting endpoint on W itself, but of course a single entity might own many websites.

I'll start talking to our Enrollment & Attestation folks about part 2, but this Issue would be a great place to talk about part 1. In particular it would be excellent if we could hear from multiple different publishers about how they might use this capability, so that we don't accidentally build something that is too restrictive to be widely useful.

[patmmccann]

(1) Yes that would solve as well

Re: #2, you make a great point, it isn't always publisher.com but perhaps saleshouse.com or publisherholdingcompany.com or magazinegroup.com that would expect the additional aggregation gate. In our case, Raptive, we would hope that our attestation would allow us to receive these reports when we setup all the advertising on a site. These sites are identifying us as 'managerdomain' at for example https://cafedelites.com/ads.txt . Similarly wsj.com identifies dow jones as owner at https://www.wsj.com/ads.txt

Almost all publishers currently use their ad server to reconcile impression counts with their SSP partners. Many of those publishers also use 'prebid analytics modules' to also count how many impressions each ssp wins using javascript events triggering calls to an endpoint when some ssp wins. Large publishers however don't typically rely completely on the ad server, and also count events from https://developers.google.com/publisher-tag/reference#googletag.events.SlotRenderEndedEvent slotRenderEnded and compare them to the ad server counts, in order to validate ongoing integration health.

I'll try and socialize this issue in the publisher community.

[michaelkleber]

Ah thanks, that context is very helpful!

So perhaps another way of saying this is: Protected Audience already supports win reports going to two sell-side parties, the top-level seller and the component seller, which gives those two parties a way to cross-check one another. This is a request for having another cross-checking destination as well.

But in that framing, it seems like the "first-partiness" of the report is not so important. That is, maybe any site might want to nominate any cross-checking partner? This is turning the feature back into something more normal, from the Enrollment point of view, where a single cross-checking provider could be a 3p used by whichever sites want its services. And a publisher could of course decide to run this itself. In this case e.g. Raptive sites could all send their reports to cafemedia.com directly, rather than cafedelites.com sending them to an endpoint on cafedelites.com itself.

[patmmccann]

This is a request for having another cross-checking destination as well.

Yes, or alternatively, an event to listen to.

the "first-partiness" of the report is not so important. That is, maybe any site might want to nominate any cross-checking partner?

That's right! Perhaps you are right and the "first partiness" part of the feature request was adding unnecessary requirements; it was intended to limit the potential privacy impact, but happy to sever.

[bmayd]

We talked about this in the April 3, 2024 WICG meeting based on issue: #1115 (Addition of an analytics/reporting entity to enable centralised reporting). Several suggestions were made, including:

• Develop a standard set of reports based on what publishers currently receive from analytics providers.
• Include low entropy reports that can be sent quickly and provide a means of detecting breakage. Include richer aggregate reporting with delays.
• Allow reports to go to 3rd-party service providers using a delegation model similar to what Attribution Reporting API provides.

[patmmccann]

closing in favor of #1115