AdAttributionKit vs SKAdNetwork: iOS Attribution After ATT

Apple’s App Tracking Transparency (ATT) framework replaced device-level identifier tracking with a permission prompt — and because a large share of users decline it, the deterministic IDFA-based attribution the iOS ad ecosystem ran on stopped working at scale. Everything else in this guide follows from that one change.

Before ATT, attribution on iOS was simple and exact. An advertiser matched an install back to the ad click that produced it using the IDFA, a stable per-device advertising identifier read freely by SDKs. That deterministic match is what made click-through attribution, granular cohort analysis and tight cost-per-action optimisation possible. ATT closed that door: an app must now show a system prompt and receive explicit consent before it can access the IDFA for cross-app tracking, and most users say no.

Apple’s answer was not to leave advertisers blind but to move measurement into privacy-preserving, on-device APIs that report aggregated, anonymised conversions rather than user-level events. The first of these was SKAdNetwork; the newest is AdAttributionKit. Both deliberately trade granularity for privacy — you learn that a campaign drove installs and roughly what those users did, but not which user did what.

That trade-off reshaped the whole iOS funnel. Cohort analysis became fuzzier, lookalike and retargeting audiences shrank, and the early-ROAS decisions that used to rest on clean user-level data now had to draw on aggregated postbacks and statistical modelling. The networks adapted too: every major ad platform now reports iOS performance through Apple’s aggregated APIs, so understanding those APIs is no longer a measurement-team concern — it is the foundation of how you plan, bid and judge iOS spend.

Across our 300+ apps managed since 2013, the teams that adapted fastest were the ones that stopped fighting this and rebuilt their user acquisition measurement around aggregated signal. The question for 2026 is no longer "how do I get the IDFA back" — it is "which of Apple’s two attribution APIs do I run, and how do I read them correctly".

SKAdNetwork (SKAN) is Apple’s original privacy-preserving install-attribution API, and AdAttributionKit (AAK) is its 2024 successor — both report aggregated, anonymised conversions instead of user-level data, but AAK measures things SKAN never could. They are best understood as two generations of the same idea, not as rivals.

SKAdNetwork came first and handles App Store install attribution only. An ad network registers with Apple, the framework records that an ad led to an install, and Apple sends the network a signed postback after the fact. It is deliberately minimal: no user identifiers, no real-time event stream, just aggregated outcomes released on a delay.

AdAttributionKit was introduced at WWDC 2024 and is available on iOS 17.4+, with re-engagement features arriving in iOS 18. Per Singular’s breakdown of AdAttributionKit, it reuses SKAN 4’s three-postback model, coarse and fine conversion values and crowd-anonymity tiers — so it is interoperable with SKAN rather than a clean break — while adding re-engagement attribution, support for alternative app marketplaces, view-through attribution and deep linking. Apple’s own AdAttributionKit documentation frames it as the forward-looking framework, and Apple has signalled that future attribution updates land here, not in SKAN.

The practical read: SKAN is the proven, widely-adopted baseline, and AAK is the strategic direction that extends measurement into re-engagement and the post-DMA marketplace world.

SKAN 4 works by sending an ad network up to three aggregated postbacks — covering the 0–2, 3–7 and 8–35 day windows after install — each carrying a conversion value only when enough installs share it to preserve user anonymity. The three-window design is the core upgrade SKAN 4 brought over earlier versions.

Each postback window reports activity captured in that period, so you get an early read at 0–2 days and progressively later reads at 3–7 and 8–35 days. The conversion value comes in two forms. The fine-grained value is 6-bit — 64 possible values from 0 to 63 — and it is available only in the first postback, and only at the highest crowd-anonymity tier. The coarse-grained value is none, low, medium or high, and it is what you receive in the second and third postbacks. Importantly, SKAN 4 lets a conversion value increase or decrease over the measurement window, which earlier versions did not.

The privacy machinery sits underneath all of this. Crowd anonymity has four tiers (0–3): the more your campaign clears Apple’s anonymity thresholds, the more detail Apple is willing to return. Targeting is carried by a hierarchical source identifier of up to four digits — 10,000 possible values, 0 to 9,999 — which replaced the older, narrower campaign ID. Postbacks also arrive on randomised delays, as Adjust documents in its SKAN 4 guide: the first postback is delayed 24–48 hours, and the second and third are delayed 24–144 hours.

