Event Tracking Done Right: A Blueprint for Product Teams

Every product team starts tracking events with good intentions. Click here, sign up there, feature X adopted. Six months later: 200 events with inconsistent names, duplicate tracking, events that fire on conditions nobody remembers, and an analytics schema that only the engineer who built it can decode. The tracking graveyard is real, and most teams end up there.

Why Event Tracking Schemas Rot

The root cause is almost never technical. It's organizational. Event tracking is added ad hoc, by whoever is working on a feature, without a naming convention, without documentation, and without a review process. Over time, the schema reflects the history of who built what, not what the product actually does.

The first engineer named events like 'btn_click_signup'. The second used 'signup_button_clicked'. The third used 'user_signed_up'. Now you have three events that may or may not represent the same action, across different surfaces, and nobody is sure which to use in a dashboard.

The Object-Action Naming Convention

The most durable event naming convention is Object-Action: what was interacted with, then what happened to it. This format is readable, sortable, and consistent regardless of who adds the event.

• user_signed_up — object: user, action: signed_up
• subscription_upgraded — object: subscription, action: upgraded
• report_exported — object: report, action: exported
• feature_enabled — object: feature, action: enabled (with a 'feature_name' property)
• onboarding_step_completed — object: onboarding_step, action: completed (with a 'step_number' property)

Notice that specifics go in properties, not in the event name. 'report_pdf_exported' and 'report_csv_exported' should be one event — 'report_exported' — with a property 'format: pdf' or 'format: csv'. This makes querying across all report exports trivial, while still allowing you to filter by format when needed.

The Four Categories of Events Worth Tracking

Not all events are equally important. Organizing your schema around business outcomes keeps it useful as the product grows:

1. Acquisition events — how users first arrive and what converts them: user_signed_up, trial_started, referral_link_clicked
2. Activation events — the moments that indicate a user is getting value: onboarding_completed, first_report_created, tracking_code_installed
3. Retention events — signals that predict whether users will stick around: feature_used_this_week, session_started (frequency), report_shared
4. Revenue events — directly tied to money: subscription_started, plan_upgraded, payment_failed, subscription_cancelled

Properties: The Metadata That Makes Events Useful

An event without properties is a count. An event with good properties is a story. Every event should carry a standard set of metadata that makes it queryable across dimensions:

• user_id or anonymous_id — to join events to user records
• session_id — to group events within a single visit
• timestamp — in UTC, millisecond precision
• platform — web, ios, android
• page_url or screen_name — where the event occurred
• referrer — how the user arrived (for acquisition events)

Governance: Who Owns Tracking?

Without ownership, tracking decays. With too much ownership, nothing gets added. The right model: a small tracking council (one engineer, one product manager, one analyst) that reviews and approves additions to the schema, with a lightweight process for engineers to propose new events.

The review checklist for any new event: Does this event already exist under a different name? Does the naming follow the object-action convention? Are all necessary properties included? Is this event documented in the schema registry? Who will use this data, and for what?

The Schema Registry

Every event in production should have a record in a schema registry — a document (or tool) that lists the event name, its definition, which properties it carries, which team owns it, and when it was added. This is the documentation that prevents the graveyard.

A schema registry doesn't need to be a specialized tool. A Notion database or a spreadsheet with one row per event is enough, if it's maintained. The discipline of updating it is what matters. Make updating the registry part of the definition of 'done' for any feature that touches tracking.

Implementation Checklist

1. Audit your current events — list everything currently tracked, identify duplicates and gaps
2. Adopt the object-action naming convention — document it and share it across engineering and product
3. Define your four core event categories and assign owners
4. Establish standard properties — implement them as a shared middleware layer so every event carries them automatically
5. Create your schema registry — start with current events, add new ones before code ships
6. Set a quarterly review cadence — prune events that nobody uses, update descriptions that are stale