Tracking Spec (Event Taxonomy)

Why it matters

Product data rots fast without taxonomy: duplicate events, random properties, "mystery metrics." A tracking spec is the contract between product, engineering, and analytics.

Template

Naming convention (pick one and enforce it)

Option A (dev-friendly):

events: snake_case + past tense (e.g., workspace_created)
properties: snake_case

Option B (Title Case events):

events: Title Case
properties: snake_case

Tracking plan table

| Event | Trigger | Required properties | Owner | Notes | |------|---------|---------------------|-------|------| | signup_completed | successful registration | source, plan, landing_path | Growth | prefer server-side | | workspace_created | workspace created | workspace_id, role | Product | | | primary_object_created | core object created | object_type, object_id | Eng | | | key_feature_used | key action performed | feature | Product | |

Standard properties (always)

user_id, workspace_id, plan, role
source, utm_*, landing_path, referrer_domain
environment (prod/stage), app_version

Common mistakes

Overloaded events (one event tries to represent multiple actions).
No property dictionary (same meaning, different keys).
Missing environment (staging pollutes prod).
No governance (who approves new events?).

Example output

A single tracking plan table + property dictionary + naming rules on one page.

Segment Tracking & Governance — A comprehensive implementation guide covering event dictionaries, environment management, spec review workflows, and common pitfalls.
Typed Event Tracking with TypeScript — Build type-safe analytics to eliminate tracking bugs at compile time.