johnwilander
commented
4 years ago Hi Ben! Thanks for filing.
Hi @johnwilander and @hober!
This is an idea that we brought up on the web-adv W3C call. @hober thanked us for explaining the use-case 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.
This is not the case. For a conversion report to be scheduled and sent, these things need to line up (using your store examples):
- An ad click must have happened on megastore.com navigating the user to shaveco.example and pushing an ad campaign ID into the internal PCM database in the browser.
- An HTTP GET request to megastore.com must happen on shaveco.example and be directed according to the conversion triggering procedure.
If the above happens, a conversion report is scheduled and later sent with these four pieces of data:
- megastore.com as the click source by virtue of being the destination of the request.
- shaveco.example as the click destination and the conversion site by virtue of being the referrer header.
- The campaign ID from the ad click.
- The conversion ID from the HTTP GET request.
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’”
This sounds complex to me and introduces new classes of data. I believe what you're requesting could be achieved through just the campaign ID. Say the click destination (in your example shaveco.example) can express "Trigger a conversion report if this conversion matches a stored ad click for campaign IDs [a, b, c …]" or "Trigger a conversion report if this conversion does not match a stored ad click for campaign IDs [x, y, z …]" in the HTTP GET request. Would that solve the issue you describe?
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.
We have to be careful here. Clever filter use could potentially achieve unique reports per user and thus reveal to the click destination site that a particular conversion was due to an ad click of a specific ad campaign on a specific click source site. That goes against the design goals of this proposal.
Limited complexity is our friend here. The more vectors and variations we allow, the higher the risk is for a combination of feature uses to open up for cross-site tracking of individual users.
benjaminsavage
Hi @johnwilander and @hober!
This is an idea that we brought up on the web-adv W3C call. @hober thanked us for explaining the use-case 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:
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.