SKAdNetwork 4 and AdAttributionKit Conversion Value Setup

A SKAdNetwork conversion value is six bits. Sixty-four states, one of which goes to the null case, and every question you want iOS to answer has to fit inside the rest. Most schemas we inherit spend all of them on revenue buckets, and then the app turns out to sit below Apple's crowd anonymity threshold on most campaigns and receives coarse values only, low, medium and high, which makes the whole mapping table decorative. We measure where your campaigns actually land against those tiers first, then design for the tier you are in rather than the one you would prefer. How the schema gets decided: We pull ninety days of your own first-party D0 through D7 data and look at the shape of it. A beauty app with a first purchase twenty minutes after install and a crypto wallet whose first deposit lands on day nine do not get the same schema, and neither gets a generic revenue ladder. Fine values are allocated against the distribution you have: bucket edges land on percentiles rather than round dollar figures, so adjacent buckets carry similar install volume and the signal survives quantization. Where the app monetizes too late for the measurement window to see anything at all, we encode funnel position instead and say so plainly, rather than shipping a revenue schema that faithfully reports zero. Windows and locks: SKAN 4 gives three postback windows, through day two, day three to seven, and day eight to thirty-five, and each returns a value only if the campaign clears its anonymity tier at that moment. We decide per window what the value means, when updatePostbackConversionValue should be called, and when to lock early. Locking is the decision people get wrong: an early lock buys a faster read and forfeits everything after it. Which campaigns get which behaviour, and why, is written down. AdAttributionKit: Where re-engagement or alternative marketplace installs matter, we implement AdAttributionKit alongside SKAN rather than instead of it, including impression registration and re-engagement postbacks, validated against Apple's developer-mode postbacks before a dollar moves. Both paths write into the same decode table so your reporting does not fork into two truths. What we ship: The schema and its mapping table as a versioned document. The implementation as a pull request into your app, reviewed with your engineers rather than thrown over a wall. MMP configuration in AppsFlyer, Adjust, Singular or Branch. A developer-owned postback endpoint so you hold copies independently of your networks. A decode and QA plan with test postbacks verified end to end. What we do not do: We do not model revenue and funnel depth in the same value space and pretend both survived. We do not report a SKAN figure without the share of postbacks that arrived null sitting next to it. We do not tune a schema toward what a particular network's dashboard rewards. And we do not start without a scheduled app release inside the engagement window, because this work ships in the binary and a schema sitting in a document is worth nothing. Who this is not for: Android-only apps. Apps whose largest campaign runs a few hundred installs a day, where you will see coarse values almost always and the honest recommendation is a simpler schema your own team can maintain. If we find that in the first week we say so and close the engagement at the assessment fee. Also not for teams who want the schema redesigned quarterly: the value of a stable mapping table is that last quarter's data is still readable.