Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Event-level] Noise level and intermediate reporting windows #734

Closed
alois-bissuel opened this issue Mar 23, 2023 · 5 comments · Fixed by #742
Closed

[Event-level] Noise level and intermediate reporting windows #734

alois-bissuel opened this issue Mar 23, 2023 · 5 comments · Fixed by #742

Comments

@alois-bissuel
Copy link
Contributor

Hello,

The noise level is fixed for clicks (ie navigation sources) at 0.24%.

If we follow the randomized response mechanism described in the Differential privacy section, the noise level depends on the number of possible output states of the API, which itself depends on the number of intermediate reporting windows.

If we use an attribution window of less than 2 days, the number of possible state is ((8+3) choose 3) = 165. According to the randomize response mechanism, the noise level with the selected epsilon value of 14 should be 0.01372% (which is far from the 0.24% for three intermediate windows).
For two intermediate reporting windows, the number of possible states is 969 and the noise level should read 0.08051%.

Would it be possible to change the noise level based on the attribution window length? Otherwise I think this puts users of the event-level API who choose it to report only on short attribution windows at a disadvantage.
@csharrison
Copy link
Collaborator

This feels very reasonable to me, @alois-bissuel . Thanks for the suggestion, I agree it only makes sense to "pay for" the windows that you could possibly use for a given source.

I think the only major consideration to me is spec/implementation complexity, which we can investigate.

@csharrison csharrison mentioned this issue Mar 29, 2023
Merged
@csharrison
Copy link
Collaborator

@alois-bissuel would you be willing to discuss this in the next meeting on Monday?

@alois-bissuel
Copy link
Contributor Author

With pleasure!

@csharrison
Copy link
Collaborator

Great, I think this dovetails nicely into our recent publication of the flexible event-level configurations, which we are hoping to discuss as well:
https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md

This proposal is a "lite" version of that design which attempts to offer much more flexibility.

@chandan-giri
Copy link

Thanks @alois-bissuel for sharing the proposal. This is a very interesting idea to achieve configurability in the event API.

This proposal would be very useful for Google ads as this gives us 2 benefits

  1. Reduces Noise: reduce the noise level to 0.08% (for 2 effective windows), 0.01% (for 1 effective window). This is very useful for advertisers with low cvr for which the current noise of 0.24% has a high impact.
  2. Configurability: configurability on the last reporting windows to a smaller value than the current global default of 7d. We have seen higher transmission losses for higher values of windows as posted in Updating Reporting Windows for Event-level reports in ARA #736

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Flex windows WICG/attribution-reporting-api
3 participants
@csharrison @alois-bissuel @chandan-giri