Taxonomy and Tracking Plan: A Comprehensive Guide for Precise Analytics in Metrix

Have you ever encountered a situation where the same user action (e.g., “clicking a button”) was recorded under multiple different names in your data? Or found it difficult to understand what a specific event actually represents? This is where Taxonomy and a Tracking Plan come to your rescue!

These two concepts form the essential foundation for collecting accurate and meaningful data in Metrix, enabling you to transform raw information into actionable insights.

1. What is Event Taxonomy and Why is It Critically Important?

Taxonomy in the world of data analytics and event tracking refers to an organized, standardized, and hierarchical system for naming, categorizing, and defining events and their properties/attributes. Simply put, a taxonomy is a set of rules and guidelines that determine how every user activity or occurrence in your product should be named and recorded.

This concept is similar to the classification of living organisms in biology; just as every living creature has a specific name and place within a classification tree, in data taxonomy, every event must have a unique and meaningful name and be placed in its correct position.

Why is Taxonomy Critically Important?

Implementing a robust taxonomy is the cornerstone of any successful data analysis. Here are the key reasons for its importance:

• Data Consistency and Integrity: A taxonomy ensures that a specific event is always recorded with a single, unified name. For example, instead of logging button_clicked in one instance and click_on_button in another, your taxonomy dictates a standard (e.g., button_clicked). This prevents human error and keeps your data clean and reliable.

• More Accurate and In-Depth Analysis: With unified and standardized data, your analytics team can generate more precise reports, create meaningful dashboards, and perform deeper analyses. Comparing, filtering, and segmenting users based on events becomes significantly easier.

• Increased Analysis Speed and Reduced Engineering Time: Analysts can focus directly on deriving insights instead of spending time cleaning, interpreting, and normalizing inconsistent data. Additionally, developers know exactly which events and attributes need to be sent.

• Effective Team Collaboration: Taxonomy serves as a common language for all stakeholders (product, development, marketing, analytics teams, and even management). Everyone understands exactly what is meant when a specific event is discussed.

• Scalability: As your product grows and the number of events increases, managing data without a taxonomy becomes a nightmare. A well-defined taxonomy helps you scale through proper organization and documentation.

• Informed Decision-Making: Ultimately, high-quality, structured data derived from a robust taxonomy leads to clearer insights and better strategic decisions for improving your product and business.

• Preparedness for Advanced Analytics and Artificial Intelligence: In today’s world, data analytics tools and artificial intelligence (AI) play a key role in discovering patterns and predicting user behavior. Unified and structured data originating from a strong taxonomy provides the necessary input for AI models. The cleaner and more consistent your data, the more accurate the analysis, powerful the predictions, and deeper the insights AI can offer—enabling smarter decisions for your business growth.

2. Key Components of a Strong Taxonomy

An effective taxonomy is not limited to just naming events; it includes the following elements:

2.1. Naming Conventions

These rules form the core of your taxonomy and determine how events and their attributes should be named.

• Standard Format:

  • Lowercase with Underscores (Snake_case): The most common and recommended format. Example: product_viewed, add_to_cart_clicked, payment_successful.
  • Avoid Spaces and Uppercase Letters: This ensures readability and compatibility across analytics tools.

• Hierarchical and Meaningful Structure:

  • Event names should be descriptive and indicate the action, object, and, if necessary, the context of the event.
  • Recommended Pattern: object_verb
    • This pattern names events in an “object_action” format. This method is highly readable and understandable, clearly showing what action was performed on which object.
    • Examples:
      • product_viewed (product viewed)
      • button_clicked (button clicked)
      • order_completed (order completed)
      • user_registered (user registered)
  • Avoid Ambiguity: Names should be completely clear and unambiguous. Avoid abbreviations that are not universally recognized.
  • Past Tense Verbs: Typically, completed actions are expressed using past tense verbs to indicate the event “has occurred.”

• List of Prohibited/Allowed Words: Define words that should not be used (e.g., click alone) or words that must be used in a specific form (e.g., viewed for viewing actions).

2.2. Defining Event Types

Events can be categorized based on the type of activity they represent:

• Interaction Events: Any action performed by the user. (Example: button_clicked, link_tapped, item_swiped)
• View Events: User viewing a specific page, section, or element. (Example: screen_viewed, product_page_viewed)
• State Change Events: Changes in user or system status. (Example: order_status_updated, user_account_created)
• System Events: Events automatically recorded by the system. (Example: app_opened, session_started)
• Business Events: Events that occur in your system’s backend and are not necessarily from direct user interaction but are important for business analysis. (Example: inventory_updated, course_published)

2.3. Event Attributes / Properties / Parameters

Attributes are supplementary information that provide additional details about an event. For each event, you should define its related attributes:

• Attribute Naming: Similar to events, following specific rules (lowercase with underscores). (Example: product_id, category_name, price, user_id, source).
• Data Type: Specifying the data type for each attribute (String, Number, Boolean, Array, Object) is crucial. This helps Metrix process and display data correctly.
  • Example: product_id (String), price (Number), is_premium_user (Boolean), items_purchased (Array), user_address (Object).
