What Goes in a Tracking Plan, and What It Cannot Catch

What is a tracking plan?

In product analytics, a tracking plan is the written spec that lists every event a product sends, the exact moment each one fires, the properties it carries with their types, the source that emits it and the person who owns it, agreed before anyone writes instrumentation code. Segment's Protocols documentation defines it as "a data spec outlining the events and properties you intend to collect across your Segment Sources." Amplitude's version adds the reason for each row: "A tracking plan defines every event and property you collect, why you collect each one, and which source emits it."

The plan is the contract and the tracking code is the implementation. When the two disagree, somebody has to decide which one is wrong, and without a plan there is nothing to check the code against. Event tracking is the practice of recording what users did. The tracking plan is the document that says what "did" means for each event.

What columns does a tracking plan need?

A tracking plan needs one row per event and enough columns that an engineer could implement the event without asking a question. The columns below are the ones that prevent real arguments later. Segment's Tracking Plan editor uses a subset of them, named Name, Description, Status, Data Type and Permitted Values.

Segment's list of data types is a reasonable default for the Type column: "any, array, object, boolean, integer, number, string, null, Date time", with date-times "required to be in ISO-8601 format." Its Permitted Values column accepts "simple regular expressions to validate property values", and that only works on string properties.

What does a filled tracking plan row look like?

A filled row reads like a small spec. Here is one event from a SaaS signup flow, written the way a plan stored in a repository would hold it:

event: signup_completed
trigger: >
  Fires once, from the server, after the account row is written.
  Not on button click. Not on page load of /welcome.
answers: Signup-to-activation funnel, weekly signups by channel
source: backend
owner: growth-eng
status: live
properties:
  plan:
    type: string
    required: true
    allowed: [team, pro]
  signup_method:
    type: string
    required: true
    allowed: [email, google, github]
  invited:
    type: boolean
    required: false

The trigger text is the part most plans get wrong. "Fires on signup" does not say whether a failed form submission counts, whether a retry fires twice, or whether the event comes from the browser or the server. Writing "not on button click" rules out the most common duplicate, where the click fires and the server then rejects the form. The naming style is a separate choice, and picking an event naming convention before the first row saves a rename later.

What can a tracking plan tool validate, and what can it not?

A tracking plan tool validates the events that arrive against the events the plan describes, and it cannot tell you about the events that never arrive. That second half is the most useful thing to know about these tools, and the vendors say it themselves.

Segment's documentation describes the checking side: "Violations generate when an event doesn't match the spec'd event in the Tracking Plan." Then, in the description of the Status column: "You can't require a Track call because Segment is unable to verify when a Track call should be fired." Segment can check that an event has its required properties, but it has no way to know that the event should have fired and did not.

Amplitude handles the opposite direction. Events that arrive without being in the plan show up as "Unexpected", and Amplitude says "You can add them to your plan, or delete them to stop ingestion and remove them from your data catalog." For the missing direction, Amplitude publishes a separate guide titled "Planned events that never arrived: confirm the problem", which tells you to "Compare your tracking plan with observed data and your planning records to find planned events that never reached Amplitude." The same page says "Data Assistant doesn't identify these entries" and that Observe, the view that shows whether an event arrived, covers "the selected time range, up to 14 days."

So a green validation dashboard means every event that arrived matched its spec. It does not mean every event in the spec is arriving. The practical fix is a check per release. List the events marked live in the plan, query recent data for each name, and flag any with zero count. Amplitude's guide adds the right caution: an event with no activity "might belong to a rare workflow, a disabled feature, or a future release", so ask the owner before deleting the row.

Which destination limits belong in the plan?

The limits of every tool the events flow into belong in the plan, because a row that breaks a limit fails silently in the destination. Google Analytics says it plainly: "Google Analytics doesn't log events, event parameters, and user properties that exceed the following limits."

The two tools fail differently when a plan exceeds them. GA4 drops the item: its example is that "Analytics doesn't process the 26th user property nor does it process an event name with more than 40 characters." Amplitude keeps ingesting but "stops indexing new values", so the data exists in exports but cannot be queried in charts. Amplitude adds that events past its event-type limit "still count toward the monthly event volume", which means a runaway instrumentation bug costs money for data nobody can chart.

Segment has its own limit for plans managed as files: an uploaded Tracking Plan CSV "must be smaller than 15 mb", and must "have fewer than 100,000 rows and 2,000 rules."

How many events should the first version hold?

The first version should hold the few events that answer the questions the team already asks every week, and nothing else. Amplitude's implementation guide says "resist the urge to track everything upfront" and suggests "starting with two important events in your product to give you initial insights." Its taxonomy playbook orders the work as business objectives first, then key metrics, then the events and properties those metrics need.

That order is the right one. Start from the metric in the weekly review, such as the north star metric, write the question it raises, and add only the events needed to answer it. A signup flow that needs a funnel analysis needs one event per step and one property that splits the result, not forty events for every click on the page. If you run Flowsery, its goal tracking "records signups, purchases, downloads, and custom events in one place", and the plan is where you decide which of those goals are worth defining.

How do you keep a tracking plan current?

A tracking plan stays current when a change to tracking code cannot merge without a matching change to the plan. Everything else is a reminder that people ignore.

The Status column does most of the work. Marking an event deprecated instead of deleting its row stops a new engineer from reintroducing the old name six months later. Both tools keep history. Segment says plan changes made by upload are "reflected in the Audit Trail and Tracking Plan changelog", and its CSV export names each file workspaceSlug-trackingPlanName--yyyy-mm-dd--hh-mm-utc. A plan that lives in the repository beside the code gets history from version control for free.

Frequently asked questions

What is the difference between a tracking plan and an event naming convention?

An event naming convention is one rule inside a tracking plan: how names are formed, such as object_action in snake case. The tracking plan is the full list of events that follow that rule, with each event's trigger, properties, types, source and owner.

Who should own the tracking plan?

One named person should approve changes, drawn from the team that reads the data most, with engineers proposing rows. A plan that anyone can edit without review drifts toward the same state as having no plan.

Should a tracking plan live in a spreadsheet or a tool?

A spreadsheet works for a first version with a few dozen events. A tool such as Segment Protocols or Amplitude Data adds validation of incoming events against the plan, and a file in the code repository adds review and history through pull requests.

Should server-side events go in the same tracking plan?

Yes. Keep one plan with a Source column, because the same event name sent from the browser and the server double counts unless the plan states which one is the record. Amplitude's own definition of a tracking plan includes "which source emits it".

How do you find planned events that never fired?

Compare the events marked live in the plan against the event names seen in recent data, and flag any with zero count. Segment states it cannot require a Track call, and Amplitude says its Data Assistant does not identify these entries, so no validation dashboard raises the problem on its own.

Does autocapture remove the need for a tracking plan?

No. Autocapture records clicks and page views, but it does not record what a click meant, such as which plan a user picked or whether the server accepted the form. The events that feed revenue and activation metrics still need a written trigger and property list.

What should the trigger column say?

It should name the single moment the event fires, in plain words, including what does not count. "Fires on signup" leaves open whether a failed submission or a retry counts, and whether the browser or the server sends it. "Fires once, from the server, after the account row is written. Not on button click" leaves nothing to guess.

How many events should a tracking plan start with?

Start with the few events that answer questions the team asks every week. Amplitude's implementation guide says "resist the urge to track everything upfront" and suggests starting with two important events. Add more only when a metric needs them.

What happens when a plan goes over GA4 or Amplitude limits?

GA4 drops the item, so a 26th user property or an event name over 40 characters is never processed. Amplitude keeps ingesting but stops indexing new values, so the data shows up in exports but cannot be queried in charts. Events past its event-type limit still count toward monthly event volume.

Why mark an event deprecated instead of deleting the row?

A deprecated row stops a new engineer from reintroducing the old name months later. It also keeps the history in the plan. Before deleting a row for an event with no activity, ask the owner, since it "might belong to a rare workflow, a disabled feature, or a future release."