Designing a SKAN conversion value schema

A SKAN conversion value schema is the six-bit map, sixty-four values, that has to carry everything a buyer needs to know about early user quality without ever seeing a single device-level record. Get the map wrong and nothing breaks loudly. It fails quietly instead, by handing bidding algorithms a signal that looks precise while it measures the wrong thing. By the time the studio notices, spend has already scaled against it.

Fine versus coarse values

SKAN 4 gives a schema designer two tiers per postback. The fine-grained value, the full six-bit range, only arrives above a per-source-app minimum install threshold; the coarse value (low, medium, high) still fires below that threshold, preserving some signal on smaller campaigns. So a schema built only around fine values goes dark on exactly the long-tail sources and smaller test campaigns where a buyer most needs early signal, because those volumes are the ones most likely to sit under the crowd-anonymisation floor.

Design the coarse tiers deliberately rather than letting them default.

Map your most commercially meaningful threshold, usually the boundary between a player who reaches a monetisation moment and one who does not, onto the coarse boundary itself. A suppressed fine value then degrades into a coarse read that still tells good campaigns from bad ones.

What to encode, by genre

A casual game's schema should prioritise early engagement depth over monetisation events. Casual titles monetise thin and slow, and the signals that predict retention (sessions completed, levels cleared, tutorial finished) arrive well before any purchase would. A mid-core or RPG schema goes the other way: weight it toward the handful of early purchase or currency-spend events that reliably predict a payer, because mid-core monetisation concentrates hard in a small cohort and the schema's job is mainly to help bidding find more of that cohort faster.

Whichever genre, resist cramming in every event you can think of. Sixty-four values is a hard ceiling. A schema that tries to encode ten different behaviours ends up giving too few values to the two or three that actually predict revenue, and the resolution thins out precisely where it matters.

Postback windows and lock-in

SKAN 4's three-postback structure changes what a schema can even attempt at each stage: an initial window measured in hours, a second in the following days, a third later still. The first postback has to work with very early signal: session count, tutorial progress, nothing monetisation-related. Almost no player has reached a purchase decision that fast. Real early-revenue signal only becomes viable in the second and third postbacks, and a schema should shift its value definitions accordingly instead of reusing the first postback's logic across all three.

Lock-in, the SKAN mechanic that fixes a conversion value once a timer starts and blocks further updates inside that window, means a schema also has to account for when in a session a value gets set. Picture a schema that only updates conversion value on session end while lock-in bites in an intermediate window. It will systematically undercount the long sessions, another way a plausible-looking schema quietly misreports quality.

Validating against day-7 revenue

None of this matters until the schema meets ground truth. Take a cohort where deterministic revenue data outside SKAN still exists, typically an Android cohort, or a web shop where full attribution holds, and compare the conversion values your schema would have assigned against actual day-7 revenue per user. What you want is a clean monotonic relationship: higher assigned value, higher actual revenue, with reasonably tight bands. Two conversion-value buckets with overlapping or inverted revenue outcomes point to a design flaw. Fix it before it drives further bidding decisions on iOS, where the same validation cannot run directly. That is the whole reason for doing the exercise on the platform where you still can.

Re-run the validation whenever the game's monetisation design changes meaningfully, not only at schema launch, because a new event or a rebalanced economy can quietly break a schema that suited an earlier build. The schema is a living artefact tied to the game's design.

Not a one-time SKAN configuration task to file away after launch.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• SKAN Conversion Value Mapping, Revisited for 2025
• SKAN 4 and AdAttributionKit, a year in: what buyers actually get back