It helps to picture the crowd-anonymity tiers as a dimmer rather than a switch. At the lowest tier Apple may send a postback with no conversion value at all; as a campaign accumulates enough installs to clear the higher thresholds, Apple releases the coarse value, and at the top tier in the first window it releases the full 6-bit fine value. Because the gate is cohort size, the same creative can return rich data inside a large campaign and almost nothing inside a small one — which is why consolidating spend into fewer, larger campaign structures is a measurement decision as much as a budgeting one. Apple deliberately does not publish the exact install count each tier requires, so you tune toward it empirically rather than to a documented floor.

It is worth being honest about what this costs you analytically. You cannot tie a specific high-value user back to a specific creative, you cannot build a real-time funnel, and you cannot optimise inside the day the way pre-ATT iOS allowed. What you can do is read campaign-level lift across three coarse time horizons and design your conversion-value mapping so the early window captures the events that actually predict value. The takeaway is that SKAN gives you a defensible aggregate picture but a deliberately blurred and delayed one — you design around the windows, you do not get around them.

AdAttributionKit keeps SKAN 4’s aggregated postback model but adds four things SKAN cannot do: re-engagement attribution, view-through attribution, support for alternative app marketplaces, and deep linking through universal links. Each one closes a real gap in what iOS advertisers can measure.

• Re-engagement attribution: AAK can attribute downloads, redownloads and re-engagements, with the first conversion-value update for a re-engagement arriving within 48 hours. SKAN simply cannot measure re-engagement — it only ever understood the install. This is the largest functional difference between the two.
• Alternative marketplaces: AAK introduces a marketplace identifier so installs from alternative app marketplaces — the distribution channel opened by the EU’s Digital Markets Act — can be attributed, not just App Store installs.
• View-through attribution: AAK can credit impressions that led to a conversion without a click, which matters for the brand and video formats SKAN’s click-centric model under-counts.
• Deep linking: AAK supports universal links and deep linking for re-engagement, so a tapped ad can route a returning user to the right in-app destination and still be measured.

Crucially, none of this means AAK has thrown SKAN away. As AppsFlyer’s WWDC 2024 write-up stresses, AAK reuses SKAN 4’s three-postback structure, its coarse and fine conversion values and its crowd-anonymity model, which is exactly what makes the two interoperable. In our portfolio, the apps that benefit most from AAK today are the ones running re-engagement and retargeting on iOS — measurement they previously had to infer rather than attribute.

The re-engagement gap deserves a closer look because it is so often underestimated. A subscription app, a marketplace or a game spends heavily to win a user back after they lapse, yet under SKAN that entire spend was effectively unmeasurable on iOS — you could see the win-back happen in your own data but you could not attribute it to the campaign that caused it. AAK changes that, and it does so without re-identifying the user, which is why it is the piece of the puzzle that most directly expands what iOS performance marketers can actually optimise.

The alternative-marketplace dimension deserves its own note for anyone running EU traffic. The Digital Markets Act forced Apple to allow app distribution outside the App Store in the EU, and SKAN had no concept of an install that did not originate from the App Store. AAK’s marketplace identifier closes that gap, so a campaign that drives an install through an alternative marketplace can be attributed instead of disappearing from your reporting. If you do not touch EU alternative-marketplace traffic, this changes little for you today. If you do, AdAttributionKit is currently the only privacy-preserving way to measure those installs — which makes adopting it less optional than it first appears.

A conversion-value schema is the lookup table that maps your in-app events to the limited values SKAdNetwork can return — the 6-bit fine value (0–63) in the first postback and the coarse none/low/medium/high value afterwards — so the real craft is deciding which 64 outcomes deserve a slot and front-loading them into the early window. Get this right and the aggregated signal predicts value; get it wrong and you are optimising on noise.

There are three common philosophies, and the right one depends on your model. A revenue schema buckets in-app revenue into ranges and encodes the band a user lands in — natural for games and apps with early purchases. A funnel schema encodes the furthest onboarding or activation step reached — useful when first-session revenue is rare but engagement predicts retention. A conversion-event schema simply flags whether specific high-intent events fired — useful for lead generation and subscription trials. Most mature teams we work with run a hybrid: a couple of bits for funnel stage and the rest for a revenue tier.

