Currently, aggregatable reports in the API come with a randomized delay of (10 mins, 1 hour), though often due to offline users or inactive browsers the delay can be much larger. This delay serves to protect whether any particular user had an attributed conversion, which is cross site data. However, if aggregatable reports leaked less cross-site data, they could be delivered with reduced delay.

In this issue I propose reducing the delay in the API to something like ~0-10 minutes instead of ~10-60 minutes.

We can do this by taking ideas from issue 439 and introducing null reports for some fraction trigger registrations, to reduce the total amount of cross-site information embedded in a report. Currently, as a lot of the cross site information is embedded in the existing source_registration_time field, we are also thinking of making this field optional as part of this change. E.g. in the trigger registration JSON:

{
  aggregatable_source_registration_time: "omit" // or "include"
  ...
}

If the source_registration_time field is present, the null report rate will need be higher. Currently we are thinking of something like ~0.05 reports (in expectation) for triggers which don’t specify the source registration time, and ~0.25 reports if they do.

Note: ideally this level of configuration would be done globally at the reporting origin level rather than the trigger level, but that would require introducing global configuration to the API across users. This is something we might explore in the future, so any feedback where we’d want to vary this across an ad-tech / reporting origin would be useful.

We also think that in the future, embedding the source_registration_time inside the encrypted payload would improve the situation here and reduce the amount of null reports. For this reason we think defaulting to omitting this field makes sense.