Quick definition
App Tracking Transparency, or ATT, is Apple's framework for requesting permission for tracking covered by its platform policy. The relevant concept includes linking app-collected user or device data with data from other companies for targeted advertising or advertising measurement, and certain sharing with data brokers. It is not a general synonym for every analytics event.
ATT gives users a system-level choice about the covered activity. An app's marketing, analytics, and third-party integrations need to respect the resulting permission state. Changing the identifier used does not automatically change whether the underlying activity is tracking.
For marketers, the practical issue is how data practices, campaign measurement, and the user experience work together. ATT is one platform requirement within a wider privacy and product process. It does not replace all applicable legal obligations or establish that every other data practice is automatically acceptable.
Map data uses before deciding what to request
Create an inventory of data collected by the app and included services. Record the recipient, purpose, identifiers involved, and whether information is combined with other companies' data. An SDK described as analytics may have additional uses that need examination.
Separate the business objective from the data mechanism. Measuring product task completion within the app is not automatically the same as connecting activity across companies for advertising. Conversely, calling a process “measurement” does not exempt it from the relevant tracking definition.
Have technical and privacy owners review the actual implementation against current requirements. Marketing should provide the intended campaign uses and vendor relationships, while engineering confirms what the code sends. A permission decision based only on a vendor category or a sales description can miss material behavior in the integration.
Respect the permission state in the implementation
The application needs to respond correctly to the authorization state, including cases where permission has not been determined or cannot be requested. Tracking-dependent services should not proceed merely because the prompt is planned for later.
A user's refusal is not permission to substitute another identifier, such as an email-derived identifier, for the same covered tracking purpose. Apple also prohibits fingerprinting intended to identify a user or device. Review vendor behavior rather than assuming that disabling one advertising identifier disables every relevant data flow.
Test both acceptance and refusal paths, as well as changes in settings and supported device conditions. The product should remain usable without coercing agreement. Keep implementation decisions documented so future SDK or campaign changes do not reintroduce behavior that the original permission design was intended to control.
Explain the request without pressuring the user
The explanation should accurately describe the intended data use in language a user can understand. Do not frame an optional tracking choice as a requirement for unrelated core functionality or promise benefits the application cannot substantiate.
Choose a context that allows the user to understand the request, while following the platform's current prompt rules. Permission interfaces and available behavior can vary by operating-system version and region, so avoid hard-coding an outdated assumption about every user's experience.
Review the complete flow, including any explanatory screen, system prompt, and subsequent app behavior. A clear sentence cannot compensate for a misleading surrounding design. Measure whether users understand the choice, not only whether they agree. An increased acceptance rate obtained through confusion is not a sound product or marketing improvement.
Worked example: reviewing an attribution integration
Imagine a fictional shopping app adding a marketing measurement SDK. The commercial team wants to connect advertising interactions with purchases, while the product team also records checkout completion for internal analysis. The team first separates these purposes rather than treating all measurement as one permission category.
Engineering reviews the SDK configuration and data recipients, then works with the relevant owners to determine which behavior depends on ATT authorization. The app is tested with permission granted and denied, and the team verifies that disallowed tracking does not continue through an alternative identifier.
Campaign reports are then documented with their actual scope and limitations. The team does not infer that a user who declined tracking never purchased. The example illustrates a review workflow, not a universal classification of every SDK. The actual data use and current platform rules determine the required treatment.
Adapt measurement without inventing missing identities
ATT can affect the availability of certain advertising identifiers and user-level matching. Teams should understand which reports contain directly observed, aggregated, delayed, or modeled information. Different measurement systems may answer different questions and should not be forced into a single supposedly exact user journey.
Use supported privacy-preserving measurement approaches where appropriate and evaluate campaign outcomes with suitable aggregate analysis or experiments. These methods have their own definitions and limitations; they are not a license to reconstruct identities that users declined to share for tracking.
Keep product analytics and advertising attribution conceptually distinct while checking both actual data practices. Report uncertainty explicitly and avoid interpreting reduced matching as proof that all marketing performance declined. The business still needs to evaluate customer value, but the measurement plan must work within the choices and constraints that apply.
Maintain a cross-team review process
Assign owners for the data inventory, SDK review, permission implementation, campaign configuration, and reporting definitions. Review material changes before release rather than assuming an earlier assessment covers every new integration or purpose.
Test actual network behavior and application states with appropriate technical tools. Check that documentation and public privacy information reflect the implementation. Vendor updates can change behavior, so maintain a process for assessing dependencies instead of treating the initial setup as permanent.
Use current Apple guidance for version- and region-specific requirements and obtain suitable legal advice for legal questions. A glossary explanation cannot determine every app's obligations. The durable operational principle is to know what data is used, for what purpose, under which permission state, and how that affects the claims made about campaign performance.
Frequently asked questions
Does ATT apply to every analytics event?
No. The relevant question is whether the actual data use meets Apple's tracking definition, not whether a feature is labeled analytics. Internal product measurement and cross-company advertising tracking can involve different practices. Review recipients, identifiers, combinations, and purposes with technical owners. Do not assume that a vendor's category alone establishes whether authorization is needed for the integration.
Can another identifier replace the advertising identifier after refusal?
Not as a way to continue covered tracking without the required permission. The policy concerns the activity, not only one identifier. Substituting a hashed email or another identifier does not automatically make the same cross-company tracking acceptable. Review the complete data flow and vendor behavior, and design measurement that respects the user's choice rather than attempting to recreate the denied capability.
Does ATT replace a privacy policy or other consent requirements?
No. ATT is a platform framework with a particular scope. An app may have additional disclosure, consent, or other obligations depending on its practices and applicable requirements. Keep the different controls understandable and ensure they do not contradict the ATT choice. Obtain appropriate review for the actual situation rather than treating one accepted prompt as universal authorization for all data use.
Should acceptance rate be the main success metric?
It can describe a defined permission outcome, but should not become an incentive to confuse or pressure users. Evaluate whether the explanation is accurate and the implementation respects every state. Also review the app experience and measurement quality. A higher acceptance rate does not establish better privacy practice, and a refusal should not be interpreted as a failure of the user journey.
Can campaign performance still be evaluated with limited tracking?
Yes, but the methods and certainty may differ. Supported aggregated or privacy-preserving reporting, product outcomes, and appropriate experiments can provide useful evidence. Understand each system's scope, delays, and modeling rather than presenting it as a complete observed user journey. Reduced matching is a measurement limitation to explain, not a reason to fabricate missing attribution or bypass a user's choice.
Related terms
- Mobile attribution: assigning mobile outcomes to marketing interactions. ATT can affect the data available for certain matching approaches.
- Data privacy: the responsible treatment of personal information. ATT addresses one platform-specific part of that broader subject.
- Consent management: coordinating choices and their effect on data use. Different controls need clear scope and consistent implementation.
- Privacy-preserving measurement: approaches designed to assess outcomes while limiting exposure of individual information. Their limitations still need explanation.
- First-party data: information collected through an organization's direct relationships. The label alone does not determine whether a later use falls within tracking rules.
- App onboarding: the first-use experience. Permission explanations should support understanding without coercing unrelated access.