Tracking Schema: Your Analytics Naming Convention

Why it exists

Without a plan, different teams will track the same user action with different names, like SignUp, User Signed Up, and user_signup. This makes it impossible to get a single, accurate count of a key metric. A tracking schema solves this by creating a single source of truth for what to track and what to call it.

The mental model

Think of a tracking schema as the API contract for your analytics. It's a strict, shared dictionary that defines every event and property your application sends to an analytics service. Just like an API schema prevents bad data from entering your backend, a tracking schema prevents messy data from polluting your analytics.

How it works

A schema is built on users, events (actions), and properties (context). The process starts by defining business goals, like "increase user retention." From there, you identify key events that drive that goal, such as Project Created or Teammate Invited. For each event, you enforce a consistent naming convention. A common standard is [Noun] + [Past-Tense Verb] from the user's perspective, like Song Played, not Played Song. You also define properties for each event, like song_title or genre, with consistent casing.

When to use it

Use a tracking schema from the very beginning of any product analytics implementation. It's critical for any system where multiple teams, developers, or services send data. It is the foundation for building reliable dashboards, conversion funnels, and retention analysis.

When not to use it

There's rarely a good reason to skip a tracking schema. For a tiny, short-lived project with a single developer, an informal approach might suffice temporarily. However, this creates technical debt that becomes very expensive to fix as the product grows. The cost of cleaning up messy analytics data later far outweighs the upfront planning effort.

One canonical example

To track a user playing a song, a bad setup might have one client send song_played and another send Played-Song. A good tracking schema would mandate a single event: Song Played. It would also specify required event properties like song_id: "ab_123" and source: "playlist". It would also define user properties that apply to the user across all events, like subscription_tier: "premium". This structure ensures every "play" event is captured identically, allowing for precise analysis.