How Do You Track App Signups and Subscriptions After iOS Privacy Changes?

Attribution on iOS stopped being a reporting problem and became a modelling problem. The ad network now tells you roughly how many installs a campaign produced, your own database tells you exactly who paid, and nothing connects the two at the person level for most of your users.

Consent is the first number to settle on, and the published figures disagree. AppsFlyer’s four-year analysis of App Tracking Transparency puts global consent at around 50% of users, roughly 10 points above where it sat when the framework launched in April 2021. Adjust’s Q1 2026 iOS benchmark puts it at about 38%, up from roughly 35% a year earlier. Plan against the lower figure.

What actually changed on iOS, and what still works?

What changed is that App Tracking Transparency removed the default right to read a device identifier, so the click-to-install chain ad platforms were built on now exists only for users who tapped Allow. Everything downstream of that chain degraded at the same time: cohort reporting, lookalike audiences, and the day-7 and day-30 ROAS numbers media buyers used to optimise against.

Three things survived untouched and they are the foundation of any setup that works now. Your own in-app events, because a trial start recorded in your own backend needs no identifier. Your subscription revenue, because the store tells you what was charged. And aggregate totals, because the number of installs and new subscribers you got last week is a fact regardless of which campaign gets credit.

What broke is the join between them. Apple replaced it with privacy-preserving frameworks that report in aggregate, on a delay, with values coarse enough that individuals cannot be re-identified. That is a different kind of data, not a worse version of the old data, and setups that treat it as a degraded IDFA tend to produce confident numbers that are wrong.

Android is moving the same way through the Privacy Sandbox, so a measurement stack built only for the iOS problem will need rebuilding again. Treat the first-party layer as the permanent part and the network frameworks as the part that changes every year.

What is SKAN and what does it tell you about subscriptions?

SKAN is Apple’s privacy-preserving attribution API. After an install, your app calls an update function to set a conversion value, a single small integer describing what the new user did, and Apple sends a postback to the ad network and your measurement partner after a randomised delay.

The fine conversion value runs from 0 to 63, which is six bits for everything you might want to know about a new user. SKAN 4 added tiers: clear Apple’s crowd anonymity threshold for that campaign and you get the fine value, fall below it and you get a coarse value or nothing, with source identifiers stripped as well.

That threshold is the part that catches subscription apps. Spend is usually spread across many campaigns, geographies and ad groups, and each combination has to earn enough installs on its own before Apple will release detail about it. The practical effect is that small and newly launched campaigns report least, which is exactly when you most want to know what is happening.

Subscription revenue makes it worse, because the measurement window closes long before an annual plan renews or a 14-day trial converts. Mapping conversion values to dollars is therefore a mistake. Map them to the earliest in-app behaviour that predicts revenue: onboarding completion, paywall view, trial start.

Read SKAN as a channel allocation tool with a known error bar, not as a source of truth about revenue. It answers which campaign probably deserves credit for a burst of installs. It does not answer what those users are worth.

What is AdAttributionKit, and do you need it yet?

AdAttributionKit is Apple’s successor to SKAN, introduced at WWDC 2024 and extended at WWDC 2025 with capabilities that matter more to subscription apps than to anyone else. RevenueCat’s guide to the framework sets out the differences: re-engagement attribution, web-to-app journeys, support for alternative app marketplaces, and 64-bit conversion values in place of SKAN’s six bits.

Re-engagement is the capability worth paying attention to. SKAN only ever measured new installs, so any campaign aimed at winning back a lapsed subscriber was unmeasurable by design. Win-back is a large share of subscription economics, and AdAttributionKit is the first privacy-preserving way to see it.

Apple has announced no deprecation date for SKAN, and both frameworks can run in the same app. The sensible position in 2026 is to support both and let your measurement partner reconcile the postbacks, rather than migrating off a framework the ad networks still optimise against.

What this does not change is the shape of the problem. Conversion values get bigger and the windows get a little more useful, and you are still receiving aggregate, delayed, threshold-gated reports about the first few days of a user’s life. The long tail stays in your own data.

Do you need an MMP, or is the ad platform dashboard enough?

You need a mobile measurement partner as soon as you run more than one paid channel, because platform dashboards each take credit for the same install. Meta reports what Meta believes it drove, TikTok does the same, and the two numbers added together regularly exceed the installs your app actually received.

An MMP, meaning AppsFlyer, Adjust, Singular, Branch or similar, does three jobs a dashboard cannot. It deduplicates across networks under one attribution rule, it handles SKAN and AdAttributionKit postbacks including the modelling that fills threshold gaps, and it joins install cohorts to the subscription events you send it.

One channel at low spend is a legitimate reason to wait, because the dashboard is directionally fine there and the integration work is a real cost. The moment a second channel goes live, or somebody asks what blended CAC is, the dashboards stop reconciling and no spreadsheet work fixes it.

