- Define the business outcome before naming the event.
- Separate browser intent from server-confirmed completion.
- Test failure, retries, existing-account login, and activation—not only the happy path.
Start with one decision and one outcome
A tracking plan is a shared definition of what your events mean, when they fire, and how you will know they worked. It is not a list of everything a browser can capture. For an early SaaS product, a useful first decision is whether the signup flow helps interested visitors reach the first meaningful product outcome.
Write that outcome in ordinary language. “The account creates its first usable project” is more precise than “engagement.” Choose the evidence that makes it true: a durable project record, an accepted teammate invitation, or a report populated with the customer’s own data. A screen rendering does not always establish that the underlying action succeeded.
Use a small event ladder
For an illustrative project-based SaaS, begin with a visible landing page, signup CTA click, signup start, confirmed account creation, and first project creation. Add a trial-start milestone only if that commitment is part of your actual business flow. This produces a short chain you can investigate without collecting every keystroke.
A magic-link request and an OAuth redirect are starts, not necessarily completed registrations. An existing customer signing in is not a new account. If your application creates an account before email confirmation, record those as separate milestones when the distinction matters. The account-created event must match your documented application definition.
| Event | Evidence | Does not mean |
|---|---|---|
| signup_cta_clicked | A deliberate CTA selection | An account exists |
| account_created | The server confirms a new account | The customer is activated |
| first_project_created | The first durable project is saved | The account has paid |
| trial_started | The configured trial is confirmed | An initial charge was collected |
Assign an owner and a verification step
Browser events are useful for interest and navigation. Completion events should be anchored to the system that knows the outcome happened. Choose one owner for each event so a browser callback and a server handler do not independently count the same completion.
Test at least four cases: a failed attempt, a new successful action, a retry of that action, and an existing-account login. Write the expected count before testing. A durable event identifier can help an implementation deduplicate retries, but only if the collector actually enforces that contract. Seeing a request sent is weaker evidence than finding one accepted record.
Collect properties that answer the decision
Useful planning fields include a safe CTA label, signup method, plan identifier, and a bounded report type. Do not collect passwords, form contents, emails, secret tokens, or complete URLs that can contain private query parameters. A property being easy to capture is not a reason to retain it.
The free generator exports a vendor-neutral CSV or JSON specification. Its suggested properties are planning ideas, not a claim that VisitLift or another provider accepts arbitrary fields. Map each event to supported instrumentation, set the necessary consent and identity boundaries, and keep account references opaque where they are needed.
Review the plan when the product changes
Add the owner, event definition, eligible population, implementation location, and verification procedure to your team’s working document. When signup changes from password to OAuth, or activation changes from creating to publishing a project, update the definition before comparing old and new cohorts.
Install the minimum useful set, verify it on a real deployment, and inspect a short funnel. Add an event when it resolves a repeated question. VisitLift’s event and measurement documentation explains its supported goals and boundaries; the planning tool itself does not install tracking or create goals in a workspace.