By Sharply Labs Editorial Team
The short answer
App Tracking Transparency (ATT) and AdAttributionKit (AAK) do two different jobs. ATT governs permission: Apple requires apps to request authorization through ATT when they collect data about end users and share it with other companies for tracking across apps and websites (Apple Developer: AppTrackingTransparency). AAK governs attribution: it lets ad networks measure campaign success while maintaining user privacy, and Apple states that apps don't need to use ATT before calling AdAttributionKit APIs and can call them regardless of tracking authorization status (Apple Developer: AdAttributionKit).
So "ATT vs. AdAttributionKit" is not a choice between two tools. It is a question of which team owns which decision. Privacy and legal owners decide whether the app tracks and whether a prompt is required. Engineering and measurement owners decide how privacy-preserving attribution flows into reporting. Growth owners decide how to read the resulting signals without mistaking them for user-level truth.
When those decisions get merged, teams make predictable mistakes: treating an ATT denial as "attribution is broken," treating AAK as a substitute for consent, or letting a third-party SDK quietly decide the company's tracking posture.
This article is operational guidance, not legal advice. Regional privacy laws and contractual obligations vary; confirm your obligations with qualified counsel.
Why the two get confused
Both frameworks arrived in the same post-IDFA period, both appear in the same mobile measurement conversations, and both affect what a growth team can see. That proximity makes them sound like alternatives.
They are not. ATT is a permission framework: an app presents a purpose string, requests authorization, and reads the resulting status (Apple Developer: AppTrackingTransparency). On iOS and iPadOS 14.5 and later, apps must receive permission through ATT to access the device's advertising identifier, and they must respect the user's response (Apple: User Privacy and Data Use).
AAK is a measurement framework. Apple Ads describes it as a way to measure ad performance that doesn't track users, using crowd anonymity and delayed postbacks (Apple Ads Help: AdAttributionKit). Apple's WWDC24 session explains that AAK builds on SKAdNetwork fundamentals and supports privacy-preserving postbacks, re-engagement, click and view attribution, conversion values governed by crowd anonymity, and developer-mode testing (WWDC24: Meet AdAttributionKit).
One answers "may we track this person across other companies' properties?" The other answers "which ad likely contributed to this install or re-engagement, in aggregate and with delays?" If your team cannot state that distinction in one sentence, the rest of the measurement plan will drift.
For how AAK coexists with SKAdNetwork specifically, read AdAttributionKit vs. SKAdNetwork. This article stays on the permission-versus-attribution boundary.
Comparison matrix
Dimension App Tracking Transparency AdAttributionKit --------- Decision it supports Whether the app may track the user or device across other companies' apps and websites How ad interactions are credited to installs and re-engagements without user-level tracking Permission Is the permission mechanism: purpose string, authorization request, status (Apple) Does not require ATT; APIs can be called regardless of authorization status (Apple) Identity Gates access to the advertising identifier on iOS/iPadOS 14.5+ (Apple) Does not track users; relies on crowd anonymity (Apple Ads) Attribution Not an attribution system; it only governs whether tracking-based methods may be used Privacy-preserving postbacks for eligible ad networks, including click/view and re-engagement (WWDC24) Output An authorization status the app and SDKs must respect Delayed, aggregated postbacks with conversion values limited by crowd anonymity Primary owner Privacy/legal owner with product and engineering Measurement lead with engineering and ad-network/MMP partners Typical failure mode SDKs tracking without valid authorization, or "workaround" identifiers Unconfigured postbacks, unsupported partner features, or reports read as user-level truth
The matrix is deliberately asymmetric. ATT has no attribution row because it does not attribute anything. AAK has no consent row because it does not grant permission for anything.
The three-map handoff
The practical fix is to produce three separate maps and hand them between owners in a fixed order. Each map has one owner, one question, and one artifact.
Map 1: Data-use map (owner: privacy/legal, with engineering)
Question: What user or device data does the app and every embedded SDK collect, and where does it go?
Inventory first-party code and every third-party SDK. For each, record data collected, destination company, purpose, and whether that data is combined with data from other companies' apps or websites. Apple is explicit that developers are responsible for ensuring third-party SDK code complies with their tracking choices (Apple: User Privacy and Data Use). "The SDK vendor handles it" is not an answer this map accepts.
Artifact: a table of SDKs and data flows with an explicit "tracking: yes / no / unconfirmed" column. "Unconfirmed" rows are blockers for Map 2.
Map 2: Permission and UX map (owner: product, with privacy/legal)
Question: Given Map 1, does the app need to request ATT authorization, and how does every component behave under each status?
If Map 1 shows tracking as Apple defines it, the app must request permission through ATT before that tracking occurs (Apple Developer). Map 2 documents the purpose string, when the request appears in the user journey, and, critically, what each SDK does when status is authorized, denied, restricted, or not yet determined. Apple does not allow alternative identifiers such as hashed email addresses or phone numbers to stand in for tracking when users haven't granted permission (Apple: User Privacy and Data Use).
Prompt timing and copy are product decisions within Apple's rules. This article makes no claim that showing, delaying, or skipping a prompt improves acquisition cost, return on ad spend, or conversion; no official source cited here supports such a claim.
Artifact: a status-by-component behavior table, reviewed by counsel where legal obligations apply.
Map 3: Attribution and reporting map (owner: measurement lead, with engineering and partners)
Question: How will campaign credit be measured and reported, independent of ATT status?
Because AAK APIs can be called regardless of ATT status (Apple Developer), Map 3 should not branch on the permission outcome for AAK itself. It documents which ad networks are integrated (Apple Ads notes only integrated networks are eligible to use AAK; Apple Ads Help), how conversion values are defined, where postbacks are received, how they are joined to spend at an aggregate level, and how delayed data is labeled in dashboards.
Artifact: a postback flow diagram, a conversion-value schema, and a reporting-continuity note for any change in partners or frameworks. Broader architecture — MMP, product analytics, finance ledger, experiments — belongs in your measurement system design; see attribution beyond Meta: SCAPI, MMP, and MMM.
Why the order matters
Map 1 feeds Map 2; Map 2 constrains anything tracking-based in Map 3; AAK attribution in Map 3 runs regardless. Running them in reverse — starting from "what does the growth team want to see?" — is how teams end up with SDKs collecting data nobody approved.
Decision tree
Work through these questions in order. Each "unsure" answer is a stop sign, not a guess.
Does the app (first-party code) link user or device data with data from other companies for advertising or measurement, or share it with data brokers?
Yes → ATT authorization is required before that tracking (Apple Developer). Go to step 3.
No → go to step 2.
Unsure → stop; resolve with privacy/legal.
Does any embedded SDK join user or device data across companies?
Yes → treat as tracking in your app; you are responsible for the SDK's behavior (Apple). Go to step 3.
No, confirmed in writing by the vendor and verified in testing → go to step 4.
Unsure → stop; obtain SDK documentation and configuration confirmation.
Is the tracking gated behind ATT authorization, and do all components honor every status?
Yes → go to step 4.
No → fix before release. Do not substitute hashed identifiers, fingerprinting, or other alternative identifiers.
Does AAK handle install and re-engagement attribution for the networks you buy?
Yes, integrated and configured → document in Map 3; proceed.
Partner unclear → confirm per network which AAK features it supports; do not assume parity across partners.
No → decide the attribution approach separately; it is not resolved by the ATT decision.
What requires counsel? Regional consent law, contractual data-sharing terms, children's or sensitive-category data, and any case where "tracking" status is ambiguous. ATT compliance with Apple's rules is not the same as compliance with every law that applies to you.
Implementation workflow with owners
Step Owner Action Validation ------------ 1. Inventory Mobile engineer List all SDKs, versions, and network destinations Network inspection in a test build matches the inventory 2. Classify Privacy/legal owner Mark each flow tracking / not tracking / unconfirmed No "unconfirmed" rows remain before release 3. Permission design Product marketer + product Write purpose string; place request in journey Copy reviewed; request appears only where planned 4. Status handling Mobile engineer Gate tracking components on authorization status Test each status: authorized, denied, restricted, not determined 5. AAK configuration Mobile engineer + measurement lead Integrate AAK calls and conversion-value updates; configure postback endpoints Developer-mode testing (WWDC24) shows expected postbacks 6. Partner confirmation UA lead Confirm each network's AAK integration and supported features Written confirmation on file per network 7. Reporting Measurement lead Label aggregated, delayed postback data in dashboards; annotate release dates Dashboards distinguish AAK data from tracking-based and first-party data 8. Review cadence Head of growth Re-run the three maps on every SDK addition, partner change, or major release Change log references the maps
Two validations deserve emphasis. First, test AAK behavior with ATT denied, not just authorized; Apple's statement that AAK works regardless of status should be confirmed in your build, not assumed. Second, test SDK behavior under denial at the network layer, because a vendor dashboard will not show you what an SDK sends.
Anti-pattern table
Anti-pattern Why it's wrong Correction --------- "ATT denied, so attribution is gone." AAK APIs can be called regardless of ATT status (Apple) Keep AAK attribution in Map 3 independent of the permission outcome "We use AAK, so we don't need ATT." AAK does not grant permission to track; ATT governs tracking (Apple) Decide ATT from Map 1, not from your attribution choice "Hash the email and match it instead." Apple disallows alternative identifiers as an ATT workaround (Apple) Remove the workaround; use privacy-preserving attribution "The SDK vendor is responsible." Developers are responsible for third-party SDK code (Apple) Verify SDK behavior per status in your own build "Every network supports every AAK feature." Only integrated networks are eligible; feature support varies by partner (Apple Ads) Confirm per network in writing "AAK postbacks show the user journey." AAK does not track users; data is aggregated and delayed Read postbacks as aggregate credit, never as individual paths "Our ATT setup makes us legally compliant." Apple platform rules are not a complete legal analysis Get regional review from qualified counsel
Attribution is not incrementality
Neither framework tells you whether advertising caused growth. ATT is a permission status. AAK assigns credit for installs and re-engagements according to its rules. Credit assignment is not a counterfactual: an attributed install may have happened without the ad.
If a budget decision depends on "did this channel create additional users or revenue?", that needs a designed experiment or model with a holdout, documented separately from attribution. Keep AAK reports in the "which ads got credit" column and lift studies in the "what changed because of spend" column. Mixing them is how teams defend channels that only harvest demand they would have captured anyway.
Limitations and when this framework does not fit
Platform scope. Everything here is limited to the Apple frameworks and conditions in the cited documentation. Android, web, connected TV, and alternative distribution need their own maps.
Legal scope. The three-map handoff organizes decisions; it does not answer legal questions. Consent obligations under regional law may apply regardless of ATT status.
Partner scope. AAK value depends on whether your ad networks are integrated and which features they support. A framework cannot substitute for that confirmation.
Data scope. AAK postbacks are aggregated, delayed, and limited by crowd anonymity. Teams that need user-level paths for product decisions should use first-party analytics within the permissions they actually hold, not attribution data.
When it doesn't fit. If your app runs no paid acquisition, embeds no third-party advertising or measurement SDKs, and shares no user data with other companies, most of this is unnecessary overhead; a lighter data-use review may be enough. Conversely, highly regulated apps may need a formal privacy impact process that supersedes this lightweight handoff.
Evidence limits. This article cites no opt-in benchmarks, prompt-performance data, or client outcomes. None are needed to separate the two jobs, and none should be assumed.
Natural-language questions teams ask
Can we use AdAttributionKit if users decline ATT? Apple states AAK APIs can be called regardless of tracking authorization status (Apple Developer). Confirm the behavior in your build and with each network.
Does AdAttributionKit replace the ATT prompt? No. If the app or its SDKs track as Apple defines it, ATT authorization is still required (Apple Developer).
Who should own the ATT decision? Privacy/legal, informed by an engineering-verified SDK inventory — not the growth team alone.
Who should own AAK? The measurement lead, with engineering and partner confirmation.
Do we still need a full audit? If the three maps reveal gaps across acquisition, onboarding, and reporting, a broader review helps; see how to run a mobile app marketing audit.
Next step
Start with Map 1 this week: export every SDK in your current production build, list its data destinations, and mark each row tracking / not tracking / unconfirmed. Every "unconfirmed" row is the real blocker — for the prompt decision and for trusting your attribution.
If your privacy, UA, engineering, and measurement owners are making these decisions separately and the handoffs are breaking, Sharply Labs can examine your current acquisition and measurement setup and identify the decision gaps and testable next steps. We don't promise lower CPI, higher ROAS, legal compliance, rankings, or guaranteed outcomes; we help you see what is decided, what isn't, and what to test next. Learn how we work on mobile app growth and our growth service.