Designing a Product Analytics Event Taxonomy That Scales

Why Event Taxonomy Matters

The event taxonomy — the system of event names, property names, and values used to track user behaviour — is the foundation of your entire analytics stack. A well-designed taxonomy produces consistent, queryable data across years of product development. A poorly designed one produces a mess of duplicate events, inconsistent names, and properties that mean different things in different contexts.

Most teams discover taxonomy problems after 6-12 months when they try to answer a question and realise the data doesn't support it. Our product analytics service starts with taxonomy design before writing a single tracking call.

Naming Convention Principles

The most reliable naming convention: [Object] [Verb]ed in title case. Examples:

• Report Viewed
• Dashboard Created
• Subscription Upgraded
• Team Member Invited

This approach ensures events are readable, past-tense (something happened), and consistently structured. Avoid abbreviations, avoid platform qualifiers (no "iOS Report Viewed" — just "Report Viewed" with a platform property), and avoid generic names like "Button Clicked" without a specific subject.

Property Schema Design

Every event should carry a baseline set of properties automatically:

• user_id: Your internal identifier for the user
• plan: Current subscription tier
• role: User's role within their account
• account_id: For B2B products — which company they belong to
• platform: web | ios | android

These context properties are usually set as super properties (Mixpanel) or user properties (Amplitude) so they attach automatically to all events.

Event-Specific Properties

Beyond the baseline, each event should have properties specific to what happened:

• Report Viewed → report_type, report_id, data_source
• Subscription Upgraded → from_plan, to_plan, trigger (manual vs. automated prompt)
• Feature Used → feature_name, usage_count (cumulative)

Taxonomy Governance

A taxonomy without governance becomes inconsistent over time as different engineers add events differently. Create a tracking plan document (a spreadsheet or a tool like Avo, Segment Protocols, or Amplitude Data) that defines every event, its properties, and acceptable values. Require all new events to be added to the tracking plan before implementation. Review the tracking plan quarterly. This process is as important as the initial design.