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

Proposal: Extending IPA to support advanced reach reporting #64

Open
ssanjay-saran opened this issue Apr 7, 2023 · 0 comments
Open

Comments

@ssanjay-saran
Copy link

ssanjay-saran commented Apr 7, 2023

tl;dr: R&F measurement is important for brand advertising, and it seems like IPA can be extended to support this use case. Lots of trade-offs to consider, but definitely worth a discussion/deep-dive.

Context: Brand advertisers are a significant part of the digital advertising ecosystem, and accurate assessment of reach & frequency of ads have always been prioritized by advertisers, large and small, that focus on brand building. In addition to measuring R&F, advertisers also want to manage the frequency of ads, to ensure ads are seen at least M times, but not more than N times. This type of measurement and management has most often required access to individual identifiers (facilitated by 3rd party cookies and device identifiers) -- mainly because the de-duplication happens across devices/platforms/media and a persistent identifier helps with easy count(distinct) queries. However, to truly protect user privacy on the web, while still providing utility to brand advertisers, you can enable these measurements in aggregate -- R&F is an aggregate measure anyway; while frequency management done in aggregate can be quite effective.

Progress to-date: A group of advertisers, in collaboration with trade groups, media publishers and broadcasters, have been working on a cross-media measurement solution that intends to enable privacy-forward reach & frequency measurement. The proposed architecture essentially has 3 parts: 1. A service that takes in ad impression information and spits out a statistical label (the labels on their own don't mean anything and don't relate to an individual, but labels can be analyzed together to create accurate reach & frequency measurement; 2. A service that takes these statistical labels and converts them to encrypted sketches (like bloom filters, these sketches preserve some notion of the underlying database without having store each individual impression, thereby significantly reducing storage and compute needs); and 3. A 3+ party MPC that takes encrypted sketches and produces a differentially privacy aggregate. One thing to note is that it is preferable to perform some of the steps outlined above (especially step1) on-device to be able to scale to all publishers on the web.

Overlap/Synergy with IPA:
The team working on R&F recently requested Chrome to support this functionality using the shared storage method. Essentially, the ask is for browsers to enable a client-side mechanism to generate encrypted statistical labels that can be used in a downstream secure computation (using 3+ party MPC). Now, the first part of IPA, which is setting an encrypted match key client-side, can be very helpful to generate the statistical label (step1 above). With this enabled, the R&F solution doesn't have to rely on any impression level identifiers on-device, and instead can leverage the browser/device-generated key as the input to generate the statistical labels. For web platforms, this allows them to solve 2 large use cases (R&F and conversion attribution) using the same mechanism. There is also a lot of commonality in terms of MPC consortium (helper party network) and differentially private aggregate outputs. I think it would be valuable for the team to think through this use case and have a discussion on what it would take for IPA to also enable the R&F use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant