Free tool

Version Adoption Calculator

Enter your active users and how many are on a new release to get adoption %, a plain rollout read, and — if you add a daily adoption rate — roughly how long until you hit your target. Runs entirely in your browser; nothing you type is sent anywhere.

42%
Early rollout

Still early in the rollout. Fine if the release is fresh; worth investigating if it has been out a while (forced-update prompt, store rollout %, cache).

4,800 more users to reach 90% — about 8 days at your current pace.

The explainer

Why adoption is the number under every release metric

Version adoption is the share of your active users on a given release: users on the version ÷ total active users × 100. It is easy to overlook because it feels like an operational detail, but it is the denominator for almost every release-health call you make.

A clean metric on a barely-adopted release is not reassuring

Crash-free rate, error-budget burn, and “which release caused the spike” are all read per version. If your new build looks great but only 20% of users are on it, you have not actually learned much yet — the other 80% simply have not exercised it. Adoption tells you how much weight to put on the stability numbers you are staring at.

What slows a rollout

When adoption stalls on a release that is not brand new, it is usually one of a few things: a staged store rollout still capped below 100%, no in-app update prompt so users upgrade only when the store gets around to it, or a chunk of users who are not returning in the window at all. The fix depends on which one it is — the calculator just tells you how big the gap is and, if you know your daily pace, roughly how long closing it will take.

The projection is a straight line on purpose

Days-to-target here is just remaining users ÷ users per day, rounded up. Real adoption curves taper — fast at first, then a slow tail — so a linear estimate is a back-of-envelope ETA, most trustworthy for the next few days. It is meant to answer “are we talking days or weeks”, not to pin a date.

Questions

What is version (release) adoption?+

The share of your active users who are running a given app version: users on that version ÷ total active users × 100. It tells you how far a release has actually rolled out — which matters because a crash or metric on a version only affects the slice of users who are on it.

What adoption counts as "rolled out"?+

There is no universal number, but most teams treat ~90%+ on the latest version as effectively rolled out and stop babysitting the long tail. 60–90% is "most users migrated," and below ~25% on a release that is not brand new usually means something is holding it back (a staged store rollout cap, no update prompt, or users who are not returning).

How is the "days to target" estimate calculated?+

It is a simple constant-rate projection: remaining users to reach your target ÷ the daily adoption rate you enter, rounded up. Real adoption curves taper rather than stay linear, so treat it as a back-of-envelope ETA, not a forecast — it is most useful for the next few days, not weeks out.

Why does adoption matter for crash and release health?+

Crash-free rate, error-budget burn, and "which release caused the spike" are all read PER version. If a new release is only 20% adopted, a clean crash-free rate on it is not reassuring yet — 80% of your users have not hit it. CleverQA tracks adoption automatically per release once your crash/release data is connected, so the version context sits next to the stability numbers.

Want adoption tracked next to your release health?

Connect your crash and release data and CleverQA shows adoption per release automatically — right beside crash-free rate and the “which release caused the spike” answer, so the version context is never missing.