Last Conversion vs Multiple Conversions

[johnwilander]

The Click Through Conversion Measurement Event-Level API proposal supports 3 conversions to be reported as outlined in in the section Multiple conversions for the same impression. PCM on the other hand only reports one conversion, often referred to as last conversion or last click.

What multiple conversions means is for instance a customer who clicks an ad for a product, configures the product on the landing site (conversion 1), adds it to the cart (conversion 2), enters shipping info (conversion 3), enters payment info (conversion 4), and finalizes the purchase (conversion 5).

In the case of PCM, only one of these conversions can ever be be reported in an attribution request whereas the Click Through Conversion Measurement Event-Level API would support up to 3. I’m not sure there is anything to merge here but it is a difference in the two proposals.

To discuss:

• Is the 3-bit conversion-metadata in the Click Through Conversion Measurement Event-Level API picked to make it hard/impossible to stitch together these 3 reports into a single identifier? What makes it hard is that bits would have to be used to signal ordering since the reports are sent out with a random 24-48 hour delay.

[johnwilander]

Ping @michaelkleber @csharrison.

[csharrison]

Hey John, actually in our design we avoided doing the 24-48 hour delay for this "multiple conversions" use-case, to avoid learning ordering in many cases even across longer periods of time. Our report delay is structured in terms of 3 "report windows" measured from click time: https://github.com/csharrison/conversion-measurement-api#sending-scheduled-reports. I'll note that this form of delay is less useful in a PCM context where click-time data is more hidden.

For merging, I wonder if a "many per click" model is something that we could consider adding in some form to PCM if we reduce conversion side bits. For instance, a model with 6 bits on the impression side and 3 bits on the conversion side, with 3 possible conversions per click. If PCM supports many-per-click, we might be able to consider a simplified unified design without the "priority" feature.

Of course, we'd need to evaluate the utility difference of this idea vs. current PCM vs. increasing impression-side bits (https://github.com/WICG/ad-click-attribution/issues/28). What do you think?

cc @johnivdel

[johnwilander]

Hey John, actually in our design we avoided doing the 24-48 hour delay for this "multiple conversions" use-case, to avoid learning ordering in many cases even across longer periods of time. Our report delay is structured in terms of 3 "report windows" measured from click time: https://github.com/csharrison/conversion-measurement-api#sending-scheduled-reports. I'll note that this form of delay is less useful in a PCM context where click-time data is more hidden.

I see. You seem to also drop the 24 hours of randomness to when the report is sent. That randomness is a privacy-enhancing design choice of ours since it makes sure that the timing of the report does not convey any information about when the ad click or conversion happened, other than that they must have happened before the 7-day expiry.

If I read your proposal correctly, the reports are sent at a static time, 2 or 7 days after the ad click (if the browser is running). That sounds like inherently reporting the time of the ad click. Would you agree? Since you also propose a 64-bit identifier on the ad click side, such static report scheduling does not worsen privacy for you, but it would for us.

If we were to support some kind of multiple conversion reporting, we would have to keep the random delay and would also have to make sure reports can not be naturally ordered.

For merging, I wonder if a "many per click" model is something that we could consider adding in some form to PCM if we reduce conversion side bits. For instance, a model with 6 bits on the impression side and 3 bits on the conversion side, with 3 possible conversions per click. If PCM supports many-per-click, we might be able to consider a simplified unified design without the "priority" feature.

That was my thinking too. And since we've already considered a 4+4+4 model for PCM, we could probably converge on an 8+3 model in PCM and 64+3 for the Chrome add-on (maybe even (64+8)+3 depending on how how you'd handle PCM's existing 8-bit campaign ID).

Of course, we'd need to evaluate the utility difference of this idea vs. current PCM vs. increasing impression-side bits (#28). What do you think?

The two invariants we have are:

• The timing of the report(s) must not convey time of day for the ad click or the conversion. If advertisers want time of day, they need to spend campaign ID bits and/or conversion bits on it.
• The ordering of multiple reports (should we support them) must be random and the conversion value bits few enough to not be able to carry ordering information with room to spare. If ordering can be inferred, a user ID could be stitched together through the conversion values of multiple reports.

As a straw man for a revised PCM, supporting multiple conversions:

• 8-bit campaign ID
• 3-bit conversion ID
• 24 hour conversion time window, starting from the first conversion
• Up to 3 conversions, all triggered within the 24 hour time window
• Reporting scheduled after the time window has passed
• 24-48 hour delay to reporting
• Up to 3 report request in random order

Would you be able to layer your things on top of that?

Multiple conversions complicate several things, for instance the spending of Trust Tokens and the privacy analysis. Thus, we may very well stick with one conversion report which would look like this if we converge on "more bits on the ad campaign side is what advertisers want:"

• 8-bit campaign ID
• 4-bit conversion ID [The rest like the existing spec]
• The conversion with the highest priority scheduled before the ad click is consumed
• 24-48 hour delay to reporting

Would you be able to layer your things on top that?

[csharrison]

If I read your proposal correctly, the reports are sent at a static time, 2 or 7 days after the ad click (if the browser is running). That sounds like inherently reporting the time of the ad click. Would you agree? Since you also propose a 64-bit identifier on the ad click side, such static report scheduling does not worsen privacy for you, but it would for us.

Yes I agree, this isn't a suitable mechanism for PCM in general. It's possible by amending these windows to include noise they would be acceptable for both designs though.

Regarding your strawman proposal, I don't think they satisfy the same many-per-click use case we intended. For our use-cases, we wanted to support conversions that happen more than 24hr after the first conversion. This is also why our design required the more complicated reporting windows, so that ordering can only be inferred if the conversions occur across different windows. In our design, conversions can be reported until the impression expires.

[johnwilander]

If I read your proposal correctly, the reports are sent at a static time, 2 or 7 days after the ad click (if the browser is running). That sounds like inherently reporting the time of the ad click. Would you agree? Since you also propose a 64-bit identifier on the ad click side, such static report scheduling does not worsen privacy for you, but it would for us.

Yes I agree, this isn't a suitable mechanism for PCM in general. It's possible by amending these windows to include noise they would be acceptable for both designs though.

Regarding your strawman proposal, I don't think they satisfy the same many-per-click use case we intended. For our use-cases, we wanted to support conversions that happen more than 24hr after the first conversion. This is also why our design required the more complicated reporting windows, so that ordering can only be inferred if the conversions occur across different windows. In our design, conversions can be reported until the impression expires.

I see. Do you see a path forward for layering your reporting mechanism on top of ours (in any of the forms I outlined) or would your spec rather replace our reporting mechanism?

[csharrison]

I think I see a path forward to combine some level of fixed reporting windows + noise, although it's possible we'd want a different level of noise than you might.

I'll try to update this thread as @johnivdel and I hash out a concrete proposal.

[hober]

Given the idea to shift from 6-6 to 3-8 in #28, could we use the remaining bit to have two conversions?