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.

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

Consider adding event-level data for conversion data as opposed to impression data #85

Open
csharrison opened this issue Nov 18, 2020 · 0 comments
Labels
possible-future-enhancement Feature request with no current decision on adoption

Comments

@csharrison
Copy link
Collaborator

The event-level API provides two main pieces of information:

  • Highly identifiable information about a particular event (the impression)
  • Coarse and noisy information about the cross-site data relative to that event (the conversion metadata)

The API was designed this way because it seemed like a lot of use-cases really benefited from highly granular data about the impression to allow for slicing on impression-side information, and for training ML models (where the conversion-side information acts like an ML label).

However, some use-cases may benefit from providing a flipped view of the data:

  • Highly identifiable information about a particular event (the conversion)
  • Coarse and noisy information about the cross-site data relative to that event (impression metadata)

In particular, one use case that cannot easily make use of event-level data about an impression is TURTLEDOVE-style ads, where the impression itself takes place in an isolated environment. In this case, a unique ID for the ad impression cannot be associated with both the page context and targeted interest-group, since TURTLEDOVE does not allow those pieces of information to be joined.

In fact, the SPARROW proposal proposed something somewhat similar to this, where the entries in their "Ranked Granular Report" could come joined with a click ID (joinable to the conversion) as well as some coarse information about the impression as long as it is protected with some privacy preserving techniques like k-anonymity, etc. See WICG/sparrow#16 for a bit more detail here.

There also may be use-cases where this kind of information could be useful in addition to the fine-grained impression information, although we would need to be very careful to maintain our privacy goals in the face of providing both types of information simultaneously (for instance, the two reports should not be linkable).

cc @michaelkleber @BasileLeparmentier for thoughts and to check my understanding.

@csharrison csharrison added the possible-future-enhancement Feature request with no current decision on adoption label Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible-future-enhancement Feature request with no current decision on adoption
Projects
None yet
Development

No branches or pull requests

1 participant