Analytics · 9 min read · 2026-10-14
Median Time-to-Value Lies: Track p75 and p90 Too
Your median time-to-value can hold steady at two days for a full quarter while your onboarding quietly falls apart. The median is the 50th percentile — it describes the typical user and is, by design, blind to everyone slower than typical. Time-to-value is a right-skewed duration: most activated users reach value quickly, a long tail takes days or weeks, and the tail is exactly where churn risk lives. A statistic built to ignore the tail is the wrong headline number for a metric whose tail is the whole point.
This is a metric deep-dive on why a single central-tendency number misleads for skewed SaaS metrics, and what to report instead. The fix is not exotic: track the median, p75, and p90 together and watch the gap between them. As one plain-language treatment of the problem puts it, "use the median when your data are skewed or contain outliers — income, wealth, insurance claims, web session durations" (Metricgate) — but for time-to-value even the median is only half the story.
Why time-to-value is always right-skewed
Time-to-value has a hard floor and no ceiling. A user cannot activate in less than zero time, but they can take an arbitrarily long time — or never activate at all. That asymmetry forces a right skew: the bulk of the distribution bunches up near the fast end, and a thinning tail stretches out to the right. This is the same shape as reaction times, request latencies, and session durations, all of which the statistics literature treats as textbook skewed distributions where the mean and median behave very differently (Rousselet & Wilcox).
The practical consequence is that the mean sits well above the median and describes no real user, while the median describes the typical user and ignores the slow one. Neither number, alone, tells you whether your onboarding is getting better or worse for the people most likely to leave. The skew is not a flaw in your data to be cleaned away — it is the true shape of how humans adopt software, and your reporting has to respect it rather than flatten it into one convenient figure. This is the distribution-shape version of the same mistake behind an unlabeled rate metric denominator: the summary hides the decision.
The median-flat, p90-rising trap
The failure mode to fear is a median that stays flat while p90 climbs. It means the fast half of your users is unchanged — or even improving — while the slowest tenth is getting slower. On a median-only dashboard this reads as "TTV stable, nothing to do." In reality you are speeding up the users who were never at risk and losing ground with the ones who churn before first value. The median cannot see this because the median does not move when you change values above it: you can push the slowest user's time to infinity and the median does not budge.
Watching p75 and p90 alongside the median turns this invisible drift into a visible line on the chart. A healthy onboarding improvement pulls all three percentiles down together. A dangerous one widens the gap between p50 and p90, and that widening gap is itself the alert — you do not need a threshold, you need to notice divergence. Teams that only report one number also tend to celebrate the wrong wins: a tweak that shaves a few minutes off already-fast users moves the median and looks like progress, while the tail — the users whose activation speed actually predicts retention — is untouched.
Worked example: two cohorts, identical median
Take two signup cohorts that both report a median TTV of 2 days. Cohort A has p75 at 3 days and p90 at 4 days — a tight distribution where even the slow users get there within a workweek. Cohort B has the same 2-day median but p75 at 6 days and p90 at 19 days — the typical user is identical, but the slow tail has blown out. If you reported only the median, these two cohorts look like the same onboarding experience. They are not: Cohort B has a large population stuck in a multi-week limbo, and those users will churn at a far higher rate before they ever reach value.
The percentile set makes the difference legible in three numbers. It also points at the fix: Cohort B's problem is concentrated in a specific slow segment, so the next move is to isolate who those users are — which acquisition source, plan tier, or setup path they share — rather than broadly "improve onboarding." The same logic that governs the choice of activation event applies here: the distribution around the metric is as informative as the metric itself, and a p90 that diverges from the median is a map to the at-risk cohort.
Censoring: the number that makes you look faster than you are
Percentiles of time-to-value are computed only over users who actually reached value, which means they silently exclude everyone still waiting. A user who signed up yesterday and has not activated has an unknown, open-ended TTV — statisticians call this right-censoring — and dropping them from the calculation makes your percentiles look faster than reality. A cohort where only 40% have activated can post a flattering 2-day median that describes a minority while the majority sits in the uncounted tail.
The discipline is to never report TTV percentiles without the activation rate beside them: "median 2 days, p90 11 days, among the 62% who activated within 14 days." The window matters as much as the percentile, because a fixed window is the only way two cohorts are measured on the same clock — recent signups have simply had less time to activate. This is the same cohort-comparability discipline that day-of-week and seasonality effects demand: if the measurement windows differ, the comparison is an artifact. For young products, small activated-user counts also make high percentiles jumpy, the same small-sample instability that plagues early-stage retention.
What to put on the dashboard
Replace the single TTV number with a compact panel: median, p75, p90, and the activation rate for the cohort, all over a fixed window. Chart the three percentiles as separate lines over time so divergence is visible at a glance — when the p90 line pulls away from the median line, you have a tail problem even if the median is flat. Keep the mean off the dashboard entirely, or relegate it to a single diagnostic: a large mean-minus-median gap just confirms the skew you already know is there.
The payoff is that you stop optimising for the users who were never going to churn and start seeing the ones who will. A percentile set costs nothing beyond a slightly wider query, and it converts time-to-value from a vanity number that always looks fine into a diagnostic that tells you when, and for whom, onboarding is breaking. The rule is simple: for any right-skewed metric — TTV, session length, time-to-first-key-action — report a percentile set and the base it was computed over, never a lone central number.
Frequently asked questions
The questions below define time-to-value, explain why a median alone misleads, recommend which percentiles to track, cover when the mean is appropriate, and describe how to compute TTV percentiles without the censoring and cohort-mixing errors that make a product look faster than it is.
FAQ
What is time-to-value (TTV) in SaaS?
Time-to-value is the elapsed time between a user signing up and reaching the moment they first experience the product's core value — the activation event or aha moment. It is measured per user as a duration (minutes, hours, or days) and then summarised across a cohort. Because it is a duration with a hard floor of zero and no ceiling, TTV is almost always right-skewed: most users who activate do so quickly, but a long tail takes days or weeks, and a minority never activate at all. That shape is why the summary statistic you choose changes the story the metric tells.
Why is median time-to-value misleading on its own?
The median is the 50th percentile, so it describes the typical user but is deliberately blind to the tail. For a right-skewed metric like TTV, the median can stay flat while the slowest quartile of users gets dramatically slower — a real and worsening onboarding problem that a median-only dashboard reports as 'no change.' The median is robust to outliers, which is exactly its weakness here: the tail is not noise to be suppressed, it is the segment of users most at risk of churning before they ever see value. Reporting only the median optimises for the users who were never the problem.
Which percentiles should I track for time-to-value?
Track the median (p50), p75, and p90 together, and watch the gap between them. The median tells you the typical experience, p75 tells you what the slower-than-average quarter endures, and p90 exposes the tail where churn risk concentrates. A healthy trend moves all three down together; a dangerous one holds the median flat while p90 climbs, meaning you are speeding up users who were already fast and abandoning the ones who struggle. Pair each percentile with the share of users who never activate within the window, because percentiles are only computed over users who eventually reached value.
Should I ever use the mean for time-to-value?
Almost never as a headline number. The mean of a right-skewed distribution is dragged upward by the long tail, so it sits above the median and describes no actual user — it is neither the typical experience nor the worst case. A mean TTV can also swing wildly when a single very slow user activates, making trends look like changes when they are artifacts. If you want one number, use the median; if you want the full picture, use a percentile set. The mean is useful mainly as a diagnostic: a large mean-minus-median gap is a quick signal that the distribution is heavily skewed and a single statistic will mislead.
How do I compute percentiles for time-to-value correctly?
Compute TTV per activated user within a fixed cohort and a fixed observation window, then take percentiles across that cohort. Two pitfalls dominate. First, right-censoring: users who have not yet activated have an unknown, open-ended TTV, so excluding them inflates how fast you look — always report the activation rate alongside the percentiles, or use a survival-analysis estimate. Second, cohort mixing: percentiles computed over users with different amounts of elapsed time since signup are not comparable, because recent signups have had less opportunity to activate. Fix the window (for example 'TTV among users who activated within 14 days of signup') so every cohort is measured on the same clock.