Time to value in SaaS: how to measure it and how to cut it

In short: Time to value is the elapsed time between a customer starting with your product and the first moment it does something useful for them. Measure it as a median, per account, and split it into two clocks: time to first value, which your product controls, and time to full value, which depends on the customer's own business. For an app installed from an app store, first value should land in the first session, and the fastest way to get there is to use the store's own data before asking the merchant to configure anything.

What is time to value?

Time to value, or TTV, is a stopwatch. It starts when the merchant installs or signs up and stops when they get the thing they came for. The whole metric rests on what you decide "the thing they came for" means, so I split it into two events and run two stopwatches.

Time to first value ends at the first visible result the product produces on the merchant's own store. The referral link is live. The first review request went out to real customers. The first creator received a message. The product has done something.

Time to full value ends at the outcome the merchant is paying for. The first order came in through an affiliate. The first review is showing on a product page. The first creator posted a video that sold something.

App type	First value	Full value
Affiliate or referral app	Signup page live, first link generated	First referred order tracked
Review app	First review request sent	First review published on a product page
Creator outreach for TikTok Shop	First outreach message delivered	First creator video live with the product
Email or SMS app	First campaign sent	First order attributed to a campaign
Upsell or bundle app	First offer live on the storefront	First order containing the offer

The split matters because the two clocks have different owners. First value is almost entirely a product design problem, and you can cut it in a sprint. Full value depends on the merchant's customers, creators, and traffic, and the product's job there is to make the waiting visible and useful.

Shopify's own onboarding guidance says the same thing without naming the metric: "A great onboarding experience presents the basics of your app to merchants as quickly as possible."

Why does time to value matter more for an app than for other SaaS?

A merchant evaluating a Shopify app is not evaluating it in isolation. They often have two or three competing apps installed at once, a trial clock running on each, and a monthly bill that starts when the trial ends. Uninstalling is one click. There is no procurement cycle to slow the decision down.

So the app that shows a result first usually wins, and the one that asks for a configuration session first usually loses, even if it is the better product on week four. I spent close to two years in customer success before I moved into design, and I read the tickets a slow first week creates. A merchant who installed three days ago and has seen nothing is not asking how to go further. They are asking whether to keep going.

Time to value is also the metric that connects onboarding to money. If your trial is 14 days and the median time to full value is 20, your trial conversion rate is being decided by the calendar, not by the product.

What is a good time to value?

The only public benchmark with a stated sample that I could verify is Userpilot's 2025 benchmark report, which lists an average time to value of "1 day, 12 hours, 23 min" across 62 B2B SaaS companies, drawn from Userpilot's own customers. The same page shows a second average of about a day and two hours without a sample attached, and the longest industry figure is HR at just under four days. Treat the whole thing as a rough signal. Every company in that sample defined its own value event, so the number averages across different stopwatches.

What I would say with more confidence, as an opinion from having shipped this work rather than a benchmark: for an app installed from an app store, time to first value should be measured in minutes and should land inside the first session. Time to full value should land inside the trial. If either does not, you have a specific design problem to find, and the funnel will show you where.

How do you measure time to value in product analytics?

I use PostHog for this, and the setup is the same in most product analytics tools.

1. Send the install as an event from your webhook handler, with the store as the identity. Send the first-value and full-value events from the server, not the browser. A referred order is a server-side fact, and a browser event will miss it when the merchant is not logged in.
2. Aggregate by store, not by user. One store may have three staff accounts. PostHog's group analytics "aggregates events by entities like organizations or companies instead of individual users," and a funnel can be set to aggregate by that group type.
3. Build two funnels: install to first value, and install to full value. Switch the funnel to the time-to-convert view. PostHog's docs put the use of it plainly: "Steps with a long time to convert are likely much harder than steps with a short time." That view turns a vague "onboarding is slow" into a specific step with a specific number of hours attached.
4. Report the median and the 75th or 90th percentile, never the mean. One store that took 40 days will move an average and hide the fact that most stores took an hour.
5. Break the funnel down by plan, by store size at install, and by acquisition source. A store with 5,000 orders a month and a store with 50 should not be in the same line.
6. Cohort by install week, and hide cohorts whose window has not fully elapsed. Otherwise the most recent week always looks worse than it is.

Then put the install-to-first-value funnel on a dashboard the whole team sees. Time to value is one of the few metrics that a designer, an engineer, and a customer success manager can all move in the same week, and it is more useful on a shared screen than in a quarterly review.

What cuts time to value for an app installed from an app store?

In rough order of how much they move the median, from what I have seen shipping this work:

Use the store's data before asking for anything. The moment OAuth completes you can read orders, products, and customers. An affiliate app can find the repeat customers who are the obvious first affiliates. A review app can list the products with no reviews. Show the merchant what the app found, on the first screen, and the stopwatch for first value is already most of the way to stopping. The guide on Shopify app onboarding walks through that first screen stage by stage.

Default every setting that can be defaulted. Commission rate, cookie window, email copy, widget colour. Each field is a place to stop and think, and some merchants stop there for good. Ship working defaults and let them edit later.

Reduce setup to the one step that produces the first result. Not a wizard with five screens. One action, one button, one result.

Do the installation work for them. If the app needs something on the storefront, use a theme app extension and switch it on from inside your app rather than sending the merchant into the theme editor with instructions. Every handoff to another part of the admin adds hours to the median.

Ship templates, not builders. The first email, the first creator message, the first offer should exist already. The merchant turns it on, sees it work, and then rewrites it.

Make the wait for full value visible. When full value depends on affiliates joining or creators replying, show the merchant the pipeline: three affiliates signed up, two links clicked, no orders yet. A screen that shows movement keeps a merchant through the gap. A screen that shows a zero does not. That screen is an empty state problem, and the guide on empty state design covers what to put there.

Intervene on the stalls, at the right time. Use the median time to first value as a trigger. If a store is past the median and has not hit the event, send one specific message naming the step that is missing, and route high-volume stores to a person. Sending it on day seven for everyone is too late for most and too early for none.

One warning. It is possible to cut time to first value by choosing an easier event. If the median drops and activation and retention do not follow, you have moved the finish line rather than the merchant. The guide on SaaS activation rate covers how to check the event against retention.

Where to start

1. Write down the first-value event and the full-value event for your app in one sentence each. If either sentence describes a settings screen, pick again.
2. Instrument both from the server, keyed on the store, and send the install event from the webhook.
3. Build the two funnels, switch to time-to-convert, and read the median and 90th percentile for last month's installs.
4. Find the step with the longest time to convert and remove, default, or automate it.
5. Set a stall trigger at the median time to first value and write the one message that goes out when a store crosses it.