How conversion values encode worth for Apple Ads

What a 6-bit value can and cannot say#

A conversion value is a single integer from 0 to 63 standing in for early user quality, reported through privacy frameworks instead of event streams. It cannot narrate a journey; it can only flag which bucket the first day or two of behaviour fell into.

That constraint forces choices: revenue bands, funnel milestones or engagement tiers, but never all three at once. The SKAdNetwork value reference defines the range and update mechanics. Frame the decision with the Apple Ads hub measurement map before committing.

Teams that accept the crudeness design better schemas than teams that fight it. Sixty four buckets beat zero signal every time.

Pick one schema per app#

One app, one schema, reviewed quarterly: revenue bands for shops, funnel milestones for services, spend or progress tiers for games. Mixed schemas across platforms make reporting unreadable and optimisation incoherent.

Document the mapping where analysts and engineers both see it: value 12 means what, in money or milestones, and who approved it. Our gaming playbook and our shopping playbook show worked mappings for their verticals. Keep the schema stable across AdAttributionKit and SKAdNetwork during dual running.

Changing schemas resets every trend line, so schedule changes with releases and annotate the cutover date in all dashboards.

Update fast, then stop touching it#

Update the value as behaviour unfolds, ideally within the first 24 hours while the postback timer can still extend. Each qualifying update pushes the reporting window out, buying the user more time to prove worth; silence lets the timer expire and locks whatever value stands.

Instrument updates server side where possible so app backgrounding never strands a high value user on a low number. The AdAttributionKit update reference documents the extension rules precisely. Pair timing discipline with our postback windows guide for the full calendar.

Audit update rates monthly: if most users sit on the install default, the schema measures nothing and needs redesign.

Map money before launch#

Revenue band schemas must be calibrated against real purchase distributions before launch, never guessed from pricing pages. Pull a year of order values, cut bands that split revenue evenly and assign the top values to the bands that fund growth.

Leave headroom at the top for whales and a clear zero band for installs with no commercial signal yet. Null is not zero, as our null rates guide insists, so keep suppressed cohorts distinct from genuine zero value users. Sanity check bands against US and UK benchmarks where category data exists.

Revisit bands when prices or mixes shift: a schema tuned for one economy lies gently in the next one.

Verify values end to end#

Prove every value from tap to dashboard with scripted test users before trusting a single chart. Fire the events, watch the value climb, wait out the delay and confirm the exact integer lands in partner reporting.

Both AppsFlyer and Adjust expose raw postback views for this verification, and our partner integration guide shows where to look. Log device side values beside dashboard rows until they agree for a full week.

Skip this step and every later argument about performance rests on unverified plumbing. Verification is dull and indispensable.

Read values beside console revenue#

Value distributions audit creative and audience quality; console revenue paces spend. Use the two together: when high value shares climb but console revenue lags, suspect delays; when both fall, suspect the traffic.

Reconcile with the method in our reconciliation guide and keep value mix charts in the weekly pack. If the numbers diverge persistently, talk to folkfox before rebuilding schemas that may be innocent.

Stable schemas, fast updates and honest reads turn six bits into genuine guidance.

Frequently asked questions#