SKAN 4 conversion values are the only window Apple leaves you into what happens after an install. Get the schema wrong and you're optimizing blind for weeks; get it right and you can still measure real outcomes on iOS. Here's how to set them up.
What a conversion value is
A conversion value is a small piece of information you encode about early user behavior, which Apple reports back in aggregate. SKAN 4 gives you two kinds: a fine value, 0 to 63, in the first window, and a coarse value of low, medium, or high in later windows.
You never see who did what. You only get counts of installs bucketed by the values you defined, so those buckets have to be chosen deliberately.
The three measurement windows
SKAN 4 reports across three postbacks, not one, which is the big change from SKAN 3:
- Window one, roughly days 0 to 2, carries the fine-grained 0 to 63 value.
- Window two, about days 3 to 7, carries a coarse value.
- Window three, about days 8 to 35, carries another coarse value for longer-term signals.
That lets you measure early activation and later value like retention or subscription, instead of only the first 24 hours.
Design the schema first
Before touching code, decide what those 64 fine values mean. The common approaches are to encode revenue buckets, a sequence of funnel milestones, or a mix packed into the bits of the value.
A simple, revenue-oriented mapping might look like this:
Conversion value schema (window 1, fine) 0 no measurable event 1 registration complete 2 tutorial finished 3 add to cart / key action 10-19 purchase, $0-$9 20-29 purchase, $10-$49 30-39 purchase, $50+ 40-63 reserved for future events
The rule of thumb is to spend your limited values on the decisions you actually make, not on everything you could log.
Implement it in the app
In practice your MMP owns the postback, so you configure the mapping in its dashboard and call its SDK when a relevant event fires, rather than calling Apple's API by hand.
// on a meaningful in-app event AppsFlyerLib.shared().logEvent( name: "af_purchase", values: ["af_revenue": 12.99, "af_currency": "USD"] ) // the MMP maps this to the SKAN conversion value // and calls updatePostbackConversionValue under the hood
Letting the MMP manage the value avoids the classic bug of two systems fighting over what to send Apple.
Why the schema is a one-way door
There's a catch that makes the design step matter more than it should: SKAN reports are aggregated and delayed, so if you change the meaning of value 20 halfway through a campaign, you can't cleanly separate the old definition from the new one in the data already in flight.
In practice teams treat the schema as semi-frozen, plan a version they can live with for a quarter, and document exactly what each value means so analysts reading the numbers months later aren't guessing. Reserving a few unused values up front gives you room to add an event later without a disruptive remap.
Mind the privacy threshold
Apple only returns the fine-grained value when a campaign clears a privacy threshold, a crowd-anonymity minimum of installs. Below it, you get a coarse value or null instead.
So schemas that split traffic into too many tiny buckets can backfire: you designed 64 levels of detail and Apple hands you "medium" because the volume was too low to be safe.
Test before you trust it
- Validate the mapping in your MMP's SKAN debugger with test events.
- Confirm each window fires and the values decode to what you intended.
- Only then judge campaigns on the data, once you know the pipe is clean.
SKAN 4 conversion values are a tiny budget of information standing in for everything a user does after install, so the schema is the whole decision. Design the buckets around choices you'll actually make, let your MMP own the postback, respect the privacy threshold, and iOS measurement stops being blind guesswork and starts being a real, if narrow, signal.
Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.
