forked from WICG/attribution-reporting-api
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
583a70a
commit 2cac7f3
Showing
1 changed file
with
186 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,186 @@ | ||
| # Attribution Reporting API | ||
|
|
||
| Mon Feb 5, 2024 @ 8am PT | ||
|
|
||
| This doc: [bit.ly/ara-meeting-notes](bit.ly/ara-meeting-notes) | ||
|
|
||
| Meet link: [https://meet.google.com/jnn-rhxv-nsy](https://meet.google.com/jnn-rhxv-nsy) | ||
|
|
||
| Previous meetings: [https://github.com/WICG/conversion-measurement-api/tree/main/meetings](https://github.com/WICG/conversion-measurement-api/tree/main/meetings) | ||
|
|
||
| Meeting issue: [https://github.com/WICG/conversion-measurement-api/issues/80](https://github.com/WICG/conversion-measurement-api/issues/80) | ||
|
|
||
|
|
||
|
|
||
| * Use Google meet “Raise hand” for queuing. | ||
| * If you can’t edit the doc during the meeting, try refreshing as permissions may have been updated after you loaded the page. | ||
| * If you are not admitted to the meeting, try rejoining. Google Meet has some UI that makes it easy to misclick if someone simultaneously requests to join while someone else is typing into the meeting chat. | ||
| * Please make sure to join [W3C](https://www.w3.org/) and [WICG](https://www.w3.org/community/wicg/) if you plan on participating | ||
|
|
||
|
|
||
| # Agenda | ||
|
|
||
|
|
||
|
|
||
| * Chair: Charlie Harrison | ||
| * Scribe volunteer: Charlie & Akash | ||
|
|
||
| Please suggest agenda topics here! (either in a comment or a suggestion on the doc: | ||
|
|
||
|
|
||
|
|
||
| * [Akash\ [Phase 2](https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-2-full-flexible-event-level) Full Flexible Event Level Feedback | ||
| * [Akash] Aggregate Debug Proposal - Null Reports feedback [#705](https://github.com/WICG/attribution-reporting-api/issues/705#issuecomment-1915461662) | ||
| * [Rhaime] Do you see publishers ever integrating directly with ARA, rather than work with an adtech platform? | ||
| * [Rhaime] If a publisher integrated with ARA directly, but did not integrate with an adtech platform, then would advertisers lose the ability to attribute conversions by publisher (given that they are working with multiple publishers)? | ||
| * [Rhaime] Would it be possible for a publisher to integrate directly with ARA and work with an adtech platform? | ||
| * | ||
| * | ||
|
|
||
|
|
||
| # Attendees — please sign yourself in! | ||
|
|
||
| (Please sign in at the start of the meeting) | ||
|
|
||
|
|
||
|
|
||
| 1. Rhaime Kim (The New York Times) | ||
| 2. Michal Kalisz (RTB House) | ||
| 3. Charlie Harrison (Google Chrome) | ||
| 4. Ruchi Lohani (Google Chrome/Privacy Sandbox) | ||
| 5. Stacy Andrade (AdTheorent) | ||
| 6. Yuyan Lei (The Washington Post) | ||
| 7. Matt Lamont (AdTheorent) | ||
| 8. Andrew Pascoe (NextRoll) | ||
| 9. Akash Nadan (Google Chrome) | ||
| 10. (AirGrid/MiQ) | ||
| 11. Aleksei Danilov (Criteo) | ||
|
|
||
|
|
||
| # Notes | ||
|
|
||
|
|
||
| ## [Akash\ [Phase 2](https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-2-full-flexible-event-level) Full Flexible Event Level Feedback | ||
|
|
||
|
|
||
|
|
||
| * Go through some of the features we’re considering | ||
| * If there is any feedback, please stop me | ||
| * Quick overview of where we’re at: we have released Phase 1: allows you to vary the frequency of reporting windows and length of windows. Also vary the # of attributions per source. | ||
| * All varies the amount of total noise. | ||
| * Phase 2: all the capabilities of phase 1 with some additional capabilities | ||
| * Trying to assess utility | ||
| * Trigger data cardinality flexibility | ||
| * CTCs have 3 bits. VTCs have 1 bit. This allows you to customize the # of bits for both. That comes at a noise tradeoff. | ||
| * Customize trigger data values | ||
| * Related to the previous one. | ||
| * This proposal allows customizing distinct values, rather than just an index from [0, cardinality). | ||
| * We are planning on implementing this and the previous one | ||
| * Next two: looking for feedback | ||
| * Summary buckets | ||
| * Allows you to bucketize event-level report values | ||
| * If you are only interested in knowing a user had 1-5 conversions, 5-10, or > 10, you could now get a report that gives you that bucketized output. | ||
| * Use-case: ROAS or value-based optimization | ||
| * There are examples in the explainer. There is a “value” now associated with the conversion that can be summed up | ||
| * Is this something you would find useful? Would use for any of your use-cases | ||
| * Aleksei: this is very interesting to us at Criteo | ||
| * Akash: what is the use-case? | ||
| * Aleksei: sales amount driven by a specific campaign. Optimize based on that. | ||
| * Matt Lamont [AdTheorent]: This is useful for us | ||
| * Akash: Next one is multiple trigger specs | ||
| * With a single trigger spec, you specify the trigger data, summary bucket, and windows. | ||
| * By allowing multiple trigger specs, you can vary those parameters for different triggers | ||
| * Use-case: high value conversions tracked differently than low level conversions | ||
| * E.g. | ||
| * High value → shorter report windows / more | ||
| * Low value → longer report window | ||
| * Aleksei: Explain tradeoff between noise and lost unattributed triggers? | ||
| * Akash: If you had an impression and performed this first registration. Noise would be computed separately based on the registration. But there is a tradeoff between coverage and noise. | ||
| * Charlie: Optimize for “privacy budget spend” on low / high value conversions | ||
| * Matt: we want to test this but exactly what Charlie said is what we’re interested in | ||
|
|
||
|
|
||
| ## [Akash] Aggregate Debug Proposal - Null Reports feedback #705 | ||
|
|
||
|
|
||
|
|
||
| * Second topic is around debugging post-3PCD. One of the proposals is posted to github. Specific topic we’re interested in feedback. | ||
| * This gives you debug information in aggregate form. ALlows you to create a key which is concatenated with a debug code. Can send these to the aggregation service. A count for each bucket + debug code. | ||
| * Feedback: in order to send these reports immediately, we would need to send null reports unconditionally to avoid the privacy leak. To avoid getting insight into certain limits. ANy time you opt-in to getting a debug report. You would either receive a real report or a null report. Our current thought here is to send it unconditionally (e.g. probability of 1). This comes at a tradeoff in the # of total reports you need to receive (performance impact). Note if you are already today receiving all signals will give you a similar # of reports (unencrypted). | ||
| * Wanted to understand if this seems reasonable, or is this latency something you could not handle. | ||
| * Charlie: also considering some alternatives | ||
| * Aleksei: For feedback I had two things in mind. I don’t think null reports will be a problem in terms of scale / volume. For the approach in general - this type of design means in order to be able to use the debug reports, one needs to have the agg pipeline already running and working in place. This might not always be in place. There may be cases where an ad tech ramps up on the usage of ARA. You first make the integration work and then you do the agg pipeline. In this case it would be the opposite. | ||
| * Charlie: It is good feedback. | ||
| * Nan: As charlie mentioned we also considering different proposals. One of them is adding local DP approach where we apply the noise locally on the device instead of in the agg service. We are still thinking through this proposal and will share more details once it is more ready | ||
| * Charlie: deployment simplicity vs. noise. | ||
|
|
||
|
|
||
| ## [Rhaime] Do you see publishers ever integrating directly with ARA, rather than work with an adtech platform? | ||
|
|
||
|
|
||
| ## [Rhaime] If a publisher integrated with ARA directly, but did not integrate with an adtech platform, then would advertisers lose the ability to attribute conversions by publisher (given that they are working with multiple publishers)? | ||
|
|
||
|
|
||
| ## [Rhaime] Would it be possible for a publisher to integrate directly with ARA and work with an adtech platform? | ||
|
|
||
|
|
||
|
|
||
| * Rhaime: would it make sense as a publisher to integrate directly with ARA instead of working with an ad-tech? What is the impact on advertising clients? Would they lose any conversions? | ||
| * Charlie: Typical solutions require having a presence on both the publisher/advertiser page. Are you in a position to have a presence on both the publisher page and advertiser page? If you don’t it might not be the best fit or we may need to think through how to augment the API for this. | ||
| * Akash: that covers it | ||
| * Rhaime: Seems the way the API is made, there isn’t a way for publishers to use it currently. But we could come here (this forum) to share what might be needed for publishers | ||
| * Charlie: For a direct publisher integration that isn’t on the advertiser site, we’d need to think through some other integrations that are directly supported | ||
| * Rhaime: If we worked with 10 advertisers, and we got them to add something to their sites that would allow us to receive information from them, other than the manual information, would they lose out on any information? | ||
| * Charlie: if you’re working with a few advertisers, and get them to issue ping to your server, you should be able to get an integration working. Would it cost an advertiser anything other than integration cost? SHould be as minor as possible based on how we built the API. There may be some rate limit impact. Most limits are by the API caller. But there are some we hope don’t get hit often across advertiser. There is a possibility that these limits get hit more often given there are more API callers for the same advertiser, but maybe unlikely. | ||
| * [https://wicg.github.io/attribution-reporting-api/#vendor-specific-values](https://wicg.github.io/attribution-reporting-api/#vendor-specific-values) | ||
| * [https://github.com/WICG/attribution-reporting-api/blob/main/params/chromium-params.md](https://github.com/WICG/attribution-reporting-api/blob/main/params/chromium-params.md) | ||
| * Rhaime: Is there any documentation regarding the rate limit around collusion that can be reviewed? | ||
| * Charlie: <shared links above with details regarding the various rate limits> The rate limits that are shared across reporting sites are the ones to look for in terms of the question. You can see the concrete values in the links above as well. We’ll check if we have any higher level documents as well. | ||
| * Rhaime: For the advertiser, the implementation cost would be real. But the attributions and reports they receive would be the same | ||
| * Charlie: with the asterisk of the limits, everything else should work as expected. Feel free to file an issue or use this forum to discuss more | ||
|
|
||
|
|
||
| ## Last minute topics? | ||
|
|
||
|
|
||
|
|
||
| * Aleksei: Timeline for flex? | ||
| * Akash: first two (trigger data bits and distinct values). Coming soon likely M123. Other two still working on a timeline. | ||
| * Kechy: | ||
|
|
||
|
|
||
| ## Labeled Privacy Budget Keys | ||
|
|
||
|
|
||
|
|
||
| * [https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md) | ||
| * Kechy: Product manager on aggregation service. Talking about labeled privacy budget keys | ||
| * Kechy: Plan this for H1 of 2024. Wanted to get feedback on this proposal | ||
| * Kechy: gives ad-techs flexibility by allowing them to split the data that is being queried by aggregation service at different cadences. Some ad-techs have data that is more for monitoring vs detailed reporting, and both have different cadences. | ||
| * Kechy: How this works. Ad-tech sets a label when a contribution is made and this would be in the encrypted payload. The ad-tech specifies the label when they query aggregation service to say which to include. If none are specified it works as it does today. | ||
| * Aleksei: Can we submit the same reports in multiple batches, but it will still work if we query by different labels? | ||
| * Kechy: Yes you would send the same reports but specify which labels for each query | ||
| * Kechy: How this works in regard to the Shared ID. The label is now part of the payload and will be added to the Shared ID hash. No impact to budgets and everything will work the same because each label will have its own Shared ID | ||
| * Kechy: In terms of batching with labels, you can specify 1 or more labels for a single batch. | ||
| * Michal: is there any limits on the number of labels that can be used? | ||
| * Kechy: right now we have an estimate (~1000 labels) per batch. We are looking for feedback on this limit. We want to make sure we don’t have too many shared IDs per batch. If you start testing and see that you need a higher limit, please share the feedback | ||
| * Michal: Is there any timeline? | ||
| * Kechy: on the status page we have it as H1, so most likely before the end of Q2 | ||
| * Aleksei: this sounds very interesting for our use-cases. Will this be available for both ARA and Private aggregation? | ||
| * Kechy: H1 is for privacy aggregation, but we are working on the timeline for ARA | ||
| * Michal: Do you know how this API would look like? Would this be on the source or trigger side? | ||
| * Kechy: current design is on the trigger side. We are considering source, but right now it is on the trigger | ||
| * Nan: We are considering if it could be a combination of source and trigger but still thinking through this | ||
| * Kechy: Is there a design that would be better for your use case | ||
| * Michal: no immediate use-case just curious | ||
| * Kechy: Please share any feedback you might have | ||
|
|
||
|
|
||
| ## Key Discovery (Optional Domains) | ||
|
|
||
|
|
||
|
|
||
| * Kechy: Current proposal mentions using a key mask and thresholding. We are proposing V1 of the key discovery proposal | ||
| * Kechy: Key discovery is looking to address the following: noisy outputs, computation cost, operational cost, and specifying a full list of keys prior to campaign launch (XNA use case) | ||
| * Kechy: Option domains: ad-tech doesn’t need to specify aggregation keys for aggregation service. Any keys not included in the domain file will be thresholded. Any keys included in the domain file will not have a threshold applied. Looking for feedback. | ||
| * Kechy: we have the key discovery proposal available on github |