- A click is a useful intent signal with a different meaning from a completed account.
- Define completion in your application’s authoritative system.
- A server confirmation still needs reliable collection, deduplication, and an explicit measurement population.
Give each commitment its own name
A visitor can click Start trial, open a signup form, request a magic link, create an account, and confirm a card-required trial at different times. Some people stop between these steps. A single conversion label hides the distinction and makes the funnel difficult to interpret.
Use separate names for intent and outcomes. For example, signup_cta_clicked describes a deliberate selection, signup_started describes entering the flow, and account_created describes a newly confirmed application account. Add activation and trial-start events only when they represent separate defined commitments.
Find the system that knows completion happened
For account creation, that is usually the application handling the durable account record or its trusted authentication result. The button handler knows the user tried. A return URL knows the browser arrived. Neither alone knows whether a new account was actually created.
Define how your flow handles email verification, existing accounts, provider errors, and a repeated callback. An OAuth login can succeed for an existing customer without creating anyone new. A magic-link request can succeed even if the recipient never follows the link. Document whether “created” and “verified” are separate states in your product.
Test the cases that should not count
Build a small acceptance checklist before launching a signup campaign. A validation error should not count as account creation. Abandoning a form should not count as a trial. Signing in to an existing account should not count as a newly acquired account. Reloading a confirmation page should not create another completion.
Test retries and concurrent requests as well as the obvious happy path. Anchor a completion to a durable event identity and your provider’s supported deduplication mechanism. A timeout in a browser does not necessarily mean the server failed; blindly resending a new completion can inflate the count.
| Test | Intent or start | New account |
|---|---|---|
| CTA click then abandon | May count | 0 |
| Invalid signup request | May count | 0 |
| One successful new registration | May count | 1 |
| Retry / confirmation-page reload | No extra completion | Still 1 |
| Existing-account login | Separate login event if needed | 0 |
Keep activation and billing distinct
An account that exists may not have experienced the product’s value. Define an activation milestone such as the first saved project or the first report containing real data. Do not count a sample dashboard as genuine data activation unless that is explicitly your chosen learning measure.
Similarly, a trial can start without collecting an initial payment. For a card-required trial, confirm the billing state required by your terms rather than inferring success from a checkout return. For paid conversion reporting, use the verified payment definition and keep it separate from account creation and trial start.
Compare counts with the same boundaries
Your application’s account total and your analytics signup total may differ because of collection failures, excluded environments, consent or identity coverage, timestamps, and duplicate handling. Reconcile one known registration through the whole path before deciding that all unmatched accounts are lost conversions.
In VisitLift, start with supported goals and verify the expected accepted event. A free tracking plan is a specification, not an automatic server integration. Keep the measurement population explicit and inspect actual counts beside the conversion rate before changing your landing page.