Consider reducing the ad attribution data budget to 3 bits

[johnwilander]

(And bumping the campaign ID budget up accordingly.)

PCM proposes a 6-bit value encoding the conversion on the click destination side. The Click Through Conversion Measurement Event-Level API proposal has a corresponding 3-bit value called conversion-metadata. Ideally, we’d reconcile this into something simple for developers.

To discuss:

• Would 3 bits on click destination side work across the board? PCM would obviously be fine with it since it reduces entropy.
• PCM would probably consider a bump on the click source side to 8 bits if 3 bits were agreed upon on the click destination side. Would that we welcome?

[johnwilander]

Ping @michaelkleber @csharrison.

[benjaminsavage]

PCM would probably consider a bump on the click source side to 8 bits if 3 bits were agreed upon on the click destination side. Would that we welcome?

The discussion on #11 indicated support for a 4+4+4 split (so potentially 8 and 4). I would welcome that.

In practice, the 64 ad campaigns limit will be more problematic for us than the reduction in the fidelity of the conversion value.

[jinghao]

Agreed with @benjaminsavage. Larger domains will have a lot of campaigns, especially the marketplaces like Target or Shopify that have lots of uncoordinated advertisers running their own campaigns. My preference would be 9-3 over 6-6 because that would give us ~500 campaigns per domain and also align the conversion metadata spec with the Chrome proposal.

[jinghao]

@johnwilander Hi! For planning purposes, it would be helpful to understand where we ended up here. Thanks!

[johnwilander]

I landed 8+4 bits for PCM in WebKit today: https://trac.webkit.org/changeset/270456

That is, 8 bits for the source ID (previously campaign ID) and 4 bits for the trigger data (previously conversion value).

[johnwilander]

This has now been updated in the spec too: https://github.com/privacycg/private-click-measurement/commit/f7e51bebbedc90419d6e39ea7cebb1d8ab687cc3