• Required/Optional: Specify which attributes are mandatory for each event and which are optional.
• Description: A brief and clear explanation for each attribute.
• Example Value: A realistic and understandable sample of the value sent for each attribute.

3. What is a Tracking Plan and How Do We Create One?

A Tracking Plan is a living, comprehensive document that lists all the events and attributes you plan to track in your application or website. This plan serves as a central reference for all team members (product, marketing, developers, analysts) and answers fundamental questions about why and how data is collected.

Key Components of a Tracking Plan:

For each event in the Tracking Plan, the following information should be recorded:

• Event Name: The standardized event name (e.g., product_viewed).
• Description: A brief explanation of the event and when it occurs.
  • Example: “This event is sent when a user views a product details page.”
• Business Goal/Reason: Why are we tracking this event? What insights does it provide?
  • Example: “To understand the popularity of different products and improve product discovery and sales optimization.”
• Platform/Source: (Web, Android App, Backend Server). This specifies where the event is sent from (e.g., via SDK or REST API).
• Attributes:
  • Attribute Name: (e.g., product_id, product_category, price)
  • Data Type: (String, Integer, Double, Boolean, Date, JSON Object, JSON Array)
  • Example Value: (e.g., P1234, Electronics, 999.99)
  • Attribute Description: A brief explanation of the attribute’s purpose.
  • Required/Optional: Specify whether this attribute must always be sent or not.
• Sample Payload (Optional): An example of the event’s JSON body with attributes, demonstrating how data should be sent in practice.
• Status: (e.g., “Planned”, “In Progress”, “Implemented”, “Deprecated” - for managing the event lifecycle).

Example of a Section from a Tracking Plan (Table):

(Note: The “example_payload” column in the table above is shown here for demonstration only. In an actual document, you can create a separate column for “Sample Payload,” reference it, or provide the JSON format in the event description.)

4. The Process of Creating and Maintaining a Tracking Plan

Creating a Tracking Plan is not a one-time process; it is a living document that requires continuous updates:

1. Define Key Goals and Questions: First and foremost, determine what questions you aim to answer through data tracking. What are your KPIs (Key Performance Indicators)? (For example: “What percentage of users complete the purchase process?”, “Which product feature is used the most?”). These goals will help you identify critical events.

2. Identify Key Stakeholders: Product, development, marketing, analytics, and UX/UI design teams should all participate in this process. Cross-functional collaboration is essential to ensure all needs are covered and the taxonomy is adopted.

3. List Main User Flows and Key Events: Map out all critical user paths in your product (User Journey). Identify and list key events in each path (e.g., registration, login, product view, add to cart, payment, use of a specific feature).

4. Define Naming Conventions and Structure: Based on the guidelines in the “Key Components” section, agree on a set of naming rules for events and attributes. These rules should be included in a reference document.

5. Define Details for Each Event and Its Attributes: For each identified event, specify the standardized name, a brief description, and all related attributes (including name, data type, and description).

6. Comprehensive Documentation: Create a central document (e.g., in Google Sheets, Notion, Confluence, or specialized taxonomy tools). This document should include:

• General naming conventions
• A list of all events with their standardized names (proposed slug or customName)
• Detailed descriptions of each event (when and why it is sent)
• A list of all attributes for each event (with name, data type, description, and example)
• Event status (e.g., “In Progress,” “Implemented,” “Deprecated”)
• Implementation responsibility (which team or individual is responsible for sending this event)

7. Training and Distribution: Familiarize all relevant teams with the new taxonomy. Conducting training sessions and providing practical examples are highly beneficial.

8. Continuous Review and Updates: A taxonomy is a living entity. As the product evolves, new features are added, or business objectives change, the taxonomy must also be reviewed and updated. This should be an ongoing process, with responsibility assigned to an individual or a team.

5. Taxonomy and Metrix: Synergy for Better Analysis

Metrix, as a powerful data analytics platform, enables you to collect and analyze events from your application or website. The importance of taxonomy becomes even more critical here.

When you send your events to Metrix based on a standardized and comprehensive taxonomy, you benefit from the following advantages:

• Reliable and Accurate Reports: The dashboards and reports in Metrix display information based on clean, standardized data that is entirely trustworthy and unambiguous.
• Building Correct Conversion Funnels: Understanding user paths and drop-off rates requires correctly named and sequenced events. A taxonomy makes this possible.
• Meaningful User Segmentation: You can divide users into different groups based on precise behaviors and attributes, enabling deeper analysis for each segment.
• User Behavior Analysis (User Journeys): With well-defined events, you can track users’ complete journey within your product and identify strengths and weaknesses.
• Maximizing the Value of Metrix’s Features: Capabilities such as cohort analysis and user retention/return analysis deliver the most value only when the input data is structured and of high quality.

In other words, a taxonomy ensures that the data you send to Metrix is not just “data,” but “actionable information” for strategic decision-making.