A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Conversion Measurement API

csharrison
2019-05-23

Overview

This proposal is fleshed out more in an explainer.

Currently, the web ad industry measures conversions via identifiers they can associate across sites. These identifiers tie information about which ads were clicked to information about activity on the advertiser’s site (the conversion). This allows advertisers to measure ROI, and for the entire ads ecosystem to understand how well ads perform.

Problem

Existing techniques to measure conversions rely on propagating identity across sites. This is a powerful capability that has negative privacy properties. Conversion measurement shouldn’t require such a powerful capability; there ought to be a privacy preserving way to do it on the web platform.

Solution

We propose a declarative way of registering impressions and conversions, and a reporting channel which bundles impression information with conversion information in a single report.

This is similar to the ad click attribution proposal, with some substantial differences:

  1. Ad impressions in iframes are supported, rather than just first party ads (those in the main frame document). The ads ecosystem relies on iframes to isolate third party content and we don’t want to incentivize abandoning that security boundary.
  2. Third party reporting endpoints are supported, so publishers can monetize their sites without making server side changes.
  3. Our goal is to include enough information in the conversion report to allow for training ML models to predict things like “conversion rate” of a given ad, which allows publishers to monetize more effectively. This kind of training needs extremely coarse information from the advertiser, but richer data about the impression. Richer impression information also provides better protection against fraud.
  4. We are exploring adding noise with some differential privacy guarantees to the conversion reports.
  5. We are exploring server side aggregation techniques where the server can’t learn things about user conversions (i.e. Secure Aggregation, aggregating hashed values). This opens up the API to provide more useful reports with richer information.

There are still many open questions that we need to resolve, so we hope to gather more feedback via Github issues on the explainer.

btsavage
2020-03-20

Hi Charlie,

This is Ben Savage, from Facebook. I would like to voice our support for moving this proposal into the WICG, to further the process of bringing it together with the Safari proposal.

Innovative approaches to training machine learning models are crucial to the future of digital advertising and privacy. Chrome’s Conversion Measurement API proposal is an important step forward, and we look forward to working with Chrome to address open questions, for example the proposal’s exclusive focus on same-browser click-through conversions. We also plan to continue engaging with other partners on different proposals to move the industry forward.

cwilso
2020-03-20

Awesome, thanks Ben! I’ve moved this to the WICG org: https://github.com/WICG/conversion-measurement-api.

csharrison
2020-04-16

I wanted to quickly update this thread to point out that we’ve added some updates to the repo, in particular to the AGGREGATE and SERVICE documents! Feedback welcome.