The user opened an account, finished the welcome tour and reached the dashboard. Even so, they may still not know how the product is going to help them. In an onboarding flow, completing the screens and understanding the product's value are not the same outcome.
SaaS onboarding is the process that prepares a user for the task where they can experience the product's core benefit. That benefit might be a report being generated, a booking being taken, a task being assigned to a teammate, or a real data connection working. You have to define that moment first, then design the steps that support it.
The work management product and the figures used in this article are examples. The event names are a suggested measurement dictionary; they are not a universal standard or an achieved customer result.
Choose an observable behaviour for “first value”
In a work management product, a user who has only created an empty project may not yet have made their team's work any easier. An example first-value definition could read: “A real task was created in the new workspace and assigned to another team member who had accepted their invitation.”
That definition does not have to be perfect; it is a verifiable starting hypothesis. Use user interviews to check whether task assignment really does represent the benefit. Then examine whether the accounts that perform this behaviour come back to the product.
Do not confuse the user unit with the account unit
In a team product, the person who signs up and the organisation that experiences the value are different units. An administrator may set things up while an employee completes the task. A measurement that expects a single user to perform every step can wrongly count successful teams as failures.
To begin with, you can keep activation reporting at account level and step completion at user level, separately. Write into the metric definition which unit is used and why.
Reduce what is required before reaching value
As you build the flow, ask of every field: “Can the user perform the first core task without this information?” If they can, consider deferring the field. A company logo, detailed billing information or configuring every team role may not be needed before the first task.
Keep the steps genuinely required for security and access. But explain the reason for each requirement clearly. If a data connection is being set up, make visible which data will be read, how long the operation might take and what happens if it fails.
The example flow can be simplified like this: open the workspace, choose the first job, invite the person you need, create the first task, see the result. That order changes with what the product does; rather than applying the same guide to every SaaS product, work backwards from your own value moment.
Sample data must be separated from real success
Showing a sample project instead of an empty screen can make the product easier to grasp. But do not count completing a task in the sample project as real customer activation. Keep a field marking records as sample data and separate them in reporting.
On first use, give the user a way to delete the sample data or continue with their own. Trial data finding its way into operational reports months later creates a different kind of trust problem inside the product.
Write the event dictionary independently of the screen flow
An event needs a name, a trigger condition, identifiers, required properties and a recording time. Segment's Track structure offers one example framework for recording behaviour with an event name and properties. The dictionary below is an original suggestion you can adapt for your product. Twilio Segment: Track.
- account_created: When the workspace is successfully created on the server, once per account.
- member_joined: When an invited person accepts the invitation and is connected to the account.
- task_created: When a task is persisted; with account and task identifiers.
- task_assigned: When the assignment completes successfully, with the assignee's account membership verified.
- first_value_reached: When the defined first-value conditions are met, as a single activation record per account.
Do not confuse clicking a button on screen with a successful persisted record. Failed requests produce clicks too. Deriving the business event that activation depends on from a server-confirmed result is a more reliable starting point.
For every event, consider fields such as event_id, account_id, occurred_at and schema_version. Deduplicate resent events by event_id. Decide which date late-arriving records enter reporting under, and how time zones are handled.
Calculate activation rate with an explicit window
Before saying “our activation went up”, write down the denominator and the period. An example definition: the share of eligible accounts created in a given week that reached first value within their first seven days. The rule for excluding trial accounts and internal team accounts should be set from the start.
In an entirely hypothetical calculation, if 35 of 100 eligible accounts meet the condition, activation is 35 per cent. That figure is not an industry benchmark or a WebWizz performance claim; it shows how the definition is computed.
If newly opened accounts have not yet completed seven days, do not compare them in the same results table as accounts with a completed window. Otherwise the most recent week's performance will look low purely because the observation period was short.
Do not read time to value on its own
Time to value is the difference between the starting event and the first-value event. You can track the median alongside the upper percentiles that represent slower users.
However, the time for activated accounts can shorten while the number of accounts that never activate grows. For that reason, read the duration together with the activation rate. Only together do they show whether a faster flow is helping more users.
Compare measurement data against product behaviour
Do not treat the analytics chart as the single source of truth. For one sample account, match the event stream against the actual application records. The account identifier may have changed, an event may have been sent twice, or trial data may have been counted as real.
Google Analytics' recommended sign_up event describes registration; it does not define the value moment in your product by itself. You have to design the relevant business event separately. Google Analytics: recommended events.
Take care not to pass free text, customer names or email addresses into analytics tools. For information that identifies a person and must not be sent to Google Analytics in particular, check the product's official rules. Google Analytics: personally identifiable information.
Onboarding implementation checklist
- Write the first-value behaviour in one testable sentence.
- State whether measurement is at account or user level.
- Defer fields that are not required for the first task.
- Distinguish sample data and internal team usage.
- Give events explicit trigger conditions and a version.
- Test duplicate events and identity merges.
- Fix the activation window and its denominator.
- Review duration, activation and continued usage together.
If you would like to work on your SaaS product's onboarding flow with WebWizz, you can share your first-value definition and your current screens through our contact page. That way design decisions can be tied to measurable product behaviour.
Frequently asked questions
Does completing the onboarding tour count as activation?
Only if it genuinely represents the product's benefit. In most cases, finishing the tour is an indicator of readiness. The behaviour showing that the user can perform the core task has to be tracked separately.
Should first value happen on day one for every SaaS?
No. Data migration, team approval or long-running workflows may require different windows. Set the period according to the nature of the product and document why you chose it.
Does churn automatically fall when activation rises?
There is no such guarantee. Examine the relationship between the first behaviour and continued usage in later cohorts. A poorly chosen activation definition may only be measuring an easily completed step.
Should we start measurement with a large number of events?
Start with reliable events for the core flow. If an event has no decision attached to it, the maintenance burden grows. More detailed measurement can be added to answer a specific user question.