A worked example makes the constraint concrete. Say you sell a subscription. With 64 values you might reserve 0 for "no monetisable action", 1–7 for onboarding milestones (registration, tutorial complete, first key action), 8–15 for trial-start tiers, and 16–63 for revenue bands that widen as the amount grows (₹ or $ depending on market). The arithmetic is unforgiving — 64 slots is all you get, so a band that is too granular at the low end starves the high-value tiers that actually move bidding. Decide deliberately where precision earns its keep.

The edge cases are where teams get caught. If a campaign does not clear Apple’s crowd-anonymity threshold, the fine value is suppressed and you receive only a coarse value — or a postback with no conversion value at all. A null or "none" coarse value is not a bug; it is a privacy signal telling you the install cohort was too small for Apple to return detail without risking re-identification. The practical fix is structural, not a schema tweak: consolidate thinly-segmented campaigns so more cohorts clear the threshold, because heavily-sliced campaigns are exactly the ones that come back coarse or blank.

One more discipline. Because SKAN 4 lets a conversion value move up or down across the measurement window, design the encoding so a later, higher-value event can legitimately overwrite an earlier one — and make sure your schema definition and your measurement partner’s stored mapping agree on how the value is read, or you will decode the same postback two different ways.

Server-side postback handling is the plumbing that catches Apple’s signed conversion postbacks: Apple posts an aggregated, cryptographically signed payload to the ad network’s registered endpoint, the network verifies Apple’s signature, decodes the source identifier and conversion value, and forwards a copy to the advertiser or its measurement partner. Nothing in this chain touches a user identifier — it is all aggregate by the time it leaves the device.

The flow runs in a fixed order. The device records the ad interaction and the install, waits out the measurement and randomised-delay windows, then sends the postback to the URL Apple derives from the ad network’s registration. The payload carries the fields you optimise on — the ad-network identifier, the hierarchical source identifier of up to four digits, the fine or coarse conversion value, the postback sequence index that tells you which of the three windows it represents, and a flag for whether this was the winning postback. Apple signs the payload so the recipient can prove it genuinely came from Apple and was not forged or replayed.

Verifying that signature is step one and it is not optional. A handler that accepts unsigned or unverified postbacks is trivially spoofable, and click-flooding fraud specifically targets attribution endpoints. The correct pattern is to validate Apple’s signature against the published public key before a postback is allowed to influence reporting or spend, then deduplicate on the transaction identifier so a replayed payload cannot inflate counts.

Two mechanics trip teams up. First, the winning-versus-losing distinction: when several networks could claim an install, only one receives the winning postback with full detail, while the others may receive a postback indicating they lost — information you still want to capture. Second, the advertiser copy: by default the postback goes to the ad network, so to see your own data you either register a developer endpoint to receive a copy or let your measurement partner collect and normalise postbacks across every network for you. Almost everyone chooses the partner route, because hand-rolling a verified, deduplicated, multi-network postback receiver is a genuine engineering project rather than a weekend task.

ATT opt-in in 2025 sat somewhere between 35% and 50% depending on whose methodology you trust — AppsFlyer reported roughly 50% global consent, while Adjust put the industry average at 35%. Both numbers are defensible; they measure different things, so treat the range, not a single figure, as the truth.

The gap comes down to how each company counts. AppsFlyer’s April 2025 data puts global consent at around 50%, weighting by user volume — so high-traffic apps with strong prompts pull the average up. Adjust’s Q2 2025 figures report an industry average of 35% using a per-app panel, where every app counts equally regardless of size. Neither is wrong; they answer slightly different questions.

Vertical matters as much as methodology. In Adjust’s panel, sports apps reached 50%, hyper-casual games 43%, action games 40% and board games 30%. The spread tells you that consent is a function of how well an app explains the value exchange and how engaged its audience already is, not a fixed platform constant.

There is a practical lever here that teams underuse. Because consent tracks how well an app explains the value exchange, a well-timed pre-prompt — a context screen shown before Apple’s system dialog that frames why allowing tracking improves the experience — tends to lift opt-in in our experience, though Apple’s rules forbid incentivising or pressuring the choice. The aim is not to chase a benchmark but to recover whatever deterministic signal your category realistically allows, then build the rest of your measurement on the assumption that the opted-out cohort is the majority.

