Ping @michaelkleber @csharrison. I'm using the "Layering" label for all the issues related to layering PCM and the Click Through Conversion Measurement Event-Level API.

Good question!

Coming out of our discussions at TPAC, I had expected we'd want a single spec with "optional" steps in a single processing model, and descriptive names chosen to make it clear what a spec-compliant browser might still choose to ignore. The single-spec idea seems to me easier for developers (and implementers!) to understand, at least. What do we gain by having two layered specs instead?

This all needs to eventually end up in the HTML spec after incubation anyway, so whatever else we decide, we probably want to write a single document that will be merged into HTML instead of two.

Our thinking is that PCM needs to do what it says on the tin, i.e. private click measurement. This means if a browser says it supports PCM or a browser setting says it enables PCM, it should be with the privacy implications of PCM, not PCM plus the additional 64-bit impression-data on top. It also means if a developer reads up on PCM, they should see the privacy-preserving click measurement that the spec is about.

Even if our two specs get pulled into HTML, I expect them to live on separately. Do you not?

Hmm, I'd like to get someone with more standards experience to weigh in on the layering issues, then — I'm not well informed here. I'll seek out more voices.

It doesn't sound to me like you would want to spec each of PCM and another impression-level-identifier on top of it, because then Chrome would end up implementing both of them, contrary to your "what it says on the tin" goal.

In conversion-measurement-api version, @csharrison proposed that the impression data would "be limited to 64 bits of information, encoded as a hexadecimal string. This value can vary by UA." Could we meet your goals by firming up this variability, with language like: "A user agent that wants to implement Private Click Measurement must mask out all but the first 6 bits of this impression data. A user agent that wants to allow Event-Level Click Measurement must mask out anything beyond the first 64 bits, and may choose a limit smaller than 64 bits."

Then each of PCM and ELCM would have a spec'd meaning, and we could get just one id in the DOM instead of two.

We’d rather have a cross-browser spec that provides privacy, and then a Chrome-only spec to remove some of that privacy. Instead of a less private spec and the a separate all-but Chrome spec to add more restrictions. Otherwise it gives the false impression that the 64 but version has multi implementor support, which it does not.

Okay, that makes the goals clearer. In particular it means that we should try to get agreement as large as possible and make this spec describe cross-browser behavior as much as we can. I don't know whether layering or forking will be a better way to spell out the eventual irreconcilable differences, but let's make there be as few as possible in either case.

For the size of the adCampaignId specifically, both 6-bit and 64-bit are arbitrary numbers, as came up in our TAG review and in the 8+3-bit and 8+4 or 4+8-bit possibilities mentioned in this repo. Other implementers might prefer fewer bits even than Safari, and a Chromium implementation ought to be built with enough flexibility that different embedders get to exercise their own judgement.

This pushes me back to thinking that we ought to:

1. Spec that the browser truncates the click-time metadata, rather than dropping clicks. (This is probably easier if the value is explicitly hex, so we can define behavior in terms of bits and the transformation is easy to see.)

2. Add a parameter to the conversion report indicating how many bits of information were allowed in the click-time id, so that the server can handle a range of possible answers. (This will be easy with a JSON-based report structure.)

3. Add some language about what bit-count limits you feel must be in place to meet your privacy goals, so that the spec describes the envelope that experimentation can happen within. The goal here is to foster useful iterative discussion between browser developers and API users.

I'm happy to propose a PR with these changes, so we can discuss concretely.

We're not aware of a browser other than Chrome that wants a wider or narrower campaign ID or freedom to experiment. It seems like there's really only two bit counts of interest: lots (Chrome) and very few (every other browser that has spoken up so far).

So there's little benefit to making the spec open-ended. It's also an interop benefit if there are fewer different possibilities. (Of course, if anyone else shows up actually wanting to implement a different number of bits, we can discuss it.)

I think a separate extra campaign ID field for Chrome in a separate spec, plus a hook in this spec to send extra data at reporting time, would be better than truncation. Then servers collecting attribution info only have to consider two possibilities, and implementations don't face an interop hazard due to choosing an oddball value.

We have agreed on trying to layer the two proposals. Details are tracking in individual issues so this umbrella is no longer needed.