🧱 argil.io

How to design your tracking plan

2 min read
Last updated March 30, 2026

Use this when: You have analytics tools set up but no systematic approach to what you track. Events are being added ad hoc, naming is inconsistent, and nobody knows the full picture.

You're done when: You have a shared tracking plan document with named events, defined properties, and a QA process that runs on every PR.

The Sequence

Loading visualization...

Template

Loading visualization...

Naming Conventions Matter More Than Tool Choice

This is counterintuitive. Teams spend weeks choosing between Segment and RudderStack, between Amplitude and Mixpanel. Then they spend zero time agreeing on how to name events. The result: six months later, the same action has three names in the system, nobody can find the event they need, and every analysis starts with 20 minutes of detective work.

A well-named event in a mediocre tool is infinitely more useful than a badly-named event in a best-in-class tool. The naming convention is the API contract between your product team and your data. Once you have a thousand events, renaming is painful. The cost of getting this right early is two hours of team discussion. The cost of getting it wrong is months of data debt.

The rules are simple. Verb-noun format. Past tense for completed actions (signed_up, not signing_up). Lowercase with underscores. No abbreviations. No team-specific jargon. If a new engineer cannot understand what the event means from its name alone, the name is wrong.

Example

At Station, a browser for work I co-founded, our CTO set up the first tracking plan. It was clean, consistent, and followed the conventions. Then we hired more engineers and started shipping features fast.

Each engineer tracked things their own way. One would ship feature_adopted. Another would track featureUsed. A third would add new_feature_click. Same intent, three different names, no coordination. Within a year, the tracking plan was a fiction. The actual events in production were something else entirely.

When I needed to understand if a new feature was actually being used, I'd open a SQL editor and start guessing. Was it sidebar_opened? sidebarOpen? open_sidebar_click? I'd try three or four variations, then go find the engineer who shipped it and ask them directly. That was our analytics workflow.

We eventually did a full migration. Wiped the event taxonomy, rebuilt it from scratch, and added a rule: no event ships without a tracking plan entry reviewed in the PR. It fixed the problem. But we learned the lesson the hard way.

Loading visualization...

Written with ❤️ by a human (still)