Why does this matter for attribution? The opt-in rate sets the ceiling on deterministic, IDFA-based measurement; everything below that line has to be measured through SKAN, AAK and modelling. Even at the optimistic 50%, half of your iOS users are measured only through aggregated postbacks — which is precisely why getting your analytics and conversion-value design right is not optional. The lower the opt-in for your category, the more your reporting leans on Apple’s privacy-preserving APIs.

You should run both concurrently — SKAN 4 and AdAttributionKit are interoperable, and Apple picks the winning postback based on the most recent engagement, so running only one leaves attribution on the table. This is the single most important operational decision in the whole comparison, and the answer is genuinely "both", not "pick one".

The reasoning is straightforward. SKAN 4 has broad ad-network adoption and is the system most of your existing campaigns already report through, so it remains the reliable baseline for App Store install measurement. AdAttributionKit is where Apple is investing, and it is the only way to measure re-engagement, view-through and alternative-marketplace installs. Because AAK reuses SKAN’s postback machinery, you are not maintaining two unrelated stacks — you are running the proven baseline alongside the framework that extends it.

Be precise about the relationship, because it is easy to overstate. AAK does not replace SKAN today. SKAN is in what is effectively maintenance mode — it still works and is still widely used — while AAK is the forward path that will receive future updates. The two coexist, and when both could attribute the same outcome, Apple awards the winning postback to the most recent engagement, which is what makes re-engagement measurable without double-counting the original install.

There is a sequencing point worth making, too. You do not have to migrate everything to AAK at once. The pragmatic order we use is to keep SKAN 4 running exactly as it is for install attribution, add AdAttributionKit alongside it to capture re-engagement and any alternative-marketplace traffic, and then let the two report side by side while your team gets comfortable reading both. Because the conversion-value model is shared, the schema you have already built for SKAN does most of the work for AAK — the incremental effort is small relative to the measurement you unlock.

If you are also weighing which measurement partner to standardise on while you do this, our breakdown of AppsFlyer vs Adjust vs Singular covers how the major MMPs handle SKAN and AAK ingestion in practice. We have seen the "run both" posture consistently outperform an either/or stance, simply because each API covers a blind spot the other leaves open.

A mobile measurement partner sits between Apple’s raw postbacks and your dashboard: it registers for and receives SKAN and AdAttributionKit postbacks, decodes the conversion value against your schema, deduplicates winning postbacks across networks, and blends that aggregated truth with predictive and incrementality modelling to estimate what the opted-out majority did. In effect the partner turns three delayed, coarse postbacks into something you can plan spend against.

The decoding step is the one most people forget exists. A postback arrives carrying a number between 0 and 63, and that number means nothing until it is read against the schema you defined — so the partner holds your mapping and translates the slot back into "reached trial" or "$5–$10 revenue band". If your schema and the partner’s stored mapping drift apart, every downstream report is quietly wrong, which is why schema changes have to be coordinated rather than shipped unilaterally.

Modelling is where partners genuinely differ. Because only the opted-in minority can be measured deterministically, and only the highest-anonymity cohorts return a fine value, partners layer on predictive modelling — using the early conversion value to forecast longer-term ROAS — and incrementality testing to separate ads that caused installs from installs that would have happened anyway. These are estimates, and two partners can return different numbers from the same campaign, which is normal rather than a defect. Our comparison of AppsFlyer vs Adjust vs Singular walks through how each one handles SKAN and AAK ingestion, conversion-value decoding and reconciliation in practice.

Reconciliation is the last piece. Your ad network reports one install count, SKAN reports another, and your partner reports a third, because each counts on a different clock and through a different privacy filter. Across our portfolio the teams that stay sane treat the partner’s blended view as the planning number, the network’s figure as a directional check, and SKAN’s raw postbacks as the privacy-safe ground truth — and they never expect the three to reconcile to the decimal.

The migration is not a rip-and-replace; it is a phased rollout that keeps SKAdNetwork 4 running as your install baseline while you add AdAttributionKit alongside it for re-engagement, view-through and alternative-marketplace measurement. Here is the order we use so nothing goes dark mid-transition.

1. Audit what you have. Document your current SKAN 4 conversion-value schema, which networks you run, and how postbacks reach you today. You cannot migrate cleanly until you know exactly what the baseline measures.
2. Confirm AAK support across the stack. Check that your measurement partner, your ad networks and your minimum supported iOS version (AdAttributionKit needs iOS 17.4+, with re-engagement on iOS 18) can all carry AAK before you build against a capability part of your audience cannot receive.
3. Extend, do not rebuild, the schema. Because AAK reuses SKAN’s conversion-value model, your existing schema carries straight over — add the re-engagement and marketplace cases rather than starting from scratch.
4. Wire re-engagement deep links. To attribute win-backs, implement universal links and deep linking so a tapped ad routes a returning user to the right in-app destination and AAK can credit the re-engagement.
5. Run both APIs in parallel. Keep SKAN 4 untouched for install attribution and let AAK report alongside it. Apple awards the winning postback to the most recent engagement, so the two will not double-count the original install.
6. Recalibrate reporting to the windows. Hold judgement until the 0–2, 3–7 and 8–35 day postbacks land, and reset finance and founder expectations to a rolling, multi-day cadence instead of a real-time dashboard.
7. Review, then decide what leans on AAK. Once both are reporting cleanly, decide which measurement — re-engagement, marketplace, view-through — you now trust to AAK, and keep SKAN as the proven install baseline while Apple’s future updates land in AdAttributionKit.

The reason to sequence it this way is risk management: at no step does a working measurement source switch off, so a misconfiguration in the new framework degrades gracefully instead of blinding your acquisition team mid-quarter.

Practical setup means leaning on your MMP to ingest both SKAN and AAK postbacks, designing a conversion-value schema that front-loads signal into the first 0–2 day window, and aligning your reporting to the three-postback timeline rather than to real-time dashboards. The mechanics matter, but the schema design is where most teams win or lose.

1. Wire up both APIs through your MMP. Configure your measurement partner to register for, receive and decode SKAN and AAK postbacks. Because AAK reuses SKAN’s postback structure, a partner that handles SKAN 4 well is already most of the way to AAK — confirm the AAK fields are mapped, not just the SKAN ones.
2. Design the conversion-value schema around the first window. The richest signal — the 6-bit fine value, 0 to 63 — only ever comes in the first postback. Map your most decision-useful early events (a key activation, a first purchase, a high-value onboarding step) into that 0–2 day window, because the later windows return only the coarse none/low/medium/high value.
3. Read against the timeline, not the clock. With randomised delays of 24–48 hours on the first postback and 24–144 hours on the later two, your "campaign performance" is always a few days behind reality. Build that lag into how you judge campaigns so you do not kill a winner before its postbacks land.
4. Pair aggregated truth with modelling. For the opted-out majority, combine SKAN and AAK postbacks with predictive and incrementality modelling to fill the gaps the aggregated data leaves — especially for early ROAS decisions made before the 8–35 day window closes.

If Apple Search Ads is part of your mix, note that it carries its own deterministic attribution alongside these privacy-preserving APIs — our Apple Search Ads strategy guide walks through how that data complements SKAN and AAK rather than duplicating it.

It means iOS user acquisition is now an aggregated, delayed and modelled discipline — and the teams that treat SKAN 4 and AdAttributionKit as a combined measurement layer, rather than chasing the lost IDFA, are the ones that scale spend confidently. The framework changes; the strategic posture does not.

The concrete implications are consistent. Plan campaigns around postback windows, not real-time numbers. Invest in a conversion-value schema as carefully as you invest in creative, because that schema is the only lens you have on the opted-out majority. Adopt AdAttributionKit now for re-engagement and marketplace measurement even while SKAN 4 remains your install baseline, because that is the direction Apple is committed to. And accept that some portion of truth will always come from modelling rather than from a deterministic match.

It also changes how you set expectations internally. Finance teams and founders used to a real-time, deterministic dashboard need to understand that iOS performance now arrives on a delay and as a probability, not a certainty. The healthiest reporting cadence we have seen judges iOS campaigns on a rolling multi-day basis tied to the postback windows, blends aggregated truth with modelled estimates for the opted-out majority, and resists the urge to react to a single day’s numbers. That discipline is what lets a team keep scaling spend without flying blind.

None of this is a reason to spend less on iOS — it is a reason to measure it more deliberately. The advertisers losing ground are the ones still trying to force a pre-ATT mental model onto a post-ATT system; the ones gaining are reading the aggregated signal for what it is and acting on it.

If you want help standing up SKAN and AAK measurement, designing a conversion-value schema that actually informs bidding, or auditing where your iOS attribution is leaking, that is exactly the kind of work our team does every day — talk to us and we will map it to your stack.