The median time between sign-up and the moment a user actually gets what they came for — always read next to the activation rate.
In practice
This metric has a dangerous edge worth knowing before you steer by it: computed on the users who eventually activate, it improves when the slowest ones give up. The figure gets better precisely because the product got worse, and nothing inside it shows that. Hence two rules that cost nothing — use the median rather than the mean, which a handful of stragglers is enough to triple, and always publish the activation rate right beside it. The other common confusion is with onboarding length: they are different things, and the gap between them is often the finding. A flow finished in two minutes can still have a six-day time to value if value only arrives once a colleague approves an integration — in which case polishing the interface changes nothing.
The formula
Time to value = the MEDIAN of (timestamp of the activation event − timestamp of sign-up), over the users who reached it
- Median, not mean
A handful of users who activate six weeks late drag a mean far past anything a real person experiences. The median is the time half your activating users beat, which is a sentence you can act on.
- The activation event
The same one your activation rate uses — two different events make the two numbers impossible to read together, which is the whole reason to have both.
- Users who reached it
Users who never activate have no time to measure, so they are excluded by construction. That exclusion is the metric's dangerous edge, and the reason the activation rate has to be published next to it.
Never quote this number alone. Time to value computed only on activators improves when your slowest users give up — the metric gets better precisely because the product got worse, and nothing inside the figure shows it.
Worked example
The quarter the number improved by getting worse
- 1,000 sign-ups. 340 activate: 200 within the first hour, 80 within a week (about 3.5 days each), 60 spread over the following two months (about six weeks each).
- Mean time to value: (200 × 0.5h + 80 × 84h + 60 × 1,000h) ÷ 340 ≈ 197 hours, about 8 days. Median: the 170th and 171st values, both inside the first hour.
- Two numbers, same data, and they describe different companies. The mean describes the 60 stragglers; the median describes what a typical activating user actually lives through.
- Next quarter, nothing is fixed and the 60 stragglers simply stop bothering. Activation falls from 34% to 28%. Mean time to value: (200 × 0.5 + 80 × 84) ÷ 280 ≈ 24 hours — an eightfold "improvement", reported the same week the product lost sixty activations.
The median would have barely moved, because the median never depended on the stragglers. Using it, and printing the activation rate beside it, is what makes this number safe to steer by — a rule that costs nothing and prevents exactly one very expensive kind of report.
Orders of magnitude
- The ambition usually quoted for self-serve products is first value inside the first session, on the theory that a user who leaves without getting anything rarely comes back for a second try. It is an ambition, not a measured norm, and it does not transfer to products that need a data migration or an integration.
- Where setup genuinely takes days, the number to watch is the trend on your own cohorts, not the absolute. A tool that went from nine days to four has done something real; a tool at four days is neither good nor bad until you know where it started.
- In B2B the largest component is usually not work but waiting — on credentials, on a colleague, on an approval. That share is worth measuring separately, because it responds to completely different fixes than the interface does.
How to improve it
- Use the median, and publish the activation rate immediately next to it. Two numbers, always together, or the pair can be gamed by attrition alone.
- Measure it per step, not end to end. The total tells you there is a delay; the steps tell you whether it is your form or someone else's calendar.
- Remove waits before removing clicks. Three screens cost a minute; waiting on a colleague for database credentials costs three days, and no amount of interface polish touches it.
- Let value land before setup finishes — sample data, a prefilled example, a result computed on a partial import. The point is that the user sees what the product does before they have finished paying the price of admission.
In the Tour
Has your onboarding been tested or iterated on at least once?
- Yes, iterated based on real data20 pts
- Tweaked a little, informally7 pts
- Never touched since launch0 pts
The Tour asks whether your onboarding has been tested or iterated on at least once — 20 points for yes, 7 for "a bit", 0 for never touched. Time to value is how you would know whether an iteration worked: without it, "we improved onboarding" is a statement about effort rather than about outcome. Teams answering 7 have usually changed something and have no before-and-after, which is the cheapest gap on this list to close — the timestamps needed are already in the database.
Questions people ask
Median or mean?
Median, for two reasons. It resists the long tail of users who activate weeks later, and it stays stable when that tail changes size — which the worked example above shows is the difference between a metric you can steer by and one that rewards attrition.
What if most users never activate?
Then time to value is the second problem and the activation rate is the first. A fast median over a small share of users describes a good experience that almost nobody has. Fix the share, then the speed.
Is it the same as onboarding length?
No, and the gap between them is often the finding. Onboarding length is how long your flow takes; time to value is how long the user waits for something worth having. A four-step onboarding finished in two minutes still has a six-day time to value if value only arrives once a colleague approves an integration.
Does a shorter time to value always mean a better product?
No — it can also mean the goalposts moved. Redefine the activation event as something shallower and the number drops overnight without a single user being better served. Freeze the event, publish the activation rate beside it, and the improvement is real or it is visible.