Reporting window, attribution expiry and trigger priorities in the event-level API

[alois-bissuel]

Hi,

It seems that there is an inconsistency in the way the event-level API is handling time windows when using priorities for attribution triggers. It seems that the browser deciding unilaterally to send reports at the end of the reporting window before attribution expiry will produce some unwanted behaviors when tracking different triggers with different priorities. Please correct me if my understanding of it is not good.

Let me produce a simple example. Let say an advertising company, adtech.com, is trying to measure the effectiveness of its ads. To do so, it uses two intent types, the number of events done on the advertiser's website and the number of sales. The latter is a better measure of the effectiveness of the ad, so adtech.com decides to track both using a priority system, with an attribution expiry of 7 days.

Now consider the following case: A user clicks on an ad and immediately starts to browse the advertiser's website, doing more than three events, but does not buy anything. Three days later, they buy something.

Now because there is a reporting window at two days, all attribution reports of the first visit events are sent at this time, preventing the priority system to allow the attribution of the later sale trigger. To me, this is an undesirable behavior, as had adtech.com decided to track only sales, the later sale would have been properly attributed to the first click.

A solution to this paradox would be to get rid of the intermediary reporting window system, and to use the attribution expiry only, to get consistent results when using priorities.

What do you think?

[csharrison]

@alois-bissuel thank you for filing. This is the intended behavior of the priority system and I agree it is not perfect for all scenarios. We introduced it to allow for prioritization within a given window, not to allow prioritization across windows.

While getting rid of the intermediary reporting windows would indeed solve this, it breaks other use-cases that rely on the windows to get faster data, especially for campaigns that have long lookback windows.

There are a few other solutions we could consider:

1. Make the intermediate windows optional / configurable in the API via some new API surface
2. Allow more fine grained controls that depend on existing conversion state like "drop this conversion if there are equal or higher priority ones in the queue for this reporting window.

Reporting window configurability has come up before as a feature request (https://github.com/WICG/conversion-measurement-api/issues/47), so (1) might be a good solution to this.

[alois-bissuel]

Thanks for the quick answer, and sorry for not following it up right away.

I am not sure I follow the second solution. Isn't it the very role of priorities for dropping conversion in the queue? I have another proposal for solving this, which I will do in a separate issue.

[csharrison]

I am not sure I follow the second solution. Isn't it the very role of priorities for dropping conversion in the queue?

Yes, but the existing proposal is heavy handed. We only drop / re-order conversions if we've hit a maximum. The alternative I suggested in (2) would allow you to say something like "only allow one low priority conversion per reporting window, to save room later for high priority ones" vs. the existing system which would force you to use up all your conversions on low priority ones if they all come in the same window.

[csharrison]

We discussed this in the meeting today (will post the minutes shortly). My takeaway from the conversion was:

1. @johnivdel mentions that the dedupe key functionality could be used to make sure that only a single low priority conversion can be attributed to a given impression. You could imagine extending this idea to have a dedupe key for each priority and have a maximum of 1 conversion per priority bucket, if you wanted to. This is a fairly blunt instrument but it seems very useful in tackling this problem.
2. We could introduce a mechanism to optionally remove the intermediate reporting windows for a given source event, meaning that reports will be delayed until the source event expires. This explicitly trades off accuracy and data timeliness.
3. We could do something more complicated than the above two solutions.

Since (1) is already spec'd and implemented, it would be great if that totally solves the issue. Good feedback to have would be:

• Is (1) sufficient to solve this problem?
• If not, does augmenting it with (2) help sufficiently?
• If not, let's brainstorm alternative solutions :)

cc @angelinaeng FYI.

[csharrison]

Hey @alois-bissuel , do you think this issue can be closed out with the proposal to allow 100% configuration of the reporting windows at https://github.com/WICG/attribution-reporting-api/pull/856? This allows you to "opt in" to removing the intermediate reporting window system.

[alois-bissuel]

If we remove intermediate windows, indeed this question exists no more. As long as we keep #700 on our radar, I am fine with closing this issue I guess.