App Tracking Transparency: What ATT Permits, Requires, and Changes
App Tracking Transparency is Apple's permission framework for cross-company tracking. This guide separates ATT from ordinary app analytics, explains the current privacy stack, and shows how developers and marketers can measure campaigns without bypassing user choice.
What is App Tracking Transparency?
App Tracking Transparency, or ATT, is Apple's framework for requesting permission before an app tracks a user or device across apps, websites, or offline properties owned by other companies, or shares user or device data with a data broker. On iOS, iPadOS, and tvOS 14.5 or later, permission is also required before an app can access the device's advertising identifier, the IDFA.
ATT does not mean that every app event is tracking. An app can still measure its own onboarding, feature use, purchases, or retention when that data is not joined with another company's data for advertising or advertising measurement and is handled under the relevant disclosures, policies, and laws. The ownership and use of the data, not the event name alone, determine whether ATT applies.
Boundary
Across companies
ATT covers links between data from your app and data from properties owned by other companies for advertising or ad measurement.
Permission
A system-level choice
The app supplies a purpose string, but iOS presents and records the authorization decision through the ATT framework.
Responsibility
Your SDKs count too
The app developer is responsible for tracking performed by advertising, analytics, attribution, SSO, and other embedded code.
Primary reference: Apple's User Privacy and Data Use guidance.
What counts as tracking under ATT?
The fastest way to evaluate a data flow is to ask three questions: where the data came from, who owns the other data it is joined with, and whether the purpose is targeted advertising, advertising measurement, or data-broker sharing.
| Data use | ATT treatment | Why |
|---|---|---|
| Join app events with another company's app or website data for ad targeting | Permission required | This is cross-company tracking for targeted advertising. |
| Send emails, advertising IDs, or another identifier to an ad network for retargeting or lookalike audiences | Permission required | Apple treats the identity link and advertising use as tracking. |
| Use an SDK that repurposes your app data to measure ads across other developers' apps | Permission required | The embedded SDK's behavior is part of your app's responsibility. |
| Measure first-party product events without a cross-company advertising link | Not ATT tracking by itself | Collection and disclosure rules still apply, but the cross-company tracking condition is absent. |
| Link data only on device without sending identifying data off device | Apple lists an exception | The linkage stays on the device and cannot identify the user or device off device. |
| Use device signals to create a substitute identifier | Prohibited | Fingerprinting is not allowed, even when ATT permission is granted. |
How the ATT permission flow works
The ATT API exposes four states: notDetermined, restricted, denied, and authorized. The implementation should branch on the state before initializing any tracking-dependent data flow.
Map
Inventory your own code, SDKs, identifiers, destinations, and purposes before deciding whether a prompt is needed.
Explain
Provide a precise NSUserTrackingUsageDescription and, when useful, a truthful pre-permission explanation.
Request
Call requestTrackingAuthorization only while the app is active and no other permission request is awaiting a response.
Respect
Enable tracking only for authorized users. Keep a functional, privacy-safe path for every other state.
Apple documents the request as a one-time prompt whose choice is remembered unless the app is uninstalled and reinstalled. The call only presents UI while the application is active. If another permission request is already pending, concurrent requests are not preserved. Check for notDetermined before requesting.
Do not make access to app functionality conditional on authorization and do not reward or pressure users for choosing Allow. A pre-prompt can explain the purpose, but it must be accurate and must not imitate the system alert or manipulate the decision.
Implementation references: AppTrackingTransparency framework overview and requestTrackingAuthorization behavior.
ATT, privacy labels, and privacy manifests solve different problems
ATT is one layer in Apple's privacy requirements. A passing implementation must align runtime behavior, App Store disclosures, and the declarations shipped inside the app and its SDKs.
ATT authorization
A runtime, per-app choice governing cross-company tracking and access to the IDFA on supported systems.
App Privacy details
App Store Connect disclosures that tell people what data the app and its third-party partners collect and how it is used.
Privacy manifests
Bundle declarations for collected data, tracking use, tracking domains, and required-reason API categories in the app or an SDK.
Required-reason APIs
APIs that could be misused for fingerprinting must have approved, accurate reasons. Their data cannot be repurposed for tracking.
If a privacy manifest declares tracking, it must list the domains used for tracking. Apple documents that requests to those domains fail when the user has not granted ATT permission. Separately, required-reason API declarations do not create permission to fingerprint. Apple has rejected submissions that omit required API reasons since May 1, 2024, and since February 12, 2025 it has also required valid privacy manifests for a specified set of commonly used third-party SDKs.
Official references: Apple privacy manifest files, required-reason API guidance, and current third-party SDK manifest requirements.
Measurement without user-level tracking
ATT does not remove campaign measurement. It changes which data can be joined at the user level and increases the importance of privacy-preserving and first-party methods. Apple's AdAttributionKit can measure installs and re-engagement through signed postbacks without requiring ATT authorization.
| Signal | What it can answer | Important limit |
|---|---|---|
| Consented user-level data | Eligible cross-company paths and audience workflows for users who authorized tracking | Permission does not waive disclosure rules or permit fingerprinting |
| AdAttributionKit postbacks | Privacy-preserving install and re-engagement outcomes for signed ads | Detail can vary by postback data tier and does not expose a complete person-level path |
| First-party product events | Activation, retention, purchases, subscription state, and feature use | They do not identify which unobserved ad exposure caused an outcome |
| Incrementality tests | The change in outcomes caused by a campaign, audience, or market treatment | They need a credible control and enough scale for the expected effect |
| Aggregated trend analysis | Cohort, market, creative, spend, and revenue movement over time | Correlation alone cannot assign causal credit |
Apple's current AdAttributionKit includes multiple conversion windows, re-engagement measurement, and postback data tiers. Some properties may be withheld to preserve crowd anonymity. Marketers should therefore design conversion values around decisions that can tolerate aggregate, delayed, or less detailed data.
This distinction matters when choosing an attribution model. A model can distribute credit only across signals it receives. It cannot reconstruct unobserved identities or turn an aggregate postback into proof of individual behavior.
Primary reference: Apple AdAttributionKit documentation.
A practical ATT implementation workflow
Treat ATT as a data-system design task, not a copy change at the end of a release. The audit must include every SDK and server destination that receives data from the app.
- 01
Inventory data flows
List every event, identifier, SDK, endpoint, data recipient, retention period, and purpose. Include SSO, deep linking, fraud, analytics, ads, and attribution code.
- 02
Classify ownership and purpose
Mark whether each destination is your company, another company, or a data broker, and whether data is used for targeting, ad measurement, security, or product operation.
- 03
Remove flows that are not necessary
Disable automatic SDK collection until the correct state is known. Remove obsolete SDKs and undocumented endpoints instead of relying on prompt copy to justify them.
- 04
Align declarations
Update App Privacy answers, privacy policy, privacy manifest files, tracking domains, and required-reason API entries so they match the shipped binary.
- 05
Design both runtime paths
Specify authorized and non-authorized initialization paths. Confirm that core features remain usable and no tracking-domain request or substitute identifier leaks into the denied path.
- 06
Request in context
Explain the concrete use when the benefit is understandable, then present the system prompt while the app is active. Do not stack it with another permission dialog.
- 07
Test and monitor
Verify all four authorization states on clean installs, inspect network traffic, validate SDK configuration, and repeat the audit whenever a vendor or data use changes.
How marketers should interpret performance after ATT
ATT changes observability. A lower attributed conversion count can reflect fewer joinable identities, a different postback detail tier, reporting delay, or actual campaign deterioration. Diagnose the measurement system before treating every reporting movement as a market movement.
Business outcomes
Revenue, activated users, retention, subscription renewal, and payback reveal whether acquired demand creates value.
Measurement health
ATT status mix, postback coverage, conversion-value completion, event delays, and SDK changes reveal whether reporting conditions shifted.
Market evidence
Creative patterns, competitor activity, category movement, and store conversion provide context without requiring a user-level identity graph.
For campaign planning, connect this measurement plan to the broader app promotion framework and your App Store Optimization work. Competitive creative research in SocialPeta Ad Intelligence can help generate testable concepts without claiming access to private user-level tracking data.
Common ATT mistakes and policy risks
Treating ATT as an IDFA-only rule
The policy covers other user or device identifiers when they join data across companies for advertising or measurement.
Starting an SDK before the state is known
Automatic collection can create a prohibited data flow before the user has made a choice.
Replacing IDFA with fingerprinting
Apple prohibits deriving a unique identity from device signals regardless of whether ATT is authorized.
Requesting permission at first launch without context
The system prompt should appear when the purpose is understandable and while the app is active, not simply at the earliest technical opportunity.
Gating features or rewarding consent
Apple says apps may not make functionality conditional on tracking permission or incentivize agreement.
Ignoring third-party code
Developers remain responsible for the collection and tracking practices of every SDK included in the app.
Assuming a privacy manifest replaces ATT
A declaration records practices. It does not authorize runtime tracking or override a denied state.
Comparing attributed totals as if coverage were constant
Changes in consent, postback detail, windows, SDKs, and reporting delays can move the reported number without an equal change in business impact.
App Tracking Transparency FAQ
What is App Tracking Transparency?
App Tracking Transparency is Apple's permission framework for tracking a user or device across apps, websites, or offline properties owned by other companies, or for sharing user or device data with a data broker. On supported Apple platforms, an app must receive permission before performing that tracking or accessing the device advertising identifier.
Does ATT stop all app analytics?
No. ATT addresses tracking across companies and data-broker sharing, not every form of analytics. First-party product analytics can continue when the data is not joined with third-party data for advertising or ad measurement and is handled consistently with Apple's disclosures, policies, and applicable law.
Can an app track with a hashed email after a user denies ATT?
No. Apple says an app may not substitute another identifier, including a hashed email or phone number, to track a user who has not granted ATT permission. Fingerprinting is also prohibited regardless of the user's authorization choice.
Does AdAttributionKit require ATT permission?
No. Apple states that apps can call AdAttributionKit attribution APIs regardless of tracking authorization status. The framework provides signed, privacy-preserving campaign postbacks instead of a complete user-level journey.
Is ATT the same as Apple's App Privacy label or privacy manifest?
No. ATT is a runtime permission for tracking. App Privacy details disclose data practices on the App Store product page. Privacy manifests describe collected data, tracking domains, and required-reason API use in an app or SDK. The requirements complement one another but are not interchangeable.