Translate IVT from source to trigger

[baz1]

Hello,

An important feature that the Google Ad Traffic Quality team would like the APIs to support is the ability to translate IVT (Invalid Traffic) decisions from source to trigger. We currently rely on some defenses that, in some cases, mark conversions as invalid when attributed to an invalid click. Such translation also needs to be accessible for IVT identified at various latencies.

In the current state of the attribution reporting APIs, such IVT translation is supported out-of-the-box in the event-level API. The only solution on the aggregate side would be to make the IVT decision at click time, and opt-out of using the API for invalid clicks, which does not satisfy the requirements below).

The requested feature would support the following capabilities in the aggregate API:

• Conversion counts can be re-queried 3 times, to account for late-IVT
• The latest re-computation could happen up to one month after the source event
• For each computation, the AdTech organization can provide a list of valid or invalid source events to include/exclude in the aggregates
• Optionally, also be able to measure the amount of invalid conversions, instead of just valid conversions

[csharrison]

Thanks @baz1 . The requerying use-case we're tracking in https://github.com/WICG/attribution-reporting-api/issues/716 so I think we can handle that separately. The rest of the use-case makes sense to me, thank you for filing.

One follow-up question. We have some designs (e.g. report verification) which attempt to filter out IVT as classified by the trigger context. This proposal supports filtering out IVT as classified by the source context. Is there a third type of filtering which needs to look at the joint information across an attributed source + trigger contexts? How important is that?

[baz1]

One notable benefit of having either report verification, or filtering based on a list of valid trigger contexts, would be to have a way to prevent fake trigger reports at the root, without having to rely on (most likely imperfect) heuristics. While fake trigger reports might not be a concern today, it seems like an important improvement for the long term.

That aside, the benefit of having the trigger context in addition to the source context seems moderate. While not nearly as important as the source context for fraud prevention purposes, it could still be useful to collect additional behavioral signals at conversion time and to ensure that the browser is the same between source and trigger.

[Saeedazimi69]

Saeed