3 min read
What Apple's ATT changed for MMPs, and why deep linking never needed it
Several attribution SDKs tie their deferred deep links to App Tracking Transparency even though opening the right screen after an install needs no tracking consent.
Since iOS 14.5, an app has to ask permission through App Tracking Transparency before it tracks someone or reads the advertising identifier. Apple's User Privacy and Data Use page says that without permission "the device's advertising identifier value will be all zeros", and it defines tracking like this:
Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement purposes.
Advertising measurement is what a mobile measurement platform sells, so their SDKs have every reason to care about that prompt. The odd part is how much of their deep linking ended up depending on it, given that opening the right screen after an install has nothing to do with ads.
What the attribution SDKs tie to ATT
I went through the docs as of October 2026, and this is what they say:
| Vendor | What the docs say |
|---|---|
| Adjust | "Deferred deep linking may be limited for users that opt out" of ATT (Adjust ATT guide) |
| AppsFlyer | Its legacy iOS guide says deferred deep linking through onConversionDataSuccess "may not work for iOS 14.5+, since it requires attribution data" (AppsFlyer dev docs) |
| Airbridge | The SDK collects IDFA and GAID by default (Airbridge identifiers) |
| Branch | The default protection level is "FULL", which includes advertising IDs and device IDs (consumer protection preferences) |
The AppsFlyer row matters most. In that integration the deferred link is read out of the attribution result, so with no attribution data there's no deferred link either, and on iOS 14.5 and later plenty of users decline tracking. The Adjust wording is vaguer and doesn't say how limited "limited" is. Airbridge's SDK waits on the prompt before it delivers a deferred link, which I wrote about in the ATT prompt isn't needed for deep linking, and the Airbridge comparison has the rest.
What deferred deep linking actually needs
The app only has to learn what the user tapped before they installed it. That doesn't require knowing who they are or reading anyone else's data.
On Android, the Play Store hands the app a click ID through the Install Referrer API and the app looks that click up. On iOS, the link page copies the link to the clipboard when the user taps its button, and the app reads it on first launch. iOS shows an "Allow Paste" prompt for that (the Allow Paste post goes into it), but it comes straight after the user tapped a button that copied the link, so the user has some idea why it's there. When neither works, a backup compares coarse details of the click (IP address, device, time, locale) with the same details from the app's first launch and returns a score rather than a yes or no.
None of that chain asks for consent to track. DeepLinkNow's SDKs never read the IDFA or Android's advertising ID and never show the ATT prompt. On iOS the clipboard handoff is the main path and it doesn't touch an identifier of any kind. The scored backup is short-lived and isn't tied to any identity across apps: a click can only be matched for 1 hour, and the stored record is deleted within 30 days.
Running it next to an MMP
SKAdNetwork, AdAttributionKit and the ATT prompt belong to the attribution side of an app, and if you buy installs that side will stay. The deep links don't have to live there. I'd keep the attribution SDK out of the deep link path and order the first launch so the deep link check runs before any ATT prompt. The check doesn't need the user's answer, and there is no reason to hold the screen they asked for behind a dialog about tracking.