Privacy Sandbox on Android: Attribution API Guide

Google's Privacy Sandbox on Android is one of the most significant changes to mobile advertising infrastructure in years. Like Apple's ATT and SKAdNetwork on iOS, it is moving the industry away from device-level identifiers toward privacy-preserving measurement APIs. Unlike Apple's approach, the Android Privacy Sandbox has been slower to roll out and more iterative in its development.

This guide explains the Attribution Reporting API, how it works technically, where it stands today, and what practical steps you should be taking now.

The Problem Being Solved

Android's advertising ecosystem has long depended on the Android Advertising ID (AAID), a resettable device-level identifier that ad networks use to match clicks to installs and in-app events. While users can reset or opt out of the AAID, most historically did not, giving ad networks near-universal coverage.

Growing regulatory pressure under GDPR, CCPA, and other privacy laws, combined with increasing user awareness of tracking, pushed Google to act. The goal of Privacy Sandbox is to let advertising and measurement continue to work in aggregate while preventing individual user tracking across apps.

This is a narrower objective than eliminating advertising. Google's business depends on advertising. The Privacy Sandbox APIs are designed to preserve the aggregate signal needed for ad optimization while removing the individual-level signal that enables cross-app tracking.

The Attribution Reporting API

The Attribution Reporting API (ARA) is the core of what replaces the AAID for attribution purposes on Android. It works at the operating system level, handling click-to-install and click-to-event matching on the device without exposing individual user data to ad networks.

How It Works

Source registration: When a user clicks an ad, the ad network registers an "attribution source" with the OS. This registration includes the ad network's endpoint, a source event ID, and expiry settings.

Trigger registration: When the user installs the app and completes an in-app event, the app registers an "attribution trigger" with the OS. The trigger includes information about what event occurred (install, purchase, level complete, etc.).

Matching: The OS matches sources to triggers using the registered data. This matching happens on-device. No party outside the device sees individual-level data during this process.

Reporting: The OS sends attribution reports to the ad network's registered endpoint. These reports come in two types: event-level reports (delayed, with limited data) and aggregatable reports (for summary statistics with differential privacy noise added).

Event-Level Reports

Event-level reports give you limited signal per attribution: a source event ID and a small trigger data value (3 bits, so 8 possible values). They are intended for ad optimization use cases where you need to know an install occurred but do not need rich conversion data.

Reports are delayed by a randomized amount (1-2 days for install events) and a small percentage of reports contain fake data intentionally, as a privacy protection.

Aggregatable Reports

Aggregatable reports use cryptographic techniques to allow aggregate statistics without individual-level reconstruction. You get summary reports showing totals across a campaign, but the underlying reports are encrypted and can only be decrypted by a trusted aggregation service.

Google operates an aggregation service. There are also plans for third-party aggregation services. The summary data includes differential privacy noise, meaning small campaigns may see significant statistical uncertainty in their numbers.

For detailed technical specifications, see Google's Attribution Reporting API documentation and the Privacy Sandbox on Android developer site.

Topics API

The Topics API is a separate component of Privacy Sandbox that relates to interest-based advertising rather than attribution directly. It assigns devices to a small set of high-level interest categories (Topics) based on recent app usage, without exposing the underlying browsing or usage history.

Ad networks can query the Topics API to retrieve a few topics associated with the current device, which they can use for ad targeting. This replaces behavioral targeting based on cross-app tracking.

For attribution specifically, Topics is less directly relevant than the Attribution Reporting API. But understanding it helps you see the full scope of what Privacy Sandbox is replacing.

Current Timeline and Status

Privacy Sandbox on Android has had a longer and more uncertain timeline than Apple's equivalent changes. Here is where things stand as of early 2026:

Developer preview and beta: Google has been running developer previews since 2022. The APIs are available on Android 13+ devices that have opted in, and on Android 14+ with broader availability.

No forced deprecation yet: Unlike Apple, which set a hard deadline with ATT, Google has not announced a hard date for deprecating the AAID or requiring apps to use Privacy Sandbox APIs. The current guidance is to treat this as a transition period.

Enrollment requirement: To use Privacy Sandbox APIs in production, your app and SDK need to complete Google's enrollment process. This involves registering your organization and agreeing to Privacy Sandbox policies.

The slow timeline has caused some uncertainty in the industry. Some teams have deprioritized Privacy Sandbox preparation because the deadline keeps moving. This is a mistake. The direction is clear even if the timing is not. Building measurement infrastructure that works with privacy-preserving APIs is the right long-term investment.

How Privacy Sandbox Affects Mobile Measurement

The shift from AAID-based attribution to Privacy Sandbox APIs changes several things about how mobile measurement works.

Reduced click-to-event fidelity: You will no longer receive individual-level reports with full conversion details. The event-level reports have limited data (8 possible trigger values) and introduce noise. Rich conversion data that you might currently pass through attribution postbacks (revenue amount, subscription tier, etc.) does not fit cleanly into this model.

Aggregation requirement for detailed data: To get detailed aggregate statistics, you need to use the aggregatable report flow with a trusted aggregation service. This adds infrastructure complexity and introduces aggregation noise.

No cross-app tracking: The fundamental constraint is that ad networks cannot combine data across different apps at the individual level. Each attribution is siloed. This prevents the broader behavioral profiles that underpinned many optimization strategies.

Measurement for first-party attribution: Attribution for your own marketing (owned channels, email, push notifications) is generally not affected by Privacy Sandbox. These channels have direct relationships with your users and typically rely on your own user identifiers rather than the AAID.

Preparing for the Transition

Audit Your Attribution Stack

Start by inventorying where AAID appears in your data pipeline. This includes:

Your MMP SDK integration
Any ad network SDKs in your app
Your server-side attribution logic
Your analytics and reporting systems

Understand which flows currently depend on AAID-based matching and which could work with aggregated or probabilistic alternatives.

Test with Privacy Sandbox APIs

Register for the Privacy Sandbox developer program and test your attribution flows on devices with the APIs enabled. The earlier you test, the more time you have to find gaps between what the APIs provide and what your current measurement setup depends on.

Update Your Conversion Value Schema

Just as with SKAdNetwork on iOS, you need a deliberate strategy for what to encode in the limited trigger data fields. Identify the 8 most important states (event-level) or the metrics you want to aggregate (aggregatable reports) before you need them in production.

Plan for More Statistical Uncertainty

Privacy Sandbox data is noisier than AAID-based data. Your reporting and decision-making processes need to account for this. For small campaigns, you may not have statistically reliable data from aggregatable reports. Build in minimum thresholds below which you treat campaign data as directional rather than precise.

Evaluate Your MMP's Privacy Sandbox Support

Your mobile measurement partner needs to have integrated the Attribution Reporting API for you to receive Privacy Sandbox attribution data in your existing dashboards. Check their roadmap and current support status. Tolinku's attribution infrastructure is built to work alongside both SKAN on iOS and Privacy Sandbox on Android.

See Tolinku's attribution concepts documentation for platform-specific guidance, and the analytics features page for current capabilities.

What Does Not Change

Despite the significant changes, several aspects of mobile attribution remain the same:

First-party analytics: Events you log within your own app using your own user identifiers are unaffected. Your product analytics, retention tracking, and revenue reporting continue to work as before.

Web-to-app flows: These are handled differently and have their own set of challenges. See our guide on web-to-app attribution for details.

Users who consent: If users grant consent under your app's privacy policy (separate from AAID opt-in), you can still use the AAID for attribution for those users. The constraint is cross-app tracking without consent, not all attribution.

Internal campaign measurement: Attribution for your own push notifications, in-app messages, and owned channels does not require AAID and is not affected by Privacy Sandbox.

The Broader Picture

Privacy Sandbox on Android and SKAdNetwork on iOS are converging toward a similar model: aggregated, delayed, noisy attribution data for paid advertising, with richer deterministic data available for owned channels and opted-in users.

This is not the end of mobile attribution. It is a significant change to how it works. Teams that adapt their measurement strategies early will be in a better position when the transition fully arrives.

The teams that will struggle are those that continue treating AAID-based attribution as indefinitely available, or that try to find workarounds (fingerprinting, probabilistic matching without consent) that violate the spirit and potentially the letter of these new frameworks.