Attribution Reporting API

Definition

The Attribution Reporting API was a Google API for Chrome and Android that measured ad conversions by registering ad clicks as sources and conversions as triggers, then returning noised event-level and aggregate reports, and it was retired in October 2025.

It was the Privacy Sandbox's answer to attribution without cross-party identifiers, and the closest thing the web and Android had to SKAdNetwork. Google announced its retirement on 17 October 2025, on both Chrome and Android. It is documented here because the design is still the clearest illustration of how noised attribution works, and because a great deal of live vendor documentation still presents it as forthcoming.

Status first

How it worked: sources and triggers

The model is worth knowing on its own terms, because every identifier-free attribution system converges on something like it. An ad click registers a source; a conversion registers a trigger; the browser or OS performs the join privately and emits a deliberately degraded report.

HTTP/1.1 200 OK
Attribution-Reporting-Register-Source: {
  "destination": "android-app://com.example.shop",
  "source_event_id": "84259648135568",
  "expiry": "2592000",
  "priority": "100",
  "filter_data": { "campaign": ["spring_sale"] },
  "aggregation_keys": { "campaignCounts": "0x159" }
}

HTTP/1.1 200 OK
Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [{
    "trigger_data": "3",
    "priority": "100",
    "filters": { "campaign": ["spring_sale"] }
  }],
  "aggregatable_trigger_data": [{
    "key_piece": "0x400",
    "source_keys": ["campaignCounts"]
  }],
  "aggregatable_values": { "campaignCounts": 32768 }
}

Why it never took hold

• Operational cost. Aggregatable reports required running or contracting an aggregation service with trusted execution environments, a significant burden for anything short of a large ad network.
• No deadline. Once Google decided to retain third-party cookies in Chrome, the reason to absorb that cost disappeared.
• Noise budgets. Privacy budgets constrained how many queries you could run against a cohort, making everyday reporting slices unavailable.
• Bit budget. Three bits, plus randomised response, gave less usable signal than the identifiers it replaced.
• Android arrived late. The Android implementation never left preview, so nobody built production Android measurement on it.

The contrast with Apple is instructive: SKAdNetwork got adopted despite comparable limitations because the IDFA was removed at the same time. An identifier-free API only wins when the identifier goes away, and on Android it never did.

What replaces it

The honest summary is that Android measurement did not move to a privacy-preserving aggregate model at all — it stayed where it was. That is a better outcome for anyone whose attribution is built on first-party link data, and a worse one for anyone who deferred that work waiting for the platform to solve it.

# App code and manifests
grep -rn "attribution-reporting\|AttributionReporting\|adservices" \
  --include="*.kt" --include="*.java" --include="*.xml" app/src

# Server side: response headers you may still be emitting
grep -rn "Attribution-Reporting-Register" server/

# HTML for the web side
grep -rn "attributionsrc" web/