Conversion Filters Proposal

[benjaminsavage]

Hi @csharrison and @michaelkleber!

This is an idea that we brought up on the web-adv W3C call. @michaelkleber indicated it seemed consistent with Chrome's privacy model and suggested bringing it to an issue on this repo.

Conversion Filters Proposal

Many ads shown on publisher websites direct people to large e-Commerce websites that sell a wide variety of unrelated products. Think of Amazon, Walmart, Target, Wish, etc.

Both Webkit’s “Private Click Measurement” proposal, as well as Chrome’s “Conversion Measurement” proposal currently suggest that all conversion events on a given domain could match up with any ad click that directed a browser to that domain. This poses a significant problem for such commerce websites. It would actually be desirable to collect less information here.

Use-Case 1: Collaborative Ads

Many producers do not sell directly to consumers via their own website. Instead, they sell their goods in stores and through large e-Commerce websites. As an example, let’s imagine a producer ShaveCo that manufactures shaving supplies. They sell these shaving supplies on e-Commerce platform MegaStore’s domain megastore.com. If they want to run ads promoting their shaving supplies, the destination of the ads would be megastore.com.

In their current form, the private click measurement APIs would not tell ShaveCo how many people purchased shaving products after clicking on their ads, it would tell them how many people purchased anything at all on megastore.com after seeing their ads. Since people commonly buy a wide variety of products on these large e-Commerce websites, it’s very likely that these APIs will be counting totally unrelated transactions for things produced by other producers, in totally different categories!

This information would be interesting to MegaStore (the other participant in this collaborative ads campaign) but not useful to ShaveCo. ShaveCo is only interested in conversion events that they consider relevant to a subset of the products available on megastore.com - their shaving supplies.

Use-Case 2: Dynamic Product Ads

The large e-Commerce website also wants to run their own ads promoting their website. They might run ads promoting a particular set of products (e.g. School Supplies in a “Back to School” campaign). While it might be interesting to know how many people ever bought anything at all on their website after clicking on an ad, it is also valuable to ask “how many people bought school-supplies after clicking on the ad promoting school supplies?”. They may additionally wish to know “How often was the exact product advertised purchased as a result of the advertisement?”

Proposal

Both conversion measurement APIs propose the addition of new attributes to the tag representing the ad in order to invoke the API. We propose the addition of another optional attribute, which would specify some type of “filter” for the set of conversions this particular ad wants to count.

We are not suggesting any specific protocol for how these “filters” would be implemented, but here is a short list of common use-cases that will drive value:

• “Only count conversions where the product_id is 12345”
• “Do not count conversions where the product_id is 12345”
• “Only count conversions where the product is one of [12345, 23456, 34567, …]”
• “Only count conversions which occur on the sub-domain electronics.megastore.com”
• “Only count conversions that occur within the directory megastore.com/store/electronics”
• “Only count conversions where the product category is ‘school-supplies’”
• “Only count count conversions where the producer is ‘ShaveCo’”

Both conversion measurement APIs propose the introduction of certain conversion metadata which would be associated with the conversion event. The Webkit proposal also suggests a “priority” attribute. We propose that advertisers can additionally specify various meta-data about the conversion event (e.g. Producer: “ShaveCo”, product_id: “12345”, category: “Shaving Supplies”).

When the browser looks into the storage of clicks requesting attribution, it could compare the metadata on the conversion with the filter specified on that ad click. These would either “match” or “not-match”. There are two possible approaches that come to mind for what to do in the event that they do-not-match.

Do not attribute this conversion event to this click. Continue checking the other clicks that requested attribution, and if none match, do not generate an anonymous conversion report at all.
Attribute the conversion to the click, but set the first “conversion-metadata” bit to zero to indicate “did not match the specified filter”.

Privacy Considerations

This proposal does not rely on any change to the total entropy contained in anonymous conversion reports, or how the bits are distributed. Platform vendors have already taken stances about how many bits to allow for representing both campaign_id as well as conversion_metadata, and this proposal should not affect those choices. Since this does not propose to change the bit entropy in conversion reports, we do not believe this proposal meaningfully impacts user privacy.

What this does do is allow websites with complex advertising campaigns and large product catalogs to more effectively utilize those bits of entropy to support common use cases.

[csharrison]

Hey Ben,
Thanks for this proposal, I believe it more or less aligns with the existing privacy in the event level API. In principle, you could "polyfill" some of this idea by spinning up a reporting domain per category of interest and converting users through the applicable domain.

However, this idea does make a class of attacks easier to pull off. At a high level with this proposal, each conversion report can include more information than they could before (implicit in the fact that it matched), at the expense of losing out on more non-matching conversions. i.e. you have a smaller probability of learning more about a user.

A concrete attack where the advertiser can match against a list could look like this:

• User clicks 10 times with impressions marked with category 1 through 10
• On the conversion side the advertiser looks at my 1p cookie and chooses to always convert categories {1, 3, 5, 7} for me
• In this way, 10 clicks leads to 10 bits of leakage from advertiser --> publisher.

Obviously, it's possible to pass 10 bits of information about a user id from 10 bits in the existing design, but it either:

• Requires explicitly abusing the reporting domain functionality
• Requires taking more time to pull off, since the bits you can forward need to be global, in a sense (i.e. on Tuesdays, convert users that have a 1 as their ith bit,...).

There might be potential mitigations here, either by limiting the domain of the categories (e.g. they can only be in the range 1-10), or by simplifying the matching rule to be a bit less expressive.

[apasel422]

The API now includes positive and negative filters: https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-attribution-filters

[csharrison]

Closing as fixed