Tracking Activation: A Simple Event Plan for Onboarding

Most teams send a welcome email, build a product tour, and then argue about whether either worked. Without data, the argument is about taste. With a small, well-planned set of events, it becomes a question you can answer: of the people who signed up this week, how many reached the first moment of real value, and where did the others stop?

This post walks through defining activation, choosing which events to track, naming them, and connecting emails and in-app flows to what users actually do. The example product is imaginary: a project management tool called "Taskly", used only to illustrate the method.

Step 1: Define activation in one sentence

Activation is the point where a new user first gets the value your product promises. It is not signing up, and it is not opening the app. It is an action that shows the product did its job.

To find yours, finish this sentence: "A user is activated when they have [done a specific thing] within [a time window]."

For Taskly, it might be: "A user is activated when they have created a project and completed one task within their first 7 days." For a payments app it might be a first successful transfer. For a design tool, a first exported file.

How to choose the action:

1. Ask what your retained users did early. Compare users who stayed with those who left, and look for an action most of the stayers took. Treat this as a hypothesis, since correlation does not prove cause.
2. Prefer an action over a view. "Viewed dashboard" is weak. "Invited a teammate" or "completed a task" shows commitment.
3. Keep it reachable. If only a small share of users could ever complete it in the time window, the definition is too hard to learn from.
4. Write it down and share it. Marketing, product and engineering should use the same definition.

Step 2: Map the path to activation

List the steps a user must take from arrival to activation. For Taskly:

1. Visits the landing page
2. Starts sign-up
3. Completes sign-up
4. Verifies email
5. Creates the first project
6. Adds the first task
7. Completes the first task (activation)

Each step is a place where people can drop out. Your event plan should let you see each one. Draw this as a funnel on a whiteboard before opening any analytics tool.

Step 3: Pick the events worth instrumenting

The temptation is to track every click. That produces thousands of events nobody reads and a bill for storing them. Start with 10 to 15 events that cover the funnel, plus a few that explain failures.

Group them in three layers.

Funnel events: one for each step above. For example signup_started, signup_completed, email_verified, project_created, task_created, task_completed.

Onboarding events: how users interact with the guidance you built. For example onboarding_checklist_viewed, onboarding_step_completed, onboarding_skipped, product_tour_dismissed.

Friction events: signals that something went wrong. For example signup_error_shown (with an error type), email_verification_resent, form_validation_failed.

A good test for any event: "If this number changed, what would we do?" If you cannot answer, do not track it yet.

Step 4: Name events consistently

Naming drift is the most common reason analytics become unusable after six months. Choose a convention and write it down.

• Format: object_action in snake case, past tense. project_created, not CreateProject or new project.
• One name per behaviour. Do not have both task_done and task_completed.
• Keep names stable. Renaming breaks historical charts. If a name must change, record the date and the old name.
• Put detail in properties, not in the name. Use signup_completed with a method property of email or google, not two separate events.

Properties worth sending

Attach a few properties to every event, and a few to specific ones.

Always:

• user_id (the account identifier from your system, not an email address)
• timestamp
• platform (web, iOS, Android)
• app_version

Where relevant:

• signup_completed: method, referrer_source
• project_created: template_used (true or false), is_first_project
• onboarding_step_completed: step_name, step_number
• signup_error_shown: error_type

Keep names, emails and phone numbers out of event properties, and check the privacy and consent rules that apply to your users.

Step 5: Write the event plan

An event plan is a table shared by product, design, engineering and marketing. Here is a starter for Taskly:

Event	Trigger	Key properties	Used for	Owner
signup_started	User opens the sign-up form	referrer_source	Top of funnel	Growth
signup_completed	Account created on server	method	Funnel step 3	Backend
email_verified	Verification link clicked	hours_since_signup	Funnel step 4, email timing	Backend
project_created	First project saved	template_used, is_first_project	Funnel step 5	Frontend
task_created	Task saved	is_first_task	Funnel step 6	Frontend
task_completed	Task marked done	is_first_task_completed	Activation	Frontend
onboarding_checklist_viewed	Checklist shown	step_count_remaining	Onboarding reach	Frontend
onboarding_skipped	User dismisses guidance	step_number	Onboarding friction	Frontend
signup_error_shown	Error displayed	error_type	Friction	Frontend

A few practical points:

• Send critical events from the server. Browser-side tracking is blocked by some extensions and lost when a tab closes. signup_completed and task_completed should be recorded where the data is saved.
• Add the plan to your definition of done. A feature is not finished until its events are in the plan, built and checked.
• Test before release. Open the live-event view of your analytics tool, perform the action, and confirm the event arrives with the right properties.

Step 6: Connect emails to behaviour

Onboarding emails are often sent on a timer: day 1, day 3, day 7. A timer ignores what the person did. Triggering on behaviour is more useful and easier to measure.

A basic set of triggered messages for Taskly:

• Welcome, sent on signup_completed. One clear action: verify your email or create your first project.
• Nudge, sent 24 hours after email_verified if no project_created exists. One line of help and a link straight to the project form.
• Stalled, sent 3 days after project_created if no task_completed. Offer a short example project or a reply-to address for questions.
• Celebrate and extend, sent on task_completed (first). Suggest inviting a teammate.

Rules that keep them useful:

1. Stop a sequence the moment the user performs the action it asks for.
2. Send each email once, and cap total onboarding messages.
3. Include a clear unsubscribe and follow the email regulations that apply to your audience.
4. Tag each link, with UTM parameters or an event on click, so you can tell which email led to action.

Step 7: Read the results without fooling yourself

Once you have a few weeks of data, look at:

• Funnel conversion at each step. The biggest drop is your first target.
• Time to activate. Median hours from signup_completed to task_completed. A shorter time usually means a clearer path.
• Activation by source. People from different channels often behave differently.
• Email impact. Compare activation among those who received a nudge and those who did not. If you did not hold anyone back, you cannot separate the nudge from users who would have acted anyway. For a real test, hold out a small random group.

FAQ

Which analytics tool should we use?

The plan matters more than the tool. Choose any product analytics tool that supports event properties, funnels and user-level views, and fits your privacy requirements. Keep the plan in a document, so switching tools later is a matter of re-pointing the same events.

How many events are too many?

If nobody can name what decision each event supports, you have too many. Starting with 10 to 15 and adding as questions appear works well.

Talk to us

If you want help defining activation, planning events, or redesigning onboarding around what the data shows, talk to our team. Email hello@risingstation.com or visit risingstation.com/contact-us.