SKAdNetwork and AdAttributionKit: iOS Traffic Reporting in 2026

If you buy iOS traffic for app installs or run app offers, conversion reporting looks like a black box: your backend counts installs while the ad platform shows zero, numbers arrive days late in aggregated form. Two Apple frameworks are responsible: SKAdNetwork and AdAttributionKit. This guide covers how they work internally, where the data disappears, and how to read their reports without comparing them to Android directly.

Related setup guides: MMP vs affiliate tracker, cookieless attribution, event_id and deduplication.

What are SKAdNetwork and AdAttributionKit?

After ATT (App Tracking Transparency) cut off mass IDFA access, the click-install-event chain cannot be reconstructed server-side by device identifier anymore. Apple replaced that mechanism with a privacy-preserving scheme:

• The attribution decision is made by iOS on the device, not by the network or tracker.
• What comes back is an aggregated postback: no device ID, no user-level data, a limited field set.
• Fingerprinting is banned under App Store rules - attempts to rebuild identification through device fingerprints lead to app rejection.

Calling the attribution APIs does not require ATT permission: apps call them regardless of the user's tracking authorization status. That is the documented position of the AdAttributionKit framework.

The practical consequence for media buyers: iOS reporting is always aggregated and delayed. Which framework to pick is not your decision - reading what it returns is.

How does AdAttributionKit differ from SKAdNetwork?

One fact confuses even experienced buyers: there is no separate "SKAN 5". Rumors of one circulated after WWDC 2023, but Apple never shipped such a version - the roadmap merged into the new framework. Official release notes list only versions 1 through 4 of SKAdNetwork.

The core mechanics match completely: the same three conversion windows, the same privacy thresholds, the same fine and coarse conversion value format. Apple explicitly names SKAdNetwork as the predecessor and recommends networks migrate while keeping compatibility: a registered SKAN ad network identifier works in both frameworks.

For traffic buyers this means one thing: the debate of "SKAdNetwork or AdAttributionKit" is misplaced. The ecosystem makes the choice - your ad network and the app SDK. Your job is understanding the shared reporting mechanics.

How do postbacks work: windows and delays?

Window mechanics is the central concept to grasp before reading any iOS numbers:

1. The first window opens at install and lasts two days. The app can keep updating the conversion value until the window closes; later updates land in the second and third windows.
2. The second window covers days 3-7 and the third covers days 8-35. Only coarse conversion values are available there.
3. After each window closes, the device adds a random delay before sending the postback: 24-48 hours for the first, 24-144 hours for the second and third.

Typical scenario: you launch a campaign today, real postbacks arrive between day two and day six, and the full three-window picture lands about six weeks later including the random delay. Any campaign judgment before those deadlines is based on platform-modeled numbers, not measurement.

Lock window changes the rules inside the first window: the app can lock the conversion value early, the postback is prepared immediately, and further updates are ignored. That trades late events for a faster signal.

Click-based attribution gives the device 30 days to register an install; view-based gives 24 hours. After install, the app has 60 days to send the first conversion value update. Re-engagement in AdAttributionKit uses a shorter window - two days for the first update.

What are crowd anonymity tiers and where does the data go?

Crowd anonymity is the mechanism most often behind "missing" conversions. The tier is computed on the device at download time and determines which fields the first postback carries:

Three consequences worth memorizing:

• Apple publishes no numeric thresholds anywhere. The check runs on-device in real time, and the only way to reach a higher tier is scaling homogeneous volume.
• Source identifier length gets picked by the system itself: it computes the tier for the 2-, 3-, and 4-digit variants and takes the best. At low tiers even a long identifier collapses to two digits - roughly 100 buckets for the entire campaign structure.
• The Android habit of many small ad sets per creative breaks iOS data collection: each branch gathers too little volume to pass the threshold. Concentrating budget into fewer campaigns directly increases available data.

How do conversions fit into 6 bits: fine and coarse conversion value?

Conversion value is set by the app developer: each meaningful in-app event translates into a number between 0 and 63. The 64-value budget gets distributed across everything you want to measure. A typical MMP schema looks like this:

• Revenue gradations: purchases bucketed by amount. A classic legacy AppsFlyer mapping: $1-$63 in $1 steps or $1-$630 in $10 steps.
• Key events: registration, trial, subscription each receive dedicated values.
• Priorities: the priority component ranks events so that more valuable ones overwrite less valuable ones - high-priority measurements displace low-priority ones.

Coarse value is Apple's answer to low tiers: even when exact values are unavailable, the device passes a rough low/medium/high estimate across all three windows. Practical takeaway: map coarse grades onto a meaningful scale, such as low = event happened, medium = mid-size purchase, high = large purchase.

The common mistake is a primitive schema: one activation event with no fine values. It technically works but offers nothing to optimize on: the platform sees no difference between an empty install and a target action. The inverse mistake - trying to give every purchase amount its own value - exhausts the budget before key events get any.

Where to build the schema when working with multiple networks is a real practitioner question. It depends on the stack: with an MMP in the chain, the schema lives there and propagates to networks; without one, each network is configured separately and value consistency across networks is lost. See MMP vs affiliate tracker for the division of roles.

