1 | Feature | Description | Estimated availability in beta (new releases posted here) | Version availability expected in header response (if applicable) | Estimated API version (Ad Services Extension version) | Code example or further detail | |
|---|---|---|---|---|---|---|---|
2 | 1 | OR trigger filters | Filters now consist of a filter set, which is a list of filter maps. An event_trigger_data object is ignored if none of the filter maps in the set match the source's filter data. | Available | 5 | ``` Attribution-Reporting-Register-Trigger: { ... "event_trigger_data": [ { "trigger_data": "2", "filters": [ {"bar": ["x"], "foo": ["1", "2", "3"]}, // OR {"bar": ["y"], "foo": ["4", "5", "6"]} ] }, ] } ``` * This change is backward compatible and will be supported by all filter fields in the API. | |
3 | 2 | Decouple Impression Expiry and Reporting window for Aggregation & Event level API | Will be same feature as Privacy Sandbox for Web: https://github.com/WICG/attribution-reporting-api/issues/522 | Available | 6 | N/A | |
4 | 3 | Aggregate Dedupe Keys with Filters | Support deduplication key for aggregatable reports | Available | 6 | Similar to deduplication_keys in event_trigger_data (Event API). We will support deduplication key for Aggregate API. ``` Attribution-Reporting-Register-Trigger { … aggregatable_deduplication_keys: [ { deduplication_key": "1", "filters": { "bar": [A] } }, … { "deduplication_key": "2", "filters": [{ "foo": [C, D] }] } ] } ``` * Deduplication Key: "[unsigned 64-bit integer]" | |
5 | 4 | scheduled_time in event reports | We will add scheduled_report_time to event reports, same as Privacy Sandbox for Web: https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#attribution-reports | Available | 6 | ||
6 | 5 | Cross-Network Attribution without redirects | See this section of the explainer. | Available | 6 | See this section of the developer guide. | |
7 | 6 | Multi destination support for web destinations | Allow repeated "web_destination" field in small batches (up to 3), and remove validation that redirects must list the same web_destination. No changes to app destination (we still accept only 1 app package name, and redirects must list the same app). | Available | 7 | ||
8 | 7 | Support both daisy chain and Attribution-Reporting-Redirects for the same registration call, and update redirect limit to 20 | If an API call has both Attribution-Reporting-Redirect and daisy chain (302) redirects listed, we will first follow the redirects in Attribution-Reporting-Redirect, then the daisy chain, up until we reach the 20 redirect limit. | Available | 7 | ||
9 | 8 | Redirects (either in Attribution-Reporting-Redirect or 302 daisy-chain) will be followed even if the original source registration is not called by an enrolled ad-tech. | Available | 7 | |||
10 | 9 | Verbose debugging reports (first set including source verbose reports) | Will be the same verbose debug reports supported by Privacy Sandbox for Web: https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md | Available | 7 | ||
11 | 10 | App<>Web debugging | To enable debug reports for App<>Web or Web>Web cross-app, you will need to provide an AdID on the web registration, and you will need access to AdID on the app registration. | Available | 7 | ||
12 | 11 | Move to origin-based attribution and add new rate limits | Attribution is based on origin used for registration, multiple origins accepted under a single site, and add a new one origin per {source app, enrollment} rate limit. | Available | 7 | ||
13 | 12 | Verbose debugging reports (remaining) | Will be the same verbose debug reports supported by Privacy Sandbox for Web: https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md | Available | 7 | ||
14 | 13 | Add coarse_event_report_destinations field to source registration | Added to reduce noise applied to event-level reports for cross app and web attribution. If this field is set to "true", all possible destinations across app and web will be included in the event-level report. | Available | 7 | ||
15 | 14 | Shared source debugs keys for cross-network attribution without redirects | Allow the serving ad-tech to set a shared_debug_key on their source registration to facilitate debugging capabilities for third-parties | Available | 8 | In order to support debugging for cross-network attribution without redirects, an additional field, shared_debug_key, is available for adtechs to set upon source registration. If set on the original source registration, it will also be set on the corresponding derived source as debug_key during XNA trigger registration. This debug key is attached as source_debug_key in both event and aggregate reports. This debug feature will only be supported for cross-network attribution without redirects under the following scenarios: - App to app measurement where AdId is permitted - App to web measurement where AdId is permitted and matching across both the app source and the web trigger - Web to web measurement (on the same browser app) when ar_debug is present on both source and trigger | |
16 | 15 | Reduce max # of contributions in agg reports from 50 to 20 | Available | 8 | |||
17 | 16 | Limit number of reports per aggregatable source to 20 | Will be same feature as Privacy Sandbox for Web: https://github.com/WICG/attribution-reporting-api/pull/779 | Available | 8 | ||
18 | 17 | registerWebSource, registerWebTrigger, registerSource and registerTrigger should use strings for fields that expect a numeric value (e.g. priority, source_event_id, debug_key, trigger_data, deduplication_key, etc.) | For registerWebSource, registerWebTrigger, registerSource and registerTrigger, we will follow the same behavior as documented for Privacy Sandbox for Web: https://wicg.github.io/attribution-reporting-api/#parse-source-registration-json | Available | 8 | ||
19 | 18 | Flexible event lite | See this explainer. | Available | 8 | ||
20 | 19 | Shared Filter Field for XNA without Redirects | Optional field ad techs can use to specify which filters of their source side parameters they are giving MMPs the ability to use for filtering in aggregate summary reports. Specific to the cross-network attribution without redirects option, where ad techs provide a shared aggregation key to MMPs. | Available | 202310 | 9 | |
21 | 20 | Android versioning support in header response | A new header field is 'Version' is sent in HTTP POST requests to indicate which Android version the device supports., and by extension which features are available. Version will be formatted as YYYYMM, indicating the month that an Android version was rolled out. A feature released in this version would be offered to 100% of devices by day 1 of the following month, so MM+1. Versioning support only applies for features that were released from Oct 2023 onwards. Additionally, having a version specificed in the the http request does not necessarily mean that a given feature released in that version is enabled. Please refer to column D for more more details on how quickly features will be ramping to 100%. | Available | 202310 | 9 | |
22 | 21 | Protected Audience Integration | Enables adtechs to receive aggregate summary reports (via the Attribution Reporting API) with custom audience dimensions in order to evaluate ROI across remarketing tactics | Available | 202311 | 10 | |
23 | 22 | Multi-cloud support for Aggregation Service | Support GCP as a cloud provider | Available | n/a | n/a | |
24 | 23 | Lookback window in trigger filters | https://github.com/WICG/attribution-reporting-api/issues/769 | Available | 202401 | 10 | |
25 | 24 | Preinstall check | During source registration, ad tech can indicates whether they want API to discard the source if the app is already installed. | Available | 202401 | 10 | During source registration, an ad tech can indicate whether they want to discard the source if the advertiser app (in the app destination specified) is already installed by setting "drop_source_if_installed" in the response header. "Attribution-Reporting-Register-Source": { "source_event_id": "12340873490", "destination": "android-app://com.example.measurement.notinstalled", "expiry": "1728000", "priority": "10", "drop_source_if_installed": true } If this bit is set to "true" and the API has observed a verified install of the app, the source will be marked for deletion. Note that the source will be registered and then discarded so that a verbose source success report can be sent and fake reports can be generated as necessary for privacy preserving reasons. This deletion logic will also propagate down to any MMP ad techs who may be registering derived sources on the ad tech’s behalf for Cross-network attribution without redirects. |
26 | 25 | Updates to trigger verbose debug reporting | Receipt of trigger verbose reports will be conditioned on having AdId available at both source and trigger time (previously this was at trigger time only) | Available | 202402 | 11 | |
27 | 26 | Support 302 redirects to a .well-known path | Optionally send 302 redirects to a .well-known path. This in intended to help 3P web measurement providers better test app-to-web measurement on ARA via a new background redirect path to .well-known endpoints (while keeping the foreground path to ensure existing click tracking measurement is not broken). Ad techs will need to opt-in via a new header. | Available | 202403 | 11 | |
28 | 27 | Support trigger context ID in aggregate reports (and support for unconditional, immediate aggregatable reports) | A new field, "trigger_context_id" will be supported in trigger registration. It can be a high-entropy ID that represents data associated with the trigger. This ID will be embedded unencrypted in the aggregatable report. To avoid leaking cross-site information through the count of reports with the given ID, the browser will unconditionally send an aggregatable report immediately on every trigger registration with a trigger context ID. A null report will be sent in the case that the trigger registration did not generate an attribution report. The source registration time will always be excluded from the aggregatable report with a trigger context ID. | Available | 202406 | 12 | |
29 | 28 | Remove foreground check for triggers | Currently the app must be in the foreground to register a source or trigger. This change will remove the foreground check for registering triggers. | Available | N/A (rolled out separately from API version) | ||
30 | 29 | Android header validation tool | Verify that the structure of response-based headers will result in successful source and trigger registration. If the header is not configured properly, the tool will also specify what needs to be changed. | Available | Available | Find the tool here. There is also a Chrome version of this tool for web ARA registrations | |
31 | 30 | Flexible event-level configurations | Varying the number and frequency of event-level reports is already supported. This launch will add in the ability to change trigger data cardinality and values. | Available | 202409 | 14 | |
32 | 31 | Change max destinations covered by unexpired sources to favor new sources | Favor new sources after the unique destination rate limit is hit. | Available | 202409 | 14 | |
33 | 32 | Reinstall attribution support | When the Attribution Reporting API detects that a given app install is actually a reinstall, it will treat the conversion as a post-install trigger, not an app install. If the winning source for the reinstall has a post_install_exclusivity_window specified, it will be ignored. | Early Nov 2024 (saturation reached ~Jan) | 202409 | 14 | In order for the API to use the reinstall signal when it performs attribution for a given ad tech, that ad tech needs to have: - previously received a report from the API - for a conversion in the relevant advertiser app - within the past 90 days |
34 | 33 | Aggregate debugging reports | https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md | Early Mar 2025 (saturation reached ~May 2025) | 202502 | 15 | |
35 | 34 | Attribution scope (pre-attribution filters) | Attribution filters currently are applied post-attribution and work to suppress reports if filters don’t match. This feature moves resolving filters to happen pre-attribution. | Available | 202411 | 15 | |
36 | 35 | Flexible contribution filtering IDs | More details here | Early Feb 2025 (saturation reached ~April) | 202501 | 15 |
1 | Note: Feature requests listed below are subject to further change or be deprioritized as we receive feedback from the ecosystem. You can provide feedback on the new feature requests here. | |||
|---|---|---|---|---|
2 | Feature | Description | Current Status | |
3 | 1 | Event reporting for cross-network attribition without redirects | Adtechs who register derived sources (typically MMPs) can receive event level reporting | Not actively exploring |
4 | 2 | Early Conversion window | Sources that do not drive a conversion within an early window are dropped and no longer eligible for future conversions | Not actively exploring |
5 | 3 | Guided Trigger Redirects | Serving ad-techs can independently optimize L1 budgets for winning cross-network attribution conversions | Initial discovery and design exploration underway |
6 | 4 | Data discrepancy reporting | Ad techs can reason discrepancies in cross-network attributed vs. self-attributed reporting (e.g. why didn’t I win?) | Initial discovery and design exploration underway |
7 | 5 | Reinstall support | API can distinguish a first install from a reinstall and attribute credit accordingly | Included in upcoming features |
8 | 6 | Reattribution | After a certain inactivity period, a conversion event can be re-attributed to another source from a re-engagement campaign. | Initial discovery and design exploration underway |
9 | 7 | Preloads | Enable adtechs to attribute install credit to OEMs or APKs for preloaded apps | Initial discovery and design exploration underway |
10 | 8 | View verification | Platform verification for views and engaged views | Initial discovery and design exploration underway |
11 | 9 | Assist Reporting | Serving adtechs can receive non-winning conversion postbacks | Not actively exploring |
12 | 10 | Install timestamp | Support install timestamp in aggregate reporting so it doesn't contribute to use of privacy budget | Not actively exploring |
13 | 11 | Install attributed filter | Apply different business logic depending on whether or not winning source for a post-install conversion is also the source that drove the initial app install. Potential examples: - Apply a longer lookback window - Select specific trigger data for their event-level report - Exclude trigger from event-level reporting | Not actively exploring |
1 | Issue | Estimated fix in beta (new releases posted here) | Version availability expected in header response (if applicable) |
|---|---|---|---|
2 | Attribution Reporting API is available in the March beta release, but had been previously disabled in the January release. If you used the Attribution Reporting API on the previous Beta release, clear your app or device data before using this Beta release using one of the following steps outlined in the release notes | March 2023 | |
3 | Aggregate keys that use more than 120 bits will be clipped (last byte - 8 bits - will be clipped) | May 2023 | |
4 | As of September, for registerSource and registerTrigger, the following fields must be formatted as strings. Previously these fields could be formatted as integers. If they are not updated to be formatted as strings, source/trigger event registration will fail. Source - source_event_id - event_report_window - aggregatable_report_window - priority Trigger - trigger_data - priority - deduplication_key | This format change took effect starting in September 2023 | |
5 | The API will reject non-https registration URIs. If using non-https, the calling app will need to update registration URIs to https or they may crash if they are not handling the error. | January 2024 (~100% by Feb 1) | 202401 |