Mobile App Conversion Tracking: iOS, Android & Cross-Platform

75 to 85% of your iOS users are invisible. Not "harder to track." Invisible. That is the share who decline the App Tracking Transparency prompt, and once they decline it, the IDFA you would use to stitch their journey across apps simply does not exist for you. Industry opt-in rates have sat in the 15 to 25% range for years now, and they are not climbing.

I have set up mobile measurement on both sides of this, a B2B SaaS app and a high-volume B2C consumer app, and I will be blunt: most "mobile app conversion tracking" content is written as if iOS is the whole story. It is not. iOS, Android, and web-to-app are three different privacy regimes with three different failure modes, and pretending they are one topic is why so many teams optimize on a slice of data and call it the truth.

This is not an iOS-ATT explainer. This is a cross-platform measurement post:

• How much data you are actually missing on each surface.
• Why the data you do keep is dirtier than you think.
• How to choose an attribution stack instead of cargo-culting AppsFlyer because everyone else did.

DataCops sits in this conversation as the architectural piece most stacks skip: a first-party, filtered pipeline that decides what is real before any conversion signal trains Meta or Google. That includes fraud traffic validation at ingestion and a first-party consent layer so consented signal is recovered, not lost. For the setup side, see mobile app attribution configuration. Hold that thought, it matters more at the end.

Quick stuff people keep asking

How do I track conversions in a mobile app? Three layers. An attribution SDK (AppsFlyer, Adjust, Branch, Singular) to assign install and event credit. The platform-native paths: SKAdNetwork or AdAttributionKit on iOS, Google Play install referrer and GAID on Android. And a server-side events layer so conversions reach Meta and Google CAPI without depending on a fragile client SDK call. Skip the third layer and you lose signal exactly where it counts.

What is the best mobile app attribution platform? There is no single best. AppsFlyer has the deepest integration network. Adjust is strong on fraud and clean dashboards. Branch owns deep linking and web-to-app. Singular is the one to beat for cost analytics and marketing-mix modeling. The right pick depends on app type, not on a feature scoreboard.

How does iOS App Tracking Transparency affect measurement? It gates the IDFA behind a permission prompt. Decline it, and you have no cross-app deterministic identifier for that user. With opt-in at 15 to 25%, that means three out of four iOS users have to be measured through SKAdNetwork's aggregated, delayed, privacy-preserving data instead. Less signal, slower signal.

What is SKAdNetwork and how does it work? Apple's privacy-preserving attribution framework. The ad network registers, the install gets attributed without exposing the individual user, and you receive a conversion value postback after a delay, often 24 to 72 hours. SKAN 4 added multiple postback windows and coarse and fine conversion values, which helps, but it is still aggregated and still delayed. You cannot tie a SKAN conversion to a specific person.

How do I track cross-platform conversions between web and mobile app? This is the hardest gap. A user finds you on mobile web, installs the app days later, converts in-app. Without deferred deep linking and a consistent identity layer, those become two unrelated sessions and the web channel that started the journey gets zero credit. Branch and AppsFlyer both do deferred deep linking; you still need server-side identity to fuse the two sides.

What percentage of iOS users allow app tracking? 15 to 25%, depending on vertical and how well you prompt. Gaming tends higher, finance lower. Plan your stack around 80% of iOS being SKAN-only and you will not be surprised.

How do I set up Google Ads conversion tracking for mobile apps? Link Google Ads to your attribution SDK or to Firebase, define your in-app conversion events, and forward them server-side. On iOS you are still bounded by SKAN. On Android you have GAID until consent says otherwise, and the Play install referrer for deterministic install attribution.

The gap: you are optimizing on a contaminated minority

Here is the measurement reality, surface by surface, with numbers.

iOS. 75 to 85% of users decline ATT. For those users you get SKAN: aggregated, delayed 24 to 72 hours, capped conversion-value granularity. You can run an app on this, but you cannot do precise user-level optimization on it. The 15 to 25% who opt in are not a random sample either, they skew toward more engaged, more trusting users. So your "good data" is a biased slice.

Android

Friendlier today. GAID still works, the Play install referrer gives deterministic install attribution. But the Privacy Sandbox on Android is doing to GAID what ATT did to IDFA, slowly. Treat Android's current visibility as a melting asset, not a permanent one.

Web-to-app

The silent killer. Hybrid products lose the entire web-to-install bridge unless deferred deep linking and a shared identity layer are in place. The web channel that sourced the user shows nothing; the install looks organic; budget gets cut from the channel that actually worked.

