SKAN 4 in Practice: How to Measure iOS Campaigns When Apple Holds the Data

What SKAN 4 actually gives you

SKAN 4 delivers up to three postbacks per install, across windows of roughly 0–2, 3–7 and 8–35 days. Each carries a conversion value: fine-grained (0–63) in the first window when crowd anonymity allows, coarse (low/medium/high) otherwise and in later windows.

The design constraint is real: you get a limited, delayed, privacy-throttled signal. The opportunity is that everyone faces the same constraint — so the teams that encode value intelligently measure better than everyone else.

Designing your conversion value schema

Sixty-four values sounds generous until you try to encode a business in them. The schemas that work map value ranges to predicted LTV tiers rather than raw events: a user who completes onboarding and makes a first purchase in 48 hours is worth more than ten who each fire a single event.

Reserve the coarse values deliberately too. 'Medium' users in window two are a signal worth optimizing toward — don't waste them on a default mapping.

Modeling through the gaps

Postbacks arrive 24–72 hours late, some installs never report due to privacy thresholds, and later windows cover only a fraction of users. Treating SKAN data as complete is the classic mistake.

The working approach: combine SKAN signals with modeled conversions, cohort-level revenue curves, and your Android data as a behavioral reference. AI-driven bidding systems handle this natively — inferring expected value from partial signals and updating as postbacks land.

Operational checklist

Before scaling iOS spend, verify: your MMP's SKAN configuration matches your schema, your DSP receives and learns from postbacks automatically, and your reporting compares SKAN-attributed value against modeled expectations. If any of those is manual, it will break at scale.