Playbook: Design a SKAN Conversion Value Schema That Actually Predicts ROAS

Playbook: Design a SKAN Conversion Value Schema That Actually Predicts ROAS

Don't waste 6 bits on vanity events. Build the schema this way:
— List every post-install event, then rank by correlation to D7 revenue, not by frequency
— Decide encoding mode: coarse-grained (low/medium/high) for low-volume, fine-grained (64 buckets) for scale
— Allocate bits — e.g. 3 bits for revenue tiers, 2 for funnel depth, 1 for a key retention flag
— Set revenue buckets on a log scale ($0, $1-5, $5-20, $20+), never linear
— Lock your measurement window to the activity window (24-48h typical) so the timer doesn't expire early
— Document the mapping table and version it; an undocumented schema is a future outage

✓ Turns 6 bits into a genuine early-ROAS signal
✓ Forces you to identify your real value events
✗ Re-engineering mid-flight resets your learning data
✗ Coarse mode loses revenue granularity entirely

Verdict: Use log-scale revenue buckets for monetization apps; skip fine-grained if you do under ~1k installs/day per campaign.
Best for: Performance teams optimizing iOS in-app spend toward revenue.