Now the part the SDK vendors do not put on the pricing page. The slice of data you do keep is contaminated. Mobile invalid traffic, install fraud, click flooding, SDK spoofing, bot-driven installs, runs in the 24 to 31% range. Think about what that stacks up to. You are already down to a minority of real visibility because of ATT. Then a quarter to a third of that minority is not human.

Picture a fraud-detection honeypot a SaaS team ran. Roughly 3,000 signups came through. When they pulled the device fingerprints and IP reputation apart, 77% were fraudulent. 650 of those "users" traced back to a single device fingerprint. One machine, wearing 650 faces. If those signups had flowed into the app's conversion events, the attribution SDK would have happily credited them to whichever campaign delivered them, and the ad platform would have been told: this campaign produces converting users, find more like them.

That is the trap. Your attribution SDK assigns credit. It does not, by default, ask whether the converting "user" was a person. Most of the tools in this category, AppsFlyer, Adjust, Branch, Singular, have fraud-prevention modules, and they catch a real share of the obvious stuff. But the architecture is still: collect everything client-side, attribute it, forward it. The validation, if any, is bolted on, not built into the foundation.

This is the root cause, and it is the same one behind every measurement failure: data flows through third-party SDK scripts with no isolation and no quality gate before it leaves your infrastructure for Meta and Google. Mixed data, real users and bots and fraud, all going out the same pipe with the same confidence.

The architectural fix is to filter and isolate at the source. DataCops runs a first-party pipeline on your own subdomain, validates session and signup traffic against a 361.8 billion-plus IP reputation database at ingestion, and separates two data tiers before anything leaves you: anonymous session analytics that flow unconditionally, and identifiable conversion data. SignUp Cops applies identity intelligence at the signup moment, which is exactly where the 77%-fraud honeypot story gets caught. Then CAPI delivery to Meta, Google, TikTok, and LinkedIn ships from data that has already been screened. The attribution SDK still does attribution. It just stops being handed bots to attribute.

Choosing your attribution stack

Match the stack to the app, not to the loudest brand.

SKAdNetwork-first

The right baseline for any iOS app with meaningful paid UA. It is privacy-durable and Apple is not removing it. Accept the delay and the coarse conversion values, design your conversion-value schema deliberately, and treat SKAN as your iOS floor.

Probabilistic attribution

Fills the gap SKAN leaves, modeling likely attribution from signals like IP and timestamp. Useful, but it is an estimate, and Apple's stance on fingerprinting keeps narrowing what is allowed. Treat probabilistic as a supplement, never your system of record.

Server-side / CAPI. This is the layer most teams under-invest in. Sending conversion events server-side to Meta and Google, instead of relying on a client SDK call that can be blocked, dropped, or never fire, is what keeps your signal alive as client-side measurement keeps degrading. It is also the only layer where you can insert a quality gate before the data leaves you.

A reasonable 2026 stack for a paid-heavy app: SKAN as the iOS baseline, an attribution SDK for deterministic Android and deep-link credit, a server-side CAPI layer for durable delivery, and a filtering layer so the events you forward are screened first.

Decision guide

Pure iOS consumer app, heavy paid UA? SKAN-first, careful conversion-value schema, AppsFlyer or Adjust for the SDK layer.

Hybrid web-plus-app product? Deferred deep linking is non-negotiable. Branch or AppsFlyer, plus a shared server-side identity layer, or you lose the entire web-to-install bridge.

Android-first app? Use GAID and the Play install referrer now, but architect for the Privacy Sandbox. Do not build anything that breaks when GAID tightens.

Spending real money on Meta and Google UA? Add a server-side CAPI layer and a filtering layer before it. Unfiltered mobile conversions at 24 to 31% IVT will quietly poison your campaign optimization.

B2B SaaS with app-based signups? Identity intelligence at signup matters more than install attribution. Screen the account-creation moment.

Tiny budget, one platform? Firebase plus the native platform conversion path. Do not buy a four-figure SDK contract for an app that is not spending yet.

You are measuring the wrong thing precisely

The mistake I see constantly: teams pour energy into squeezing the last 2% of attribution accuracy out of SKAN while ignoring that 24 to 31% of the conversions they are measuring were never human. They tune the instrument and never check whether the thing it is pointed at is real.

Cross-platform mobile measurement is not about reclaiming the iOS users ATT took away. They are not coming back. It is about being honest that you are working with a minority of visibility, and then making sure that minority is clean before it trains a billion-dollar ad algorithm to go find more of "those users."

So here is the question to take into your next stand-up. Of the mobile conversions you reported last month, what share can you actually prove were human, and what is your evidence? If the answer is "the SDK said so," you do not have an answer. You have a guess that Meta is spending your budget on.