The three layers answer different questions, and confusing them is where most reporting arguments start.

Layer	What it tells you	What it cannot tell you
SKAN and AdAttributionKit	Which campaign probably produced a burst of installs	What those users are worth
Your own first-party events	Exactly who started a trial, converted and renewed	Which ad they came from
Incrementality testing	What the channel actually caused	Which creative or audience caused it

Whichever you use, your subscription platform needs to be wired to it in both directions. Install cohorts flowing in, trial and renewal events flowing back out, so that paid cohorts can be read against revenue rather than against installs.

That wiring is the piece most often deferred, until the data is already a year old and unusable. We set it up as part of running an app launch end to end.

How do you measure trials and subscriptions when installs are all you get?

You measure them in your own stack and stop expecting the ad network to do it. Trial starts, install-to-trial rate, trial-to-paid conversion, renewals, cancellations and refunds are all first-party events, unaffected by consent and not delayed by any postback window.

Those numbers also give you benchmarks you can hold yourself to without any attribution at all. RevenueCat’s State of Subscription Apps 2026 puts median day-35 download-to-paid conversion in North America at 2.6%, with the top quartile above 5.6%. You can calculate your own version of that figure from store and subscription data alone.

The useful mental model is two ledgers that meet at the cohort. The network ledger says roughly how many installs each campaign produced in a week. Your ledger says exactly how many trials, conversions and dollars that week’s installs generated. Join them weekly at cohort level and you get a defensible cost per paying user.

What you give up is per-user certainty, and you should stop trying to buy it back. Modelled attribution dashboards that report cost per subscriber to two decimal places are stating a confidence the underlying data cannot support.

How do you prove a channel is working when attribution is incomplete?

You prove a channel is working by running an incrementality test, which is the only method that does not need identifiers. Switch the channel off in a set of matched geographies for two to four weeks, keep everything else constant, and compare total installs and total new subscribers between the test and control regions.

Incrementality answers the question attribution only approximates: what would have happened anyway. A channel can look excellent in a dashboard and prove to have been harvesting users who would have found you through store search. Only a holdout exposes that.

Blended numbers belong in the same category of honest measurement. Total paid spend divided by total new subscribers, with no attribution applied, is a number nobody can dispute, and tracked weekly it catches problems a modelled dashboard will smooth over.

Two to four tests a year is a realistic cadence for a brand spending at a serious level. More than that and you spend the year with channels switched off; fewer and the result is stale before you act on it.

Size the test before you run it. A holdout needs enough baseline volume in the control regions to detect a difference, and a channel contributing a small share of total installs will need a longer window or a larger geography split to show up at all.

What should your tracking setup actually look like?

The working setup has four layers, and the order matters because each one depends on the one before it. First, first-party event tracking and a subscription platform that owns trial, conversion and renewal data. Second, SKAN and AdAttributionKit implemented properly, with conversion values mapped to early predictive events. Third, an MMP reconciling networks. Fourth, a quarterly incrementality test.

Conversion value mapping is where most implementations are quietly wrong. Mapping to revenue buckets looks sensible and returns almost nothing, because the window closes before the money arrives. Mapping to onboarding completion, paywall view and trial start returns a usable signal within the window.

Decide your attribution rules before you need them and write them down: which event counts as activation, what the window is, whether view-through counts, and which number the team reports. Changing those definitions mid-quarter produces a trend line that measures your own definition changes.

Then check the arithmetic against the store. Store installs and store revenue are the outer bound, and if your dashboards sum to more than the store reports, the dashboards are wrong.

Run that reconciliation monthly rather than when something looks odd. App Store Connect and Google Play Console give you units, proceeds and refunds that no attribution system can overstate, and a monthly comparison catches a broken event or a double-counted postback while the cause is still findable.

The short version

Build on what consent cannot take away. Your own trial starts, conversions, renewals and revenue are complete, immediate and not subject to any opt-in, and they are the only numbers in this system that are fully reliable.

Treat the privacy frameworks as campaign allocation rather than truth. SKAN gives you a 6-bit conversion value from 0 to 63, released only when a campaign clears Apple’s crowd anonymity threshold, so map it to early predictive events and expect low-volume campaigns to report least. AdAttributionKit raises that ceiling and adds re-engagement and web-to-app measurement, and running both is the correct position while Apple keeps SKAN alive.

Add an MMP when the second paid channel goes live, because that is the point where the platform dashboards start double-counting. Then prove the whole thing with a holdout two to four times a year.

ATT consent somewhere between 38% and 50%, according to the Adjust and AppsFlyer panels, means half to nearly two thirds of your iOS users are invisible at the device level, and an incrementality test is the only measurement that does not care.