Android Privacy Sandbox: Upcoming changes to Attribution Reporting API


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
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
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.	Early Oct 2024 (saturation reached ~Dec)	202409
32	31	Change max destinations covered by unexpired sources to favor new sources	Favor new sources after the unique destination rate limit is hit.	Early Oct 2024 (saturation reached ~Dec)	202409
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		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 X days (TBD)
34	33	3PC (ar_debug) availability signal in event-level and aggregatable reports	Add a new header "trigger-debugging-available" to outgoing event-level and aggregatable reports to signify whether 3PC (ar_debug) was available at trigger registration time. Header will be added to any report where the source had a web destination set. The goal is to allow API callers to identify whether the report represents a conversion that was measureable via 3PCs or not.	Early Oct 2024 (saturation reached ~Dec)	202409
35	34	Aggregate debugging reports	https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md	Early Dec 2024 (saturation reached ~Feb 2025)	202411
36	35	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.	Early Dec 2024 (saturation reached ~Feb 2025)	202411
37	36	Flexible contribution filtering IDs	More details here	Early Feb 2025 (saturation reached ~April)	202501


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