Consider sending aggregate error reports for event-level reports

[johnivdel]

There are a number of failure modes which can be difficult to observe due to the delayed reporting mechanism, and opaque way the browser handles sources and triggers for event level reports.

Some examples are:

• a source declares the wrong attributiondestination, causing the browser to drop the source
• a given user hits the report rate limit, causing all subsequent reports to not be sent in the time period
• a source is removed due to the pending destination limit

In these cases, there is no straight-forward way for a developer to monitor this behavior outside of inferring they aren't receiving as many reports as they would normally.

It's possible the API could proactively send reports for these types of errors in parallel. To prevent cross-site information from being revealed the browser could send very little information in the error reports, for example just revealing {reporting_origin,error_code}.

It could also be possible to create and send the error reports similar to aggregate reports.

[maudnals]

A few other cases raised in the 6/28 meeting:

• Tag is misconfigured
• The endpoint fails
• ...

[maudnals]

Note about the scope of this issue: In Chrome, local debugging is partly supported:

• Issues (console warnings) are thrown for a number of developer errors
• A debugging UI is available at chrome://conversion-internals What remains uncovered is "at-scale" debugging: how to detect what's going wrong in prod / for end-users?

One API that takes care of this is the Reporting API⏤it may not be suited here because it's document-scoped. One interesting feature it used to have was a failover mechanism. This would only help mitigate endpoint server failure. AFAIK this feature was removed in the API v1 due to its complexity (?). clelland would be the right person to ask, will document further here in this issue.

[linnan-github]

Currently Attribution Reporting API supports extended debugging reports that will be deprecated alongside the deprecation of third-party cookies.

As a non-cookie based mechanism, the error reports may allow developers to monitor the failures and help them better measure the API performance.

Without revealing any cross site information, as a first step, the browser could send reports in the following source registration failure modes:

• a source is rejected due to the reporting origin limits
• a source is rejected due to the destination limit

These enforcements are functions of only publisher site activity, therefore it is possible to reveal the source event id in the report data (see below).

The browser will send a non-credentialed secure HTTP POST request to a new endpoint:

https://<reporting origin>/.well-known/attribution-reporting/error

The report data is included in the request body as a JSON object:

{
  "type": "<report type>", // could be "unattributed-reporting-origin-limit" or "source-destination-limit"
  "body": {
    "limit": 100, // a constant integer
    "source_event_id": "<source event id in the source registration>",
    "source_site": "https://source.example",
    "destination_site": "https://destination.example",
    "reporting_origin": "https://reporting.example.com"
  }
}

These error reports may receive some small delay upon the error occurring during source registration.

The ad-techs may opt in to receive these error reports by adding a new field to Attribution-Reporting-Register-Source header:

{
  ...,
  "error_reporting": true // default to false if not present
}

It may also be desirable for publisher sites to observe these failures. In this case, the publisher site may opt in to receive error reports by declaring a reporting endpoint via a HTTP header in the top-level document response:

Attribution-Error-Reporting-Endpoint: <reporting endpoint>

The report data is identical to what is sent to the ad-tech. The publisher would not be able to interpret the source event id, but that is potentially still useful to be included in the report data.