-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiple aggregation server calls from component seller #1035
Comments
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. |
@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. |
Sorry, it's been a month, and I've completely lost context. |
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. |
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:
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. |
(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. |
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. |
Yes, or alternatively, an event to listen to.
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. |
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:
|
closing in favor of #1115 |
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
Publisher Revenue Accrual and Impression Validation
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.
!The text was updated successfully, but these errors were encountered: