Most of the privacy-attribution conversation over the last three years has been about iOS. ATT, SKAdNetwork, conversion values, the disappearing IDFA. For a market that is overwhelmingly Android, that focus has always been slightly misplaced. The change that matters most is now arriving on Android itself, through the Privacy Sandbox.
The scale of the mismatch is worth stating plainly. Across installs processed on Linkrunner over a recent 30-day window, around 97 per cent were on Android and only around 3 per cent on iOS. For an India-heavy app base, an Android privacy framework is not a side note. It is the main event.
This post explains what the Android Privacy Sandbox Attribution Reporting API is, how it compares to SKAN, what it could change for your measurement, and what to do now. The short version on the last point: prepare, but do not tear anything out yet.
What Is the Android Privacy Sandbox Attribution Reporting API?
Attribution Reporting API: the Android Privacy Sandbox component that measures ad-driven conversions through on-device matching and privacy-preserving aggregate and event-level reports, designed to reduce reliance on cross-app identifiers such as the Google Advertising ID (GAID).
It sits inside the wider Privacy Sandbox on Android programme, Google's effort to limit cross-app tracking while keeping ad measurement workable. The web version of Privacy Sandbox has had more attention, but the Android measurement APIs are the part that touches mobile app attribution directly.
On rollout: treat it as a gradual, opt-in-then-default transition rather than a single switch-on date. The sensible posture is to assume it lands during the planning horizon you are budgeting for now, not years away.
Why Android Is Getting a Privacy Framework Now
The direction of travel is the same one Apple set: reduce how much measurement depends on a stable, cross-app device identifier.
-
On Android that identifier is the GAID, and the Privacy Sandbox is built to make attribution work even as access to it narrows.
-
The deterministic Google Play Install Referrer is the mechanism most Android attribution leans on today, and it is the thing worth watching as the model shifts.
-
Because Linkrunner's own base runs around 97 per cent Android, this is the framework that lands hardest for India-first teams, far more than any iOS change has.
This is also where a common setup risk shows up. Across Android-heavy onboardings we routinely see attribution that leans almost entirely on the deterministic install referrer, with no aggregate-reporting fallback planned. That single dependency is exactly what the Privacy Sandbox shift puts pressure on, which is why understanding mobile attribution in today's privacy landscape matters before the change forces the question.
How the Attribution Reporting API Compares to SKAN
If you have learned SKAN, the shape will feel familiar, but the details differ.
-
Aggregate vs event-level reports. The API produces both privacy-preserving summary (aggregate) reports and noised event-level reports. SKAN gives you postbacks with a conversion value envelope; the API gives you two report types with different granularity and privacy trade-offs.
-
On-device matching with added noise. Like SKAN, matching happens on the device and statistical noise is added to protect individuals. You read trends, not clean per-user truth.
-
Reporting delays. Expect deliberate delays, similar in spirit to SKAN postback timing, so same-day optimisation on these signals is not the design goal.
-
What stays deterministic today. The install referrer path still works right now. The transition is about reducing reliance on GAID over time, not deleting deterministic Android attribution overnight.
For the iOS side of this same privacy arc, our SKAN 4.0 decoding framework covers the conversion-value mechanics in detail.
Tech Explainer: aggregate vs event-level reports. Aggregate reports answer "how much value did this campaign drive?" across many conversions, with noise that washes out at volume. Event-level reports tie a small, noised signal to an individual ad interaction, useful for coarse optimisation. Neither gives you a clean one-to-one click-to-install record, which is the whole point.
What Could Break for App Marketers
The risk is not that attribution stops. It is that the parts you quietly depend on get coarser.
-
Deterministic install referrer attribution could carry less of the load if GAID access narrows, pushing more measurement into aggregate reports.
-
Channel-level granularity may soften under aggregated reporting, making fine-grained, campaign-by-campaign reads harder for low-volume campaigns.
-
Re-engagement and view-through measurement on Android may need rethinking, since both lean on identifiers the Sandbox is designed to limit.
-
Low-volume campaigns feel privacy thresholds first, the same pattern marketers already recognise from SKAN crowd-anonymity limits described in our post-IDFA user journey guide.
What App Teams Should Do Now
A practical checklist, in order:
-
Audit your Android dependency. Work out how much of your current Android attribution rests on GAID versus the install referrer. If you cannot answer this, that is the first gap to close.
-
Keep schemas portable. Design conversion and event schemas so they work across both a deterministic model and an aggregate model. Avoid setups that only make sense with per-user identifiers.
-
Confirm your MMP roadmap. Ask your measurement provider directly whether Attribution Reporting API ingestion is on the roadmap and when.
-
Do not rip anything out. The deterministic path works today. Premature migration costs you accuracy you still have. This is the same "predict and prepare, don't panic" logic behind predictive attribution.
How to validate this in your MMP
-
Pull your Android installs and check the split between install-referrer-attributed and GAID-dependent attribution.
-
Confirm your conversion events still map cleanly if a channel moves to aggregate-only reporting.
-
Review your postback configuration so the events you send stay meaningful under coarser reporting.
How This Looks Inside an MMP
The marketer should not have to choose the measurement path by hand. The framework decision is plumbing, and plumbing belongs to the tool.
Platforms like Linkrunner are built to absorb the Android transition by ingesting both install-referrer-based deterministic attribution and Attribution Reporting API summary reports into one Android view, so the framework choice stays invisible in your reporting. The job of the MMP here is to make sure that as the deterministic signal softens, your dashboard degrades gracefully into aggregate truth rather than going dark.
FAQ
Is the Android Privacy Sandbox the same thing as SKAN for Android?
Not exactly. It plays a similar role, privacy-preserving, on-device, report-based measurement, but it uses Google's aggregate and event-level report model rather than Apple's postback and conversion-value model.
Will the Attribution Reporting API replace the Google Play Install Referrer?
There is no announced removal of the install referrer. Treat the API as an additional, privacy-preserving measurement path that reduces reliance on cross-app identifiers over time, not a same-day replacement for deterministic attribution.
Does this affect Android attribution today?
For most teams, deterministic Android attribution still works as it does now. The point of acting early is to remove single-point dependencies before the rollout forces the issue.
How much added reporting delay should I expect?
Expect deliberate delays similar in spirit to SKAN postback timing. Build your optimisation routine around trends rather than same-hour reads on these signals.
Does the Privacy Sandbox change apply to apps or only to Chrome and the web?
There are separate web and Android tracks. The Attribution Reporting API on Android is the app-relevant one, which is why mobile-first, Android-heavy teams should care about it specifically.
The Takeaway
Three years of privacy work focused on the smaller side of an India-heavy market. The Android Privacy Sandbox corrects that, and for teams running roughly 97 per cent of installs on Android, it is the change worth preparing for now. Audit your GAID dependency, keep your schemas portable, and confirm your MMP will ingest the new reports. Do not migrate anything prematurely.
If you want to see how a unified, deterministic-first MMP is planning to absorb the deterministic-to-aggregate transition into one Android view, request a demo from Linkrunner. A good place to start is auditing exactly how much of your current Android attribution depends on a single identifier, before the framework makes that decision for you.