Should I track this event or is it noise?

You're here when: You're designing a tracking plan or adding instrumentation to a new feature and you're debating whether a specific user action is worth logging.

The Heuristic

The answer to "should I track this?" is almost always yes. The real question is "can I track it well?"

• Track user actions, not system events. "User clicked upgrade button" is useful. "Server processed payment webhook" belongs in your application logs, not your analytics.
• Name it clearly using verb_noun format. clicked_upgrade_button, submitted_signup_form, viewed_pricing_page. If you can't name it in two words, you probably don't understand what you're tracking.
• Attach properties, not just the event. The event viewed_page is almost useless. The event viewed_page with properties {page_name: "pricing", referrer: "blog", user_plan: "free"} answers real questions.
• Map it to a question you'll actually ask. If you can finish the sentence "this event will help me understand whether..." then track it. If you can't, you're collecting noise.

Decision Tree

Quick Example

A team at an early-stage productivity app tracked 47 events with no naming convention. Some used camelCase, some used snake_case, some used spaces. "Sign Up" and "signup_completed" and "user_registered" all meant the same thing. When the PM tried to build a funnel, she spent two days just mapping event names to actual user actions. They paused feature work for a week, defined a naming convention, and re-instrumented everything. Painful, but it was the last time anyone spent a day decoding their own tracking.

The Real Cost of Bad Tracking

The danger isn't tracking too much. Storage is cheap and most analytics tools handle high event volumes fine. The danger is tracking inconsistently.

When event names don't follow a convention, nobody trusts the data. When properties are missing from some events but not others, every analysis starts with a data cleaning exercise. When the same action has three different event names because three different engineers instrumented it, your funnel has gaps that look like user drop-off but are actually instrumentation holes.

Segment (now Twilio Segment) published their tracking plan framework specifically because their largest customers kept hitting this wall. The companies with clean data weren't the ones tracking less. They were the ones with a written naming convention, a tracking plan spreadsheet, and a QA step before any new event shipped to production. The upfront cost is a day of planning. The downstream cost of skipping it is weeks of cleanup and months of distrust.

The Anti-Pattern

The Everything Firehose. The team tracks 500 events with no naming convention, no property standards, and no documentation. Every engineer picks their own format. The analytics tool has so much data that nobody can find anything. Searches return duplicates, funnels break because step names don't match, and the PM stops using the tool entirely because it's faster to ask engineering directly. The data exists but it's unusable, which is worse than not having it at all.

Written with ❤️ by a human (still)