You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The event-level API provides two main pieces of information:
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:
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.
The text was updated successfully, but these errors were encountered: