MaskedLARK: Range restriction on conversion data restricts use-cases

[csharrison]

In the MaskedLARK proposal, there is only a small enum of potential conversion-side values ("purchase", "visit time", etc). This is fairly restrictive for some reporting use-cases. For example, a large advertiser might want to report on precisely which product (out of thousands) in their catalog was purchased, which would likely require huge value vectors.

I think at the very least this should be documented in the proposal, although I totally see why it is left out of scope.

[jpfeiffe]

Thanks Charlie -- our initial thinking on this is features such as product would be provided within the aggregation_key (e.g. {"product" : "toothbrush"}) part of the scope, not within the aggregation_values. Such a query might then have terms like "aggregation_service_queries" : {"product" : "toothbrush", "campaign" : 100}, and return the types of conversions that were produced (monetary or whatever). It gets tricky to think about aggregation where some of the values are in the aggregation_key and some are in the aggregation_value, and then we're summing over different aggregation_value.

To your point, the actual product landed on might of course not be available until the advertiser's site. Perhaps allowing the .well_known URL to respond with both aggregation_keys and aggregation_values would solve this?