Do you need to migrate from SKAdNetwork to AdAttributionKit?

Apple documents the interoperability plainly: .skadnetwork and .adattributionkit network identifiers work in both frameworks, the system ranks impressions from both sources together and picks a single attribution winner, and conversion value updates made through SKAdNetwork mirror into AdAttributionKit. A telling fact: Apple Ads itself registered as an ad network in AdAttributionKit in spring 2025.

What migration actually delivers:

1. Re-engagement: click-based attribution of repeat app opens starting with iOS 18. A separate conversion-type=reengagement in postbacks, limits per month per app and per year per device. For retention campaigns this is the first native way to measure returns without MMP modeling.
2. Alternative marketplaces: apps distributed outside the App Store (the DMA requirement in the EU) are invisible to SKAdNetwork entirely.
3. Configurable rules: AttributionWindows narrows the standard 30-day click window down to 1-30 days; AttributionCooldown sets a pause between counted conversions from 0 to 720 hours.
4. Testing: development postbacks under Settings > Developer generate postbacks on-device without real ads, with tier simulation. Test delays shrink from days to minutes.

Technically, migration belongs to the SDK and ad network, not the buyer. From the media buying side it is enough to confirm your networks route traffic through AdAttributionKit where possible and your MMP parses the new postback fields correctly.

Why do iOS numbers disagree with the backend?

The classic mismatch scenario: three days in, the backend counts hundreds of installs while the dashboard shows zero. Causes stack independently:

1. Postback delay: the first postback travels 24-48 hours after its window closes, the second and third up to 144 hours. Last week's data may arrive next week.
2. Privacy thresholds: part of the traffic landed in Tier 0-1, giving the platform minimal fields or nothing.
3. Modeled data: platforms reconstruct the picture with models, and at ad set and ad level practitioners themselves treat SKAN figures as extrapolation, not measurement.
4. Extra layers: consent-driven aggregation in the EU, and conflicts with server-to-server billing stacks (subscription services disable automatic SDK event logging for deduplication - and on-device SKAN physically stops receiving the data it needs for postbacks).

Reading anti-patterns that cost money:

• Reacting to daily ROAS swings while postback delays are live: the platform algorithm receives feedback with lag and overcorrects in cycles. Practitioner approach: rolling windows of five days or more.
• Direct comparison with Android: Android campaigns in the same geos run on device-level attribution while iOS runs on aggregated reporting. Different layers, not broken tracking.
• Optimizing creatives off ad-level SKAN figures in TikTok or Snap dashboards: that is platform extrapolation, not measurement.

Treat SKAN reporting as a directional indicator and reconcile against the backend on a fixed window, for example weekly cohorts by install date.

Checklist for privacy-limited iOS campaigns

1. Verify a conversion schema actually exists: in Meta that is the SKAdNetwork schema in Events Manager; a lone Activate App event is a red flag of primitive setup.
2. Concentrate budget: fewer campaigns and ad sets raise the odds of passing crowd anonymity thresholds and getting a full source identifier with fine values.
3. Distribute the 64 values deliberately: priority to valuable events, revenue bucketed into gradations, coarse scale mapped to something readable.
4. Do not judge a campaign before 72 hours: the first postback is still in transit, and anything the dashboard shows is modeling.
5. Reconcile against the backend on a fixed window: weekly cohorts instead of daily charts.
6. Never optimize off ad-level SKAN numbers: campaign-level is the only measured layer; use your own tooling or geo splits for creative decisions.
7. Use AdAttributionKit development postbacks (iOS 18.4+) to validate the setup before spending budget.

If you push web traffic through prelanders toward app offers, remember: SKAN covers only the final install. Everything upstream - clicks, prelanders, sub-IDs - lives in your tracker, and signal quality there depends on conversion delivery setup covered in server-side tracking vs browser pixel.

Where does Most fit?

SKAdNetwork and AdAttributionKit cover one leg of the iOS funnel: installs and in-app events inside the app. Everything before installation - clicks, prelanders, routing, sub-IDs - lives in your tracker, and conversions from there need server-side delivery so ad platform algorithms get signal faster than aggregated postbacks ever could.

Most automates exactly that last hop: delivering conversions from Keitaro and other trackers into Meta CAPI and TikTok Events API with correct identifiers, timing, and deduplication. The free manual pixel-checking tool is Pixel Activator; automated delivery is Most.

If traffic reaches the app through a web wrapper - for example, a OneLink-class solution - you can connect the web part of the funnel to MMP attribution through your tracker. On entry, the MMP generates its click identifier and passes it to the Keitaro offer as a sub-ID. Keitaro stores it on the click and sends it back to the MMP via an S2S postback when the conversion lands. This joins web-funnel data - prelanders, sub-accounts, offers - with install attribution: the tracker shows not just the conversion but which campaign or creative produced it. For SKAN campaigns this adds an extra signal layer on top of Apple's aggregated postbacks.

Summary

iOS reporting without IDFA will remain a trade-off between privacy and granularity. Buyers lose when they expect device-level precision from it; they win when they build a deliberate conversion schema, concentrate volume, and reconcile aggregates against their own data.

Sources