How to define activation and measure time to first value
Choose a meaningful activation event, define the measurement window, and use a worked example to track completion and time to first value together.
In this article
Activation is an early, observable sign that a customer has reached a useful product outcome. Time to first value measures the wait from a defined starting point to that outcome. Choose the event, eligible audience, and observation window together, then report both the share who reach value and how long successful customers take. The worked example below turns those choices into a measurement definition.
A customer connects a data source, names a workspace, and dismisses the welcome tour. Every box is ticked. Then the first report loads with nothing in it.
Has that customer activated? If your definition is “completed onboarding,” yes. If the customer came to find out which projects are over budget, they are still waiting.
That gap matters because the event you call activation becomes a design target. Count setup completion and you will optimize setup. Count a useful result and you have a reason to fix everything between the welcome screen and that result, including missing data, confusing output, and permissions.
Finish the customer’s sentence
“The user created a project” describes product activity. “The user can now see which jobs need attention” describes a benefit. Before opening an analytics tool, complete this sentence: “A new customer gets their first useful result when they can…”
For an invoicing tool, that might be sending a valid invoice to a real customer. For a scheduling tool, it could be a booking appearing in the right calendar. An editor may deliver value before any account exists, when someone makes an edit they want to keep. These are candidate definitions, not rules for every product in those categories.
Amplitude’s activation chapter distinguishes discovering value from the later exchange that benefits the business. That distinction is useful: seeing what a product can do, using it for a real task, and paying for it need not happen together.
Avoid forcing all three into one milestone. A preview may convince someone to continue without proving that their own work is ready. A payment proves a purchase, but the person may still be unable to use what they bought.
When the useful outcome is difficult to observe, work backward from it. You cannot reliably instrument “understood the report.” You can record whether a valid report was opened, whether the customer changed a meaningful filter, or whether they saved a view. Watch people perform the task and ask what they learned. That helps you judge which event is a reasonable signal and which is just an easy button to count.
Make the definition hard to satisfy accidentally
Consider an illustrative reporting product. Its first candidate activation event is report_created. A template creates a report automatically at signup, so every new account qualifies. The metric tells you almost nothing.
A more useful candidate might be: the account owner opens a report containing successfully imported customer data within seven days of starting setup. That definition has a subject, an action, a quality condition, and a deadline. It can still be wrong. Perhaps owners open reports only to discover that the import is incomplete. But now the team can inspect the cases and improve the definition.
Keep the qualifications that defend the meaning. Exclude internal test accounts and sample-only reports. Decide whether an implementation specialist opening the report counts, or whether an end customer must do it. Record the account and person separately when both matter.
Do not keep adding conditions until activation means “a successful long-term customer.” Requiring months of use would make the metric too late to diagnose onboarding. You need an early signal with enough substance to be useful.
Put a start on the clock
Time to first value is elapsed time between a chosen start and the first qualifying result. The arithmetic is simple. The start is contentious.
Signup is convenient, but it may occur well before someone intends to begin. First session excludes the delay between registration and arrival. Starting the clock after a data import hides the import wait entirely. None of these choices is neutral.
Choose a customer-facing clock and keep it stable. If you also need a diagnostic clock, name it separately. In the reporting example, signup-to-first-report describes the whole wait. Import-start-to-first-report helps isolate processing and review. Both can be useful on the same dashboard.
Assisted setup needs the same care. If a specialist prepares an account for a week before the customer logs in, “two minutes to value” from first login describes only the final stage. Report preparation time separately instead of letting it disappear.
The fastest users can make a slow product look good
Suppose 100 eligible new accounts enter an illustrative cohort. Twenty reach value in ten minutes; the other 80 have not reached it after a week. A median of ten minutes among successful accounts is accurate and deeply incomplete.
Now suppose an improvement helps another 30 accounts reach value, though they take two days. The median among successful accounts can get slower while the product helps more customers. Treating speed alone as the score would punish that improvement.
Pair the time distribution with the share that reaches the milestone within the observation window. Show the median and a slower percentile among those who reach it, clearly labeled. Keep the people who never reach it visible in the completion rate. Give new cohorts enough time to mature before comparing them with older ones.
Also split journeys when the work differs. A workspace creator, an invited reviewer, and an account prepared by a specialist face different tasks. One blended number can move because the mix changed, even if every journey stayed the same.
Check whether the milestone deserves its name
Compare later useful behavior for people who reached your candidate milestone and those who did not, using comparable cohorts and a fixed early activation window. Measure return behavior after that window. Otherwise, people classified as activated may simply have had more time to qualify and return.
Amplitude’s retention analysis documentation makes the starting event, return event, and included users explicit. Use that flexibility deliberately. A return login is a weaker test than another completed customer task when the latter is observable.
A retention difference supports further investigation; it does not prove that pushing people through the event causes retention. Motivated customers may both activate and stay. Combine the analysis with observation, and test changes that plausibly help customers reach the underlying outcome.
Return to the empty report. The useful intervention might be a better import, a clearer explanation of missing data, or a report that answers a narrower question immediately. A shorter welcome tour would miss all three. A defensible activation definition directs attention to the work the customer is still waiting for.
A worked definition of activation and time to first value
Write the definition before building the report. The completed example below uses the reporting product from this guide; its events and numbers are illustrative. Change the definition to match the outcome your own customer needs.
| Decision | Worked reporting-product definition |
|---|---|
| Customer outcome | The account owner can inspect which projects are over budget using their own imported project data. |
| Observable signal | The owner opens a report after that account’s real-data import succeeds. Sample-only reports and reports without usable data do not qualify. |
| Unit counted | One newly created customer account. Count its first qualifying result once, even if the owner opens several reports. |
| Eligible population | New accounts created through the self-serve signup route. Exclude internal and test accounts; evaluate invited users and assisted implementations separately. |
| Clock start | The timestamp when signup creates the account. Keep the import wait in this customer-facing clock. |
| Clock finish | The timestamp of the first qualifying report opening by the account owner. |
| Observation window | The first 168 hours after each eligible account’s signup. Compare cohorts only after every included account has had that full window. |
| Activation rate | Eligible accounts with a qualifying result during the window, divided by all eligible accounts in the mature cohort. |
| Time to first value | Finish timestamp minus start timestamp for each qualifying account. Label summaries as applying to accounts that activated within seven days. |
| Meaning check | Observe customers using the report and check whether they can identify a real project that needs attention. An opened report remains a proxy for that outcome. |
This worked version starts at signup. If your team chooses a different start, change both the definition and its label before comparing results. An additional import-processing clock can help diagnose delays, but should remain separately named.
Work through one cohort
Suppose five eligible accounts have each completed their seven-day observation window. The synthetic record is:
| Account | First qualifying result after signup | Activated within seven days? |
|---|---|---|
| A | 30 minutes | Yes |
| B | 3 hours | Yes |
| C | 8 hours | Yes |
| D | 48 hours | Yes |
| E | No qualifying result during the window | No |
The seven-day activation rate is 4 ÷ 5 = 80%. Among those four activated accounts, the ordered times are 0.5, 3, 8, and 48 hours, giving a median of (3 + 8) ÷ 2 = 5.5 hours. Report the two results together: four of five accounts reached the milestone, and the median wait among those four was 5.5 hours. The fifth account remains visible in the activation rate. This tiny invented cohort explains the calculation; it is not a benchmark.
Copy these questions into your measurement brief
- Outcome: What can the customer now do, understand, or obtain?
- Signal: Which recorded event represents that result, and what conditions make it meaningful?
- Population: Are you counting people or accounts? Who is eligible, and which exclusions will you apply consistently?
- Clock: What starts the wait, what ends it, and how long will you observe each new entrant?
- Missing results: How will you distinguish unfinished work from missing or faulty measurement?
- Report: Which completion rate and time distribution will you show together, with their denominators and windows?
- Review: Who will inspect example journeys, check the event’s meaning with customers, and decide when the definition needs revision?
Before using the result, follow a successful account and an unfinished account through the underlying records. Check that staff activity, sample data, duplicate events, and missing timestamps behave as the brief says. Investigate missing measurement instead of quietly removing those accounts from the denominator. For teams with several arrival routes, use the invited-user and assisted-account guide to keep shared preparation separate from a person’s first result.
When you apply that definition to real event data, separate internal tests from customer activation so QA activity does not stand in for a useful customer outcome.
