Skip to content
fromHello

Tracking plan

A tracking plan is the living specification of every analytics event a product instruments: each event's name, its properties, when it fires, and who owns it. It is the contract between the people who ship code and the people who read the data, so the same behavior is always recorded the same way.

Updated 2 min readBy fromHello

Key takeaways

  1. One row per event — name, properties, trigger, owner — and the plan changes in the same pull request as the code.

  2. A single naming convention, commonly object_action in snake_case (subscription_started), keeps events queryable months later.

  3. Drift — renames, duplicates, missing properties — corrupts funnels, segments, and every report downstream, silently.

What goes into a tracking plan?

At minimum, one row per event: the event name, the properties attached to it, the exact moment it fires, and the person who owns it. Good plans also record which tools receive the event and the question it exists to answer — an event nobody queries is maintenance without payoff. Format matters less than habit: a spreadsheet, a versioned file in the repo, or a schema tool such as Segment Protocols or Amplitude Data all work, as long as the plan is updated in the same pull request as the tracking code.

A tracking plan and the terms it is built from.

How should you name events?

Pick one convention and enforce it everywhere. The most common is object_action in snake_case: subscription_started, invoice_paid, report_exported. Object first, so related events sort together; past-tense action, because the event records something that happened. Which convention you pick matters less than its uniformity — Sign Up, signup, and user_signed_up in one dataset are three events your analytics tool treats as strangers, and every chart built on them is wrong.

What is tracking drift, and why does it kill analytics?

Drift is the gap that opens between the plan and what the code actually sends: an event gets renamed without a plan update, a property changes type, a duplicate appears under a second name. Each change is small; together they make funnels undercount, dynamic segments stop matching the users they should, and dashboards drift into fiction — at which point the team stops trusting the data entirely. The cure is procedural, not technical: no event ships without a plan entry, and reviewing the entry is part of code review.

Why it matters for a two-person team

Small teams skip the plan because it smells like process for a company they are not yet. The logic runs the other way: with two people, nobody remembers in October why checkout_completed and order_completed both exist. A one-page plan written before the first event costs an afternoon — it is the first job a growth engineer does. For how the plan fits into a complete setup, from SDK to consent, see the guide to first-party data and tracking.

Sources

  1. Segment docs — Create a tracking plan (opens in a new tab)
  2. Amplitude docs — Plan your taxonomy (opens in a new tab)

FAQ

Common questions

  • What is the difference between a tracking plan and a data dictionary?

    A tracking plan is prescriptive: it says what should be instrumented, before the code ships. A data dictionary is descriptive: it documents whatever data already exists, warts included. Small teams usually merge the two — one document that is both the spec and the reference.

  • Who should own the tracking plan?

    One named person — in a small startup, usually the founder closest to the data or the growth engineer. Ownership means approving every new event and rejecting names that break convention, not writing every entry personally.

  • How many events should a tracking plan contain?

    Fewer than you expect. Start with the events your funnel and activation metric need, and add one only when a real question demands it. Every event is a maintenance commitment; both Segment and Amplitude recommend keeping the taxonomy lean.

  • What tools can enforce a tracking plan?

    Schema-validation tools — Segment Protocols, Amplitude Data, Avo — block or flag events that do not match the plan. Without them, a linter on event names plus one review rule (no new event without a plan entry) catches most drift at two-person scale.

fromHello is open-source marketing automation: messages triggered by what people do.

fromHello Cloud is in early access through the waitlist.

Join the waitlistStar on GitHub (opens in a new tab)

Keep reading

All guides

Early access

fromHello Cloud

You didn’t start this to stay small.

Early access to fromHello Cloud opens in stages. Onboarding is hands-on: we help you get set up and bring your contacts over.

We’ll email you when your spot opens. No spam.

Not ready to join? View on GitHub