SKAdNetwork 5: what changed and what to ship this quarter

SKAdNetwork 5 has been generally available long enough that there's no excuse left for staying on SKAN 4. The headline changes are re-engagement attribution, coarse conversion values across three postback windows, and a richer crowd-anonymity tier. The migration is mostly mechanical — here's the checklist. (And everything below transfers to AdAttributionKit, which inherits SKAN's semantics on newer iOS.)

What is SKAdNetwork, in one paragraph?

SKAdNetwork is Apple's privacy-preserving install attribution framework. Rather than letting an ad network identify the individual who installed, iOS itself sends the network a signed postback saying an install happened, which campaign drove it, and a limited encoding of what the user did afterwards. It is deliberately aggregated, delayed, and lossy — no attribution provider can enrich it, and none can make it real-time.

What changed in SKAdNetwork 5?

The practically important change is re-engagement. Until SKAN 5, reactivation spend on iOS was measurable only through your own first-party signals; now Apple will attribute it, which means your reactivation budget can finally be compared against acquisition on something close to like-for-like terms.

How do crowd anonymity tiers affect what you receive?

Crowd anonymity is Apple's throttle on postback detail: the fewer installs a campaign produces, the less it tells you. At the lowest tier you get a postback with no conversion value and a coarse source ID. Higher up, the fine value and the full hierarchical source ID arrive.

This has a direct structural implication for how you buy. Ten campaigns at low volume can return less usable data in total than three campaigns at higher volume, because each one falls into a lower tier. If your SKAN reporting looks empty, the first thing to check is not your integration — it is whether you have fragmented spend below the threshold where Apple will tell you anything.

Update your conversion value schema

SKAN 5 keeps the fine conversion value (0–63) and the three coarse buckets across the three postback windows. Re-map your event values so 'trial started' lands in the right window, and audit the crowd-anonymity tier each event is likely to receive.

The design mistake most teams make is encoding too much. Sixty-four values feels roomy until you try to represent revenue bands, funnel stage, and cohort in the same integer, and then discover that the value you actually needed sat in a window that had already closed. Pick the single decision the value has to inform — usually a revenue band or a qualified-user flag — and encode that well.

// Fine value 0–63; the coarse bucket is what later
// postback windows will actually report.
LinkTrail.shared?.updateConversionValue(42, coarseValue: .medium)

Handle re-engagement postbacks

Re-engagement is the most underused feature in SKAN 5. If your acquisition is mature and your reactivation budget is meaningful, you should be lighting this up — and you should be tagging postbacks accordingly in your warehouse.

Two things to get right when you enable it. Tag re-engagement postbacks distinctly in your warehouse from day one — they will otherwise inflate your acquisition numbers and nobody will notice for a quarter. And accept that SKAN re-engagement and your own first-party re-engagement measurement will disagree, because they use different windows and different definitions of a lapsed user.

Is SKAdNetwork being replaced by AdAttributionKit?

AdAttributionKit is the successor, and it inherits SKAdNetwork's semantics — the same conversion value model, the same postback windows, the same crowd anonymity throttle. Apple's own framing is migration rather than replacement, and SKAdNetwork postbacks continue to arrive. Practically, this means the conversion value schema you design now carries over, so the work is not throwaway.

The meaningful addition is support for alternative app marketplaces and re-engagement handling that fits the newer install flows. If you are shipping today, implement against both: register for SKAdNetwork attribution and update conversion values through one code path, and let the SDK route to whichever framework the OS version supports.

Don't trust the deck — trust the postback

Ad networks publish their SKAN reporting in summary form, often with proprietary smoothing. Always ingest the raw postback yourself, store it indefinitely, and reconcile against the network's reports. If you're using LinkTrail, the postback endpoint is one route handler — no excuse not to.

Does SKAdNetwork replace an attribution platform?

No — it covers one slice. SKAdNetwork tells you that a campaign produced installs, in aggregate, after a delay, with no user-level detail and nothing about which link was tapped. It cannot route a user to the right screen, cannot carry a promo code through an install, and reports nothing at all for the owned channels — email, SMS, referral, QR, influencer links — where a lot of installs originate.

So the two run alongside each other. SKAN and AdAttributionKit measure paid iOS network spend on Apple's terms; deferred deep linking and click-based attribution handle everything else and deliver the experience. LinkTrail does the second and reports the first, which is why our SDK exposes registerForSKAdAttribution and updateConversionValue rather than pretending the framework isn't there.