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.