Data Taxonomy for Analytics: Naming Rules and a Cleanup Example

A data taxonomy decides what you track and what everything is called, so that "sign-ups" means the same in every report. This guide explains the four layers, gives naming rules with examples, works through a cleanup of a four-year-old event list, and shows how to keep it from drifting.

What a data taxonomy is

In analytics, a data taxonomy is the agreed structure and naming for what you track: which events exist, what they are called, which properties they carry and which values those properties may take.

Without one, the same action gets tracked as "Signup", "sign_up" and "user_registered" by three teams in three years, and every report needs a footnote.

Four layers

The table below lists the four layers of an analytics taxonomy with examples.

Write each layer into the tracking plan, with an owner and an example.

Naming rules

Pick rules once, write them down, and apply them everywhere:

1. Object + action, past tense: account_created, report_shared, order_completed. The object first groups related events together in lists.
2. One case style: snake_case for events and properties is common. Never mix.
3. No values in names: not clicked_pricing_button_blue; use button_clicked with button: pricing and variant: blue.
4. Same property, same name everywhere: plan on every event, not plan, plan_name and tier.
5. Controlled values for properties used in reports: method is one of email, google, github, in lower case.
6. Track the outcome, not the click, where possible: account_created after the server confirms, not signup_button_clicked.

A worked cleanup

A product that had grown for four years had 186 distinct event names (sample numbers throughout). A review found:

• Nine names for creating an account: Signup, sign_up, signUp, user_signed_up, register, Register Click, signup_google, signup_email, account_create.
• 38 events with no hits in 90 days.
• 310 property names, many duplicates (plan, planName, plan_tier).

After the cleanup:

• 186 → 42 events. The nine sign-up variants became one event, account_created, with method: email | google | github.
• 38 unused events marked deprecated, then removed from code.
• 310 → 75 property names, each with a type, description and example.
• Old names mapped to new ones for historical reports, so trends did not break.

The sign-up count now matches the database within 1%; before, depending on which event you picked, it was 40% too low or 15% too high.

Keeping it clean

• One owner approves new events and properties.
• Plan before code: every new event is written into the tracking plan, with required properties, before it is built.
• Check after release: hits in the first 24 hours and completeness of required properties.
• Review quarterly: deprecate unused events, merge new duplicates.

Where TapCub stores and checks it

• All-platform analytics › Data › Tracking plan holds planned events with display name, category, platforms, properties (type, required, example), owner and status (Proposed, Developing, Accepting, Live, Deprecated). Live verification shows hits in 24 hours and required-property completeness. Plans import from CSV and export to XLSX.
• All-platform analytics › Data › Event inbox holds event definitions on its Definitions tab, plus new events waiting to be claimed.
• All-platform analytics › Data › Property dictionary documents properties.
• All-platform analytics › Data › Virtual events / props combines existing events, such as several old sign-up names, into one virtual event without changing code.

Related: tracking plan, data dictionary, event tracking and data quality.