Attribution is not dead after App Tracking Transparency. User-level attribution for opted-out iOS users is largely gone.
After a user opts out of App Tracking Transparency (ATT), five privacy-preserving methods still work:
- Apple's SKAdNetwork (SKAN) and AdAttributionKit, for aggregate install and conversion data
- Deterministic matching on consented or first-party identifiers
- Probabilistic matching, as a limited fallback
- Web-to-app flows that carry a click ID
- First-party event data you already own
Only SKAN and AdAttributionKit are aggregate by design. User-level iOS data for opted-out users is limited to flows where the user starts on your own web page, so the practical aim is decisions from aggregate signals, not a return to IDFA-level precision.
That distinction matters because most of the confusion we see is about expectations, not tooling. This post maps each method to what it gives you, what it needs and where it stops. For the wider debate, see Is Mobile Attribution Dead Under Privacy Changes?
What is privacy-preserving attribution?
Privacy-preserving attribution: measuring which marketing drove an install or event without exposing a user's identity across apps, through aggregated, delayed or consent-based signals.
Under Apple's rules, "tracking" means linking user or device data from your app with data from other companies' apps, websites or offline properties for targeted advertising or ad measurement. Without permission, the IDFA is returned as all zeros. Apple's user-privacy page also says that using a hashed email or phone number in place of the IDFA still needs ATT permission.
Here is how the methods compare for an opted-out iOS user:
| Method | Data you get | What it needs | Main limit |
|---|---|---|---|
| SKAN | Aggregate, campaign-level postbacks with a conversion value | Ad network support, postback set-up | Delayed, no user-level data, crowd anonymity thresholds |
| AdAttributionKit | Aggregate postbacks for installs and re-engagements | A recent iOS version, network support | Same aggregate model, still delayed |
| Deterministic matching | User-level match on a consented or first-party identifier | A click ID or token that survives the journey | Only where such an identifier exists |
| Probabilistic matching | An estimated match from device and network signals | No identifier | Less reliable; restricted by Apple's rules |
| Web-to-app click ID | User-level match for flows that start on your web page | Your own web page, plus a way to match the click to the app after install | Only for traffic you route through it; how the iOS match is made varies by vendor |
| First-party events | Your own sign-up and purchase data | Backend or SDK events | Says what users did, not which ad found them |
How do SKAN and AdAttributionKit work after ATT opt-out?
SKAN and AdAttributionKit are Apple's own attribution frameworks. The device, not the MMP, decides what an ad network learns.
- Ad networks register with Apple and sign ads. Apple selects a winning ad impression and later sends a signed postback with limited detail.
- Apple assigns a postback data tier, and the device uses it to cap detail so that a user stays in a crowd. This is crowd anonymity, and low-volume campaigns can get less detail.
- The app updates a conversion value as users engage. SKAN version 4 allows up to three postbacks across three conversion windows, which means your signal arrives in stages, not at once. See SKAN Attribution for the basics.
- AdAttributionKit covers install and re-engagement conversions, on the App Store and alternative marketplaces, on recent iOS versions. Apple documents interoperability with SKAdNetwork, and our comparison covers what changes: AdAttributionKit vs SKAN.
For decoding postbacks and conversion value design, read the Strategic SKAN 4.0 guide rather than repeating it here.
Field note. Across many customer conversations, most SKAN questions were not about conversion values. Many expected user-level data, deferred deep links or event attribution from SKAN, and most of the rest launched before prerequisites were complete, such as ad-network IDs in Info.plist, postback copy endpoints or the schema in Meta. The standard answer is the same each time: SKAN is aggregate and delayed, so use web-to-app where user-level iOS data matters.
What can deterministic and probabilistic matching still do?
Deterministic matching links an install to a click using an identifier that both sides can see, such as a click ID carried through web-to-app or an ad click ID. Deterministic attribution is the accurate option, but it needs the identifier to exist.
Probabilistic matching estimates a match from device and network signals when no identifier is available. Probabilistic attribution is less reliable, and Apple's rules restrict it. Asked whether you can use signals from the device to identify it, Apple's user-privacy page answers "No", adding that apps or SDKs, attribution services included, that do this may be rejected from the App Store. Read that page before you rely on any signal-based method, and ask every vendor how theirs complies.
Where does that leave a practical set-up?
- Prefer deterministic signals first: click IDs, consented identifiers and, for Apple Ads, the Apple AdServices token (Apple AdServices attribution).
- Treat probabilistic matching as a fallback, not a plan. Linkrunner is deterministic-first and uses IP address matching as a last resort.
- Expect lower confidence on any fallback match, and keep it out of decisions that need precision.
- On Android, the Google Play Install Referrer is a deterministic source, so the opt-out problem is mainly an iOS one.
How does first-party data fill the gap?
First-party data is information users give you directly, in your own app or on your own pages. Apple's policy treats data collected separately, outside the app and unrelated to it, as out of ATT scope, but tracking inside the app still needs permission, so design flows with that line in mind.
- Web-to-app with a click ID. Ad click lands on your page, the click ID is captured there, and the app is matched to it after install. How that match is made on iOS matters, so ask your vendor which signals it uses. This is the main route to user-level iOS data. See What Is Web Attribution? and the Meta Web-to-App guide.
- Consent signals. Pass the user's choice to your attribution SDK. Linkrunner documents this at Send Consent.
- Opt-in PII hashing. In the Linkrunner SDK this is off by default and enabled with
enablePIIHashing(true). Remember Apple's point above: hashing does not turn tracking into non-tracking. - Backend events. Send sign-ups and purchases from your server so revenue signals do not depend on device identifiers.
- Referral codes and QR scans. These carry context you control, because the user acts on them knowingly.
- Web attribution (Web SDK, beta). Linkrunner also attributes website visits, sign-ups and purchases, which helps when the journey starts on the web. See web attribution (beta).
What can an MMP do, and what can it not do?
A mobile measurement partner (MMP) cannot undo Apple's privacy model. It can make the allowed signals easier to use.
What an MMP can do:
- Unify SKAN, AdAttributionKit and Android attribution in one view
- Map conversion values to events and decode postbacks
- Send revenue and event signals back to ad networks through postbacks
- Manage consent flags and opt-in hashing
- Match deterministically where an identifier exists
- Flag suspicious installs after attribution
What it cannot do:
- Reveal individual opted-out iOS users
- Shorten Apple's postback delay
- Remove crowd-anonymity limits
- Make SKAN data match the old IDFA-era numbers
- Fix a SKAN set-up where the prerequisites are missing
For the SKAN side, Linkrunner offers a SKAN dashboard, privacy tiers and conversion value mapping. Integration is same day for most teams, and fully live within a week.
How should an iOS measurement set-up look now?
- Decide whether iOS ad spend justifies SKAN. An Android-heavy app may need only a lean set-up; the rule is in Android-First Apps: Do You Still Need SKAN?.
- Turn on SKAN or AdAttributionKit and confirm the prerequisites before you launch, not after.
- Write a short conversion value schema around one early, predictive event.
- Route user-level journeys through web-to-app wherever your channels allow it.
- Pass consent and keep PII hashing a deliberate choice.
- Read results as trends. Compare campaigns by aggregate direction and wait for delayed postbacks before cutting spend.
- Add incrementality tests or media mix modelling only where spend is large enough to justify them.
FAQ
In short: SKAN and AdAttributionKit, deterministic matching, web-to-app flows, and first-party events.
What is the ATT opt-in rate? It varies by app, vertical and how you ask, so there is no single figure worth quoting. Check your own prompt results in your app analytics, then plan for the opted-out share as the default case.
Is fingerprinting allowed on iOS? Apple's user-privacy page says no: you may not derive data from a device to uniquely identify it, and apps or SDKs that do so can be rejected. Ask any vendor how its fallback matching complies.
Do I still need an MMP for iOS? If you run meaningful iOS paid spend across several networks, yes, mainly to unify SKAN or AdAttributionKit with Android data, map conversion values and return signals to ad networks. A single-network, low-spend app may manage with the network's own reporting.
Does SKAN give me user-level data? No. It is aggregate, delayed and thresholded. Web-to-app flows are the practical route to user-level iOS data.
Is AdAttributionKit replacing SKAN? Apple documents the two frameworks as interoperable, and AdAttributionKit adds re-engagement support. Read the comparison for what changes in practice.
The short version
Opted-out iOS users are measured in aggregate. Deterministic signals, web-to-app click IDs and your own event data fill in around them, and probabilistic matching stays a restricted fallback. Platforms like Linkrunner, a mobile and web attribution platform, bring these signals into one place with SKAN tooling, consent support and opt-in hashing.
If you want to check how your iOS set-up reads against this list, request a demo from Linkrunner and bring your current SKAN schema.
