SKAN 4.0 in 2026: How to Measure UA Performance When Most Teams Still Haven't Figured It Out

Four years after Apple's App Tracking Transparency (ATT) changed iOS advertising for good, you'd expect most app marketers to have iOS measurement under control. They don't.

A 2026 survey by Kochava Foundry found that only 21% of iOS app marketers describe their understanding of iOS attribution as comprehensive and confident. Another 48% say they have a basic understanding with unresolved blind spots, and 14% admit they have no clear picture of how it works at all. On SKAdNetwork specifically, 33% of marketers haven't implemented it at all, and only 11% say they're fully set up and actively optimizing their configuration.

That gap is exactly why this article exists. Every June, agencies rush out a "here's what changed at WWDC" post, and this year that post would be short: WWDC26 brought no updates to SKAdNetwork or its successor, AdAttributionKit. Apple's whole keynote was about Siri and AI. If you were waiting for Apple to hand you a simpler measurement system, that wait continues.

The good news is that SKAN 4.0 hasn't changed either, which means the tactics below are stable ground you can build on right now, without a big budget or a six-person analytics team.

SKAdNetwork (SKAN) is Apple's privacy-safe way of telling advertisers "your ad led to this install," without identifying the actual person. SKAN 4.0, released in October 2022, is the version most of the industry is (finally) running on. Here's what it changed versus earlier versions, in plain terms - and if you want a refresher on the tools that sit underneath this whole system, our guide to mobile attribution trackers covers how AppsFlyer, Adjust, and similar platforms fit in.

You can get up to three postbacks per install, not just one. Each postback covers a different window of the user's early lifecycle:

