Activation is not signup: pick the event that predicts retention

Every product dashboard shows signups, because signups are the number that is always available. They are also the number that cannot tell you whether anything worked: someone who signed up, saw an empty screen, and never came back counts exactly as much as someone who is still using the product six months later.

Activation is the narrower question — what happened in the first session that makes a second session likely? — and it is worth one afternoon of work, because it is the only number that tells you whether your onboarding is doing its job.

Start from the users who stayed

Take the accounts that are still active today, and look backwards at their first session. What did they do that the accounts which churned did not? Not what they clicked — what they finished. The candidate is usually an action that produces something the user can show: a project created, a first record imported, a document shared, an integration returning data.

You are looking for a behaviour with three properties:

• It is in the user's control. "Was invited by an admin" is a segment, not an activation event.
• It can happen in the first session. If it needs a week of data, it explains renewal, not activation.
• It is observable. If it means "understood the product", it is a feeling; pick the action that implies it.

Then check it against the users who left

An activation event earns its name only if it separates the two groups. Count, among the accounts that churned in the last quarter, how many had reached it in their first session. If a healthy share of the churned users reached it too, the event is a milestone, not a predictor — go back a step and find an earlier one.

Do this with your own data, not with a benchmark: the number is only useful as a ratio inside one product. Cohort tables in your own warehouse (or an event list filtered by signup date) are enough; a spreadsheet of a few hundred accounts answers the question before any tooling is involved.

Make it the single number onboarding is judged on

Once the event exists, derive the metric from it: the share of new accounts that reach it within their first session, and within their first week. One number, one definition, written down. "Activated" now means something a support reply, a checklist edit and a pricing page can all be measured against.

The three usual mistakes

• Choosing two events. A dashboard with two activation numbers has none: the first time they disagree, the meeting discusses which one is right instead of what to change.
• Redefining it quietly. Changing the definition when a number disappoints makes every historical comparison meaningless. Version the definition and note the date it changed.
• Reporting it as a total. "1,240 activated" says nothing. The reported form is a rate over a cohort: of the accounts created that week, how many activated.

Point the onboarding at that event

An activation event turns onboarding from a description into a measurement. If the event is "first project created and at least one step of it completed", then a checklist whose steps end exactly there is aligned with the metric by construction — and a guided product tour that shows the settings screen is not, no matter how well it is built.

That is the argument for a checklist over a tour, and it is a measurement argument, not a design preference: a tour proves the interface was seen. A checklist proves which specific steps were done, per user, in which order — the raw material for the activation number itself.

Getting Started keeps progress per end user and reports the completion funnel per step, plus the number of users who finished the list. So the checklist's last step can be mapped to the activation event, and the funnel's shape is the first thing to look at when the activation rate moves:

// a backend that creates the project for the user completes the step server-side
POST /api/gs/v1/server/complete
{ "userId": "u_1829", "stepKey": "first_project" }

Two rules keep that honest. Complete a step only from an event your own product actually emitted — not from a timer, not from the widget's own animation. And write the activation definition where the team reads it, not in the dashboard query that happens to implement it.

Configure a draft list in the console and watch the funnel fill as you complete steps yourself: open the console. If you are still designing the list, start with the design rules; the reference for the server-to-server calls is in the docs.