How will ASTRAPIA's reliance on Aggregate Reporting/Conversion Measurement API support IVT use cases?

[acomets]

Most of the IVT detection we do today is based on post-bid signals that feed more or less complex anomaly detection models. Information is processed by breaking down on one or more dimensions, to identify offenders that we want to block pre-bid and post-bid. The computation can be done in real-time or offline, depending on the complexity of the model.

We are concerned that the ASTRAPIA proposal in its current form will not cover those needs as it relies on the Aggregate Reporting API and the Conversion Measurement API for human analysis and post-bid models. We see this as presenting the following limitations:

• The latency of the data would not allow supporting IVT use cases, especially post-bid models, for which being able to react quickly to detected IVT is critical (typically within a few minutes).
• For example, some of our rules-based filtration models block traffic in real-time, i.e. typically with a 5-minute delay, e.g. detecting IP3 subnetworks going rogue and generating a spike in clicks.
• It is unclear whether the granularity would be sufficient to address IVT needs, in particular, whether we are able to access all the dimensions we rely on today (IP, User-Agent, other user and device-level identifiers), and the ability to cross several dimensions.
• Depending on the level of noise added, it could make it difficult to interpret the data, and in particular with conversions, which are a very robust signal that can often be considered as the "ground truth".
• Still, regarding conversions, the lack of flexibility around attribution models (up to the browser vendor if I am correct) will cause issues as this is a reliable signal to vet the quality of traffic. See related issue.

How does this proposal plan to address those limitations?