SKAN returns exactly one value per install: the conversion value. Deciding what goes into that narrow slot is the part of iOS measurement that takes the most actual work.
64 slots is smaller than it sounds
The fine value is six bits — 0 to 63, so 64 slots. That looks generous at first.
Then you list what you want to encode. Signup (2) × tutorial complete (2) × first purchase (2) × five revenue bands is already 40 slots. Add one retention signal and you are over.
But the real constraint is not slot count, it is volume per slot. Split into 64 and a campaign doing 500 installs a day averages eight per slot. At that level noise buries the signal.
The design rule: split only where decisions differ
Ask one question per split: "if this value changes, do I do something different?"
If you split revenue into five bands but only ever adjust bids on the top two, the other three consume slots without informing anything. Merge them.
A schema you can read beats a schema that covers everything. That is the whole principle.
Four common mistakes
One: encoding behavior outside the window. The first window is days 0–2. If your average purchase lands on day 5, that signal never reaches it. Check your real conversion-delay distribution before fixing the schema.
Two: dropping raw revenue in. Revenue is continuous and must be bucketed; tight buckets run out of slots fast. Split only the bands that matter.
Three: remapping often. Change the mapping and data before and after mean different things. If you must, record the date and never blend the periods.
Four: designing finely in windows 2 and 3. Those return only low, medium, and high. Ten LTV bands there collapse into three.
The platform learns from this value
This is the real reason design deserves care. The conversion value is not a reporting number — it is the algorithm's training signal.
Feed it a bad signal and the platform optimises that signal diligently. Put tutorial completion at the top and it brings users who finish tutorials. If those are not the users who spend, CPA improves while revenue does not.
Try this today
One. Pull the mapping and count actual install volume per value. More than half the slots nearly empty means the schema is sliced too finely.
Two. Check what sits at your top value, then verify that users who performed that action actually have higher D30 revenue. If they do not, you are handing the algorithm the wrong objective.
Let's be honest
Do not treat conversion-value-based ROAS as an absolute number. It approximates revenue encoded into a narrow value, and revenue beyond the measurement window is never captured at all. Ranking campaigns against each other is about as far as it safely goes.
And when values stop arriving, do not suspect the schema first. Below the privacy threshold a perfect schema still returns no fine value. Per-window rules are in Apple's documentation.
The full migration order is covered in SKAN 4 migration.