Each postback arrives with a random delay on top of its window (roughly 24–48 hours after postback 1's window closes, and 24–144 hours for postbacks 2 and 3), which is why SKAN data always feels "late" compared to what you're used to on Android or web.

"Fine" and "coarse" conversion values work differently. A fine value is a number from 0 to 63 that you map to specific user behavior — but it's only available in the first postback, and only if your install volume clears Apple's privacy bar. A coarse value is just "low," "medium," or "high," and it's available across all three postbacks with a lower privacy bar. In practice, most small and mid-size apps will lean on coarse values more than they'd like, simply because they don't have the daily install volume to reliably unlock fine-grained data.

Crowd anonymity decides how much you actually get. Apple sorts every postback into one of four "crowd anonymity" tiers based on how many installs a campaign generated. At the lowest tier, you get nothing — a null conversion value. At the highest tiers, you get a fine-grained value plus a longer "source identifier" (more digits in your campaign ID, which means more granular reporting - the difference between roughly 100 possible campaign breakdowns and 10,000).

One of the more useful, lesser-known data points here: an analysis by AppsFlyer of 240 million SKAN 4 postbacks found that 20 installs per campaign, per app, per day was enough to reach the higher tiers with 97% consistency. That's a genuinely reachable number for a small UA budget — you don't need Candy Crush–scale volume to get usable data. (Other agencies suggest budgeting closer to 100 installs/day as a safer cushion, since Apple has never published the exact threshold and it isn't guaranteed to stay fixed — treat 20 as the encouraging floor, not a promise.)

There's also a lockWindow option, which lets you "lock in" a conversion value early and get your postback faster, at the cost of not capturing anything that happens later in that window. Useful if your key user actions happen fast; risky if they don't.

Here's the gap in the current conversation. Most explainer content about SKAN 4.0 was written back in 2022–2023, right after it launched, and reads as if the whole industry adopted it immediately. It didn't.

• As late as January 2024, only 27% of all SKAN postbacks industry-wide were actually running on version 4 (AppsFlyer).
• By mid-2025, Meta was still sitting at roughly 44% SKAN 4 adoption, while TikTok had moved further ahead and Google, Meta, and Snap were largely still defaulting to SKAN 3 (Singular).
• Only by mid-2026 is SKAN 4 finally reaching majority adoption across the ecosystem (Kochava).

In other words, if your dashboards have looked inconsistent or hard to trust over the past two years, part of the reason is structural: you and your ad networks weren't always speaking the same version of the protocol.

Apple's actual next-generation framework, AdAttributionKit (AAK), has been available since March 2024 and picked up genuinely useful features at WWDC25 - configurable attribution windows, overlapping re-engagement windows, country codes in postbacks, and an easier developer testing tool. Almost none of that matters yet in practice: AAK adoption is still described as "negligible" by two independent sources (Singular and Kochava), and Kochava's 2026 survey found 27% of marketers hadn't even heard of it, with only 7% actively testing it. Don't deprioritize your SKAN 4 setup to chase AAK - the ecosystem simply isn't there yet.

Meanwhile, the big networks haven't been sitting still waiting for Apple. Google has its own Integrated Conversion Measurement, Meta runs Aggregated Event Measurement (and "Advanced AEM"), TikTok has Advanced SAN, and Snap has its own Advanced SAN-style product. Each of these blends modeled data with whatever SKAN signal is available. That's worth knowing, because it means "just implement SKAN 4 correctly" is necessary but not sufficient - you're always working with a layered system, not a single clean number.

Based on how the guidance above plays out in practice, the recurring mistakes are less about SKAdNetwork itself and more about how teams approach it:

1. The schema tries to do too much. Mapping revenue into 64 fine-grained buckets feels rigorous, but if your daily volume can't reliably fill those buckets, you're mostly generating noise and null values. Simpler, coarser schemas often perform better for smaller apps.
2. Campaigns are too small to clear the privacy threshold. If a campaign (or a single creative test) is running below roughly 20–100 installs a day, expect a lot of coarse or null data no matter how well-designed your schema is.
3. The schema optimizes for the wrong moment. Cramming your most important purchase event into postback 1 (Day 0–2) only makes sense if that event genuinely happens that early for most users - the same logic that applies when defining a target action for a CPA campaign: if the event you're optimizing for doesn't actually reflect real user value yet, you're forcing a signal where there isn't one.
4. There's no fallback for the 90% of traffic that isn't SKAN or consented. According to Kochava's mid-2026 attribution breakdown, only about 10% of iOS attribution today is device-level and consented, and SKAN itself accounts for roughly 11%. Apple Ads has grown to around 36% of iOS attribution volume (largely because it's one of the few channels where deterministic measurement is still possible). The rest is aggregate and modeled. If your measurement plan only accounts for the SKAN slice, you're planning around a fraction of your actual iOS traffic.

ATT consent is left entirely to Apple's default prompt, or skipped. This one is easy to fix and most teams still don't. Acceptance rates among users who are actually shown a prompt have climbed to nearly 70% in 2026 (up from around 37% when ATT launched), largely because people are simply used to consent prompts now. The catch: Kochava's data shows only about 2% of iOS installs are being prompted at all, because 24% of apps skip the prompt entirely and another 36% use only Apple's bare-bones default dialog with no explanation of value first. A well-designed pre-prompt screen that explains the benefit before the system dialog appears is standard practice, not a gray-area tactic - and it's one of the cheapest wins available to a small team.

You don't need an enterprise MMP contract or a data science team to run a decent SKAN 4 setup. Here's a sequence that works for lean teams:

1. Start with your business questions, not Apple's documentation. Before touching a conversion value table, write down two or three things you actually need to know: is this campaign profitable, is this creative better than that one, is this user segment worth more. Everything else is secondary.

2. Keep the schema simple on purpose. Use coarse values as your default and reserve fine values for cases where you know you'll have consistent daily volume. A short list of well-chosen events beats a comprehensive list of theoretically interesting ones.

3. Size campaigns to clear the privacy floor. Before launching a new campaign or creative test, check whether it can realistically hit the install volume needed to avoid null data. A brilliant creative test that only reaches 8 installs a day will teach you nothing through SKAN - you'll need to lean on other signals (in-app analytics, cohort behavior) for that test instead.

4. Map events to the window where they naturally happen. Onboarding and early engagement belong in postback 1. First purchases and trial starts usually belong in postback 2. Renewals and long-term revenue bands belong in postback 3. Resist the urge to force a late-stage event into an early window just because fine values are only available there.

5. Fix your ATT prompt before you fix anything else. If you don't have a custom pre-prompt screen explaining why you're asking, build one. This single change touches every other number downstream, since a larger consented population gives you a small but genuinely deterministic dataset to validate everything else against.

6. Treat SKAN as one input, not the whole answer. Combine it with your in-app analytics, a lightweight incrementality or holdout test where you can afford one, and basic marketing mix modeling for the large chunk of traffic that will never resolve to a clean, individual-level signal. Whatever mobile measurement partner sits underneath your stack (AppsFlyer, Adjust, and similar tools all handle SKAN differently), make sure someone on your team actually understands its defaults instead of trusting them blindly. You're not trying to eliminate uncertainty - you're trying to make decisions inside a reasonable range of it.

7. Revisit the setup quarterly, not once. Ad network support for SKAN 4 and AAK keeps shifting (as the adoption numbers above show), so a schema that made sense a year ago may be leaving data on the table today. A 30-minute quarterly review of null rates and postback volumes is enough to catch most drift.

SKAN 4.0 isn't new, and it isn't going away any time soon - AdAttributionKit exists, but the ecosystem hasn't shown up for it yet, and WWDC26 confirmed Apple isn't in a hurry to force the issue. That means the marketers who benefit most in 2026 won't be the ones waiting for a cleaner measurement system. They'll be the ones who quietly did the unglamorous work: a simple schema sized to their real install volume, a properly explained ATT prompt, and a realistic view of how much of their traffic SKAN can and can't explain.

None of that requires a big team or a big budget. It requires treating measurement as a habit rather than a one-time setup - which, given that two-thirds of marketers in Kochava's 2026 survey admitted to unresolved reporting gaps, is apparently still the rarest resource in mobile UA.