SKAN 4 may return up to three window postbacks, with fine values available only in the first. The encoded signal is 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. Actual distribution and missingness differ, so that average alone does not establish whether the schema is useful.
Is your schema using the 64 values well?
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. An average purchase on day 5 does not mean no purchases occur earlier; check the fraction within the first two days. 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.
Check how the platform uses this value
This is the real reason design deserves care. Conversion values can support reporting and optimization. Check platform and MMP settings to establish which values influence the selected goal.
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
Pull the mapping and count actual install volume per value. If many slots are empty, check behavior distribution, missingness and return conditions before considering consolidation.
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.
Limits of this approach
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. Different missingness, buckets and maturity can distort campaign rankings too.
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.