Track Before Launch

A feature without tracking might as well not have shipped. Define the tracking plan while writing the spec and ship it with the feature.

A feature without tracking might as well not have shipped. You don't know how many saw it, how many used it, how many got stuck at which step — you can only say "it shipped" on a hunch.

What you'll run into:

• Two weeks after launch, your boss asks how it's doing, and after digging around all you can say is "seems like a lot of people used it"
• You want the conversion numbers for the new feature and find only one click was tracked — the middle steps are empty
• Backfilling tracking means scheduling another release, and by the time the data accumulates it's a month later and the feature is nearly retired
• You have data, but still no idea how many people failed or why

When to define tracking

The answer is while writing the spec, on the same page as the acceptance criteria. Not after development, and definitely not after launch.

The test is simple: if the feature's spec doesn't answer "which numbers will I look at after launch to judge whether it succeeded," the spec isn't finished. This is the same thing as the three parts of defining a need — the acceptance criteria were always supposed to include the measurable part.

The minimum tracking set

You don't need dozens of events on day one. Five events per feature answer most questions:

• Exposure. How many people saw the entry point. It's the denominator — without it, every conversion rate downstream is uncomputable.
• Start. How many clicked in and began. A big drop from exposure to start points to the entry itself: unclear, intimidating, or in the wrong place.
• Success. How many made it to the end. This is the number you actually want.
• Failure (with reason). Failure must carry a reason attribute: validation failed, API errored, balance too low. Tracking success but not failure means only hearing good news.
• Drop-off. Where the people who quit midway stopped. This one tells you directly which page to go fix.

These five events chain into a funnel. Wherever the drop-off is sharpest is where you focus next — no more guessing. Web analytics as a discipline is measuring, collecting, and analyzing exactly this kind of behavioral data to improve a product; event tracking is how you practice it inside your own feature. web-analytics

What to specify per event

Each event also needs two easily-missed things: who reports it (frontend or backend) and who will look at it. Anything tied to money or permissions is reported by the backend — the frontend can be intercepted, disabled, or spoofed. Events no one will look at shouldn't be tracked; they're just overhead. And name events as "module_object_action," lowercase with underscores, one scheme site-wide — with sloppy names, three months later even you won't recognize what click_btn_2 means.

Common pitfalls

• Tracking only success. The most common one. Everything looks fine after launch because the people who failed were never recorded.
• No correlating id. Without user and session identifiers, you can only see totals — you can't tell whether the same person made it through, and the funnel can't be assembled.
• Tracked but never looked at. Events pile up while no dashboard gets built. When you define an event, write down what question it answers; if it answers none, cut it.
• Counting frontend events as the ledger. A frontend success event only means "the UI showed success." Real payments and real charges must be based on backend records.
• Renaming without updating the dictionary. The event dictionary has to change with the code. The day the dictionary and the code disagree, nobody trusts the data anymore.

If you're using AI to write code, put the tracking directly into the same spec so it ships alongside the feature. Rules you have to restate every time are a good fit for the project constraints file (see Distilling Constraints) — no need to remind it each time.