[Aggregate API] Tracking multiple trigger types

[alois-bissuel]

Splitting the budget in the aggregate API can be difficult especially when tracking multiple trigger types with one type which we want to fire only once per source.
For the sake of the argumentation, we will take an adtech example, but I believe the issue is relevant for other use cases.
An advertiser (or the adtech acting on its behalf) may want to know if users really clicked on its ads, then browsed on its site and finally bought a product. In other words, the advertiser/adtech wants to track two type of trigger events:

1. a landing, ie that the user did at least visit the website after clicking (in other words it is not a misclick)
2. a sale action (it could be any other desired action on the website though, such as registering to a newsletter, etc).

For reporting purposes, advertisers are interested in having a landing fired only once per click.

In my current understanding of the aggregate API, it is hard to cover this use case easily. There are some hacky ways to do it, but ultimately they do not really fit the bill:

1. Use a priority and deduplication system (as proposed in Allow prioritization in summary reports? #472). Pros: easy to implement and mirrors the event-level API. Cons: limited to a window size of roughly 10 minutes as told in the doc, hence it does not cover the use case (if a user stays more than 10 minutes on the website, and we generate landing keys for every page of the site, then we will burn the budget).
2. Advertiser/adtech endpoints are stateful, and fire a landing event only once per "session". Pros: no further complication of the API. Cons: same as 1. (ie that it does not really cover our use case), but this time the window size is configurable. Also a big complexity increase for users of the API.

What I am proposing is to add a predefined (at source registration time) budget per key. The sum of budgets should not exceed L1. We should find a graceful way out if they do. Budget tracking will be done per key and per source, ie any contribution (at key-level) will be silently dropped if the key budget or the total budget is exhausted.

Another way out would be the mechanism proposed by @johnivdel in #373, if filtering by key is allowed.

Thanks a lot for your comments and inputs on this problem!

P.S. Tagging #485 as this issue is somewhat about budgeting in the aggregate API.

[linnan-github]

Thanks for all the discussions in the meeting.

We propose to introduce a deduplication system for aggregate API, similar to that currently supported in event-level API.

The ad-tech can specify a deduplication key by adding a new field aggregatable_deduplication_key to the Attribution-Reporting-Register-Trigger header, which will be used to deduplicate multiple triggers which contain the same aggregatable_deduplication_key for a single source.

aggregatable_deduplication_key is per source and stored until expiry and therefore is not subject to the reporting window constraints. At trigger time, the browser will create aggregatable reports for a source only if the trigger’s aggregatable_deduplication_key has not already been associated with an aggregatable report for that source, no matter whether the report has been sent or not.

A separate deduplication key for aggregate API gives ad-techs more flexibility in how they control the event-level and aggregatable reports.

[alois-bissuel]

Sorry for the very late answer.
It looks like this mechanism should enable most of our use cases.

A quick question though: would a source have only one dedup_key associated to it, or several?