SKAN Conversion Value Mapping, Revisited for 2025

A conversion value schema is not a settings screen you configure once and forget. SKAN conversion value mapping decays as a game's monetisation curve shifts, and a schema built for a title's launch window rarely still reflects reality by its sixth month live. Revisit the mapping on a fixed cadence rather than only when a dashboard stops making sense. That habit is the difference between an attribution model informed by SKAdNetwork's numbers and a mapping that is quietly wrong.

Why a fixed schema goes stale

SKAdNetwork compresses a user's early value into a small number of possible conversion values, decoded on a schedule the developer sets through the postback windows rather than in real time. A schema built to bucket early revenue and engagement events makes sense against the spend curve a game had at launch. Then the game changes. Six months on, a live-ops calendar with new events, a pricing ladder that has shifted, a subscription tier that did not exist at launch: all of them change which early behaviours actually predict a valuable cohort, while the schema carries on rewarding the same old signals.

What to remap, not just re-tune

The instinct when a schema stops correlating with post-attribution revenue is to nudge value thresholds. That treats a structural problem as a calibration problem. The better question is whether the events feeding the schema are still the right events at all. A game that has added a battle pass since launch, for instance, under-maps the buyers who bought that pass on day one and spent only a small amount inside the base game, so long as the schema stays weighted toward first-session IAP alone. Remapping means revisiting which events populate the schema before you touch where the thresholds sit inside it.

A worked example, illustrative figures

Take a hypothetical hybrid-casual title whose first-postback schema originally split value only by whether a user finished the tutorial and made any purchase under five dollars. Assume the game later added a subscription at four dollars a week and a battle pass at eight dollars a season. A schema still built around the original two-event structure codes a battle pass buyer identically to a five-dollar in-app purchase buyer, collapsing two very different value tiers into one signal. Rebuild it so that subscription starts sit in one band, battle pass purchases in another and small one-off IAP in a third, even at the cost of some resolution elsewhere in the schema. The correlation between the postback and the revenue a UA team actually cares about optimising toward comes back.

Postback timing is part of the mapping, not separate from it

SKAN 4's multiple postback windows extend measurement past the single postback SKAN 3 offered, but only if you design the conversion value schema with each window's purpose in mind. The first postback should still carry the fastest, highest-confidence early signal. Load it with an event that only a minority of users trigger inside the first day and you have added noise to the one window that most needs precision. Later windows can absorb slower-maturing signals, a first week's retention or a first subscription renewal among them. Treat postback timing and value mapping as one design decision. Configure the timing once, map separately, and you leave measurable accuracy on the table, which is the same point that follows from the case for reconciling attribution windows across IAP and ad revenue we made in Attribution Windows for Hybrid-Monetisation Games.

Coarse-grained values are not a fallback, they are a design choice

SKAN 4 lets a coarse-grained value come back alongside a fine-grained one, or instead of it. The coarse tier has three levels: low, medium, high. Teams often treat it as a privacy-threshold fallback rather than a deliberate design decision in its own right, and that undersells it badly. A coarse value that returns reliably on a higher share of postbacks can beat a fine-grained value that decodes for only a fraction of installs, because the fine-grained one depends on an event most users never trigger. Decide upfront which decisions the schema has to support, whether a campaign-level spend shift or a creative-level optimisation. Then match the coarse or fine-grained mapping to that decision instead of defaulting to fine-grained everywhere.

A review cadence that catches drift before a dashboard does

A standing routine that works: check the schema against actual post-attribution revenue every full live-ops season or every quarter, whichever is shorter. Any new monetisation feature triggers an out-of-cycle review, whether that is a subscription tier, a currency bundle, a battle pass. Don't wait for the scheduled slot. And keep a record of what each value band represented at each schema version, because a schema changed without documentation makes historical postback data very hard to read later.

Documenting the schema pays off when someone new inherits it

A schema with no written record of its own history becomes a liability the moment the person who built it moves to another project or leaves. Their successor inherits a set of numeric value bands with no memory of what each one represented, and rebuilding that context from scratch, or worse, guessing at it, is how a perfectly good schema quietly loses the team's trust. A one-page log helps: the date of each schema version, which events fed it, why it changed. Maintaining that alongside a quarterly review takes a few minutes and saves considerably more the first time a new measurement lead has to make sense of a schema they did not build.

Where AdAttributionKit changes the calculus

Apple's AdAttributionKit, positioned as SKAdNetwork's successor, keeps the same conversion value mechanics as its foundation while extending re-engagement measurement, and MMPs have spent the year publishing migration guidance as the newer framework matures. None of that changes the discipline described here. A better successor framework sitting on top of a stale value schema still produces a stale signal. The schema work has to happen whichever framework does the decoding, which is exactly why treating conversion value mapping as a one-time setup step rather than a recurring design exercise stays the more expensive mistake, well past whichever framework happens to be current.

Related archive reading

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

• Designing a SKAN conversion value schema
• Creative Decay Curve by Genre Looks Different