Build a Tracking Plan

A tracking plan is the shared spec for what you track and how each event is named and shaped. Writing it before you instrument is the difference between analytics you trust and a pile of inconsistent events nobody queries. This guide gives you a repeatable process and ready-to-fill templates.

Why Write a Plan First

• Consistency. Engineers, PMs, and analysts all reference the same event names and property keys. No signup vs SignedUp vs user_registered.
• You only track what answers a question. Every event maps to a KPI, so you don't drown in events nobody looks at.
• Cheaper to change names than data. Renaming an event after it's shipped means reconciling historical data. The plan catches naming problems on paper.

The Process: KPIs → Flows → Events → Properties

1. Start from KPIs, Not Features

List the handful of metrics the business actually steers by. For most products they fall into:

• Acquisition — where do people come from?
• Activation — do new users reach first value?
• Engagement / retention — do they come back and use core features?
• Revenue — do they convert, expand, and stay?

Write each KPI as a question: "What % of signups reach activation within 7 days?" A KPI you can't phrase as a question won't tell you what to track.

2. Map Each KPI to a User Flow

For every KPI, walk the journey a user takes. "Conversion to paid" might be: land on pricing → start checkout → enter payment → subscribe. The steps in that flow are your candidate events.

3. Turn Flow Steps into Events

Each meaningful step becomes one event, named after the action that completed (CheckoutStarted, Subscribed). Follow the Events vs Properties rule — one event per action, variants go in properties — and the naming conventions there (PascalCase events, snake_case properties).

Logspot.track({
  event: 'CheckoutStarted',
  metadata: { item_count: 3, cart_value: 149.0, currency: 'USD' },
});

4. Define Properties for Each Event

For every event, list the properties that let you slice it: the dimensions you'll filter and group by (plan, source, category) and the measures you'll sum (amount, item_count). This is where most of the analytical value lives — a thin event with rich properties beats many narrow events.

5. Decide Who Is Identified, and When

Note the point in each flow where you can identify() the user, and which traits you'll attach (e.g. plan, company_size). Anonymous activity before that point is merged into the person on identify, so you keep the full pre-signup journey.

6. Review, Then Instrument

Circulate the plan, agree on names, then write the track calls. Keep the plan in version control next to your code so it stays the source of truth.

Templates

Start from one of these and adapt it. Each is a CSV with columns for the event, when it fires, its properties (in snake_case), the KPI it answers, and a priority so you can ship the high-value events first.

• SaaS tracking plan (CSV) — signup → activation → subscription → expansion → churn
• E-commerce tracking plan (CSV) — product views → cart → checkout → purchase → refunds
• B2B / account-based tracking plan (CSV) — leads → trials → workspaces → expansion → renewal

The templates use Payment as the reserved revenue event and value + currency as first-class fields — see revenue() in the SDK reference.

A Worked Example (SaaS Activation)

KPI: What % of signups reach activation within 7 days? Flow: sign up → create first project → complete onboarding.

With these three events you can build the activation funnel, segment it by signup_method, and watch time_to_activate_seconds trend — all without touching the instrumentation again.

Next Steps

• Events vs Properties — the naming rules referenced above
• How Tracking & Identity Works — identify, sessions, groups, consent
• JS SDK reference — track, identify, revenue