The Ultimate Tracking Plan Template: Event Specification Guide for Analytics

“Every analytics implementation starts with good intentions and ends in chaos without a tracking plan.”

Teams fire events without documentation. Properties get named inconsistently. Critical user actions go untracked while irrelevant clicks clutter the data. Six months later, nobody trusts the data, nobody knows what events mean, and the engineering team dreads every analytics request.

A tracking plan prevents this entropy. It is the single source of truth that defines what you track, how you name it, what properties you attach, and how you identify users across their journey. Done well, a tracking plan transforms analytics from a liability into a strategic asset. Done poorly - or not at all - analytics becomes a graveyard of ambiguous data that nobody can interpret.

This guide provides everything you need to build a professional tracking plan: naming conventions, property standards, user identification strategies, complete examples for SaaS and e-commerce, and a downloadable template you can use immediately. By the end, you will have a framework that ensures clean, consistent, trustworthy data from day one.

What Is a Tracking Plan?

A tracking plan is a structured document that defines every event, property, and user attribute your analytics implementation will capture. Think of it as a contract between your product team, engineering team, and analytics consumers. It specifies exactly what data should be collected, in what format, and under what circumstances.

At minimum, a tracking plan includes an event name, a description of when the event fires, the properties attached to each event, the data type of each property, and whether each property is required or optional. More comprehensive plans also include implementation notes, sample payloads, ownership information, and links to related documentation.

The tracking plan is not code. It does not replace your analytics implementation. Instead, it serves as the specification that guides implementation. Engineers reference it when instrumenting events. Analysts reference it when interpreting data. Product managers reference it when requesting new tracking. Without this shared reference, every stakeholder operates with different assumptions, and the data reflects that inconsistency.

Why Tracking Plans Matter

The absence of a tracking plan creates problems that compound over time. Without standardized naming, the same action gets tracked as “Button Clicked,” “btn_click,” and “ButtonClick” depending on which engineer implemented it. Without property definitions, one event includes user_idwhile another includes userId and a third includes userID. Without documentation, a new analyst cannot determine whether “Purchase Completed” includes refunded orders or excludes them.

These inconsistencies destroy trust. When stakeholders notice that different reports show different numbers for the same metric, they stop trusting the data entirely. They revert to intuition and anecdote. The analytics investment produces negative returns because it has actively confused decision-making rather than clarifying it.

The Benefits of a Well-Designed Tracking Plan

A comprehensive tracking plan delivers five critical benefits that transform your analytics practice:

• Consistency: Every event follows the same naming pattern, uses the same property structure, and adheres to the same data type standards. Analysts can query confidently without wondering whether “signup” and “sign_up” are the same event.
• Speed: Engineers do not have to invent naming conventions or guess at property requirements. They reference the plan and implement exactly what is specified. Implementation time drops by 50% or more.
• Quality: Required properties are enforced. Data types are validated. Missing or malformed data is caught at implementation rather than discovered months later in a broken report.
• Collaboration: Product, engineering, and analytics speak the same language. When someone references “Checkout Started,” everyone knows exactly what that means and what data it includes.
• Scalability: New team members can understand the analytics schema without tribal knowledge. New features can be instrumented following established patterns. The system grows without degrading.

Anatomy of a Tracking Plan

A complete tracking plan contains several interconnected components. Understanding each component and how they relate is essential before you start building your own.

Events

Events are the core unit of behavioral analytics. Each event represents a discrete action that a user takes or that happens to a user. Events answer the question: “What happened?” Examples include “Signed Up,” “Added to Cart,” “Subscription Renewed,” and “Feature Activated.”

Your tracking plan should define each event with a clear name, a precise description of when it fires, and the trigger mechanism (user action, system event, or backend process). The description should be specific enough that any engineer could implement it consistently.

Properties

Properties provide context to events. While an event tells you what happened, properties tell you the circumstances. For a “Purchase Completed” event, properties might include order_id, total_amount, currency,payment_method, and items_count.

Each property in your tracking plan should specify the property name, data type (string, number, boolean, array, object), whether it is required or optional, a description, and example values. This level of detail eliminates ambiguity during implementation.

User Properties

User properties are attributes that describe the user rather than a specific action. They persist across events and define who the user is. Examples include plan_type,company_size, signup_date, and lifetime_value.

User properties enable segmentation and cohort analysis. When you want to compare activation rates between enterprise and SMB customers, you need a company_sizeuser property that was set consistently across your user base.

Identity Schema

The identity schema defines how you identify users across sessions, devices, and stages of their journey. It specifies what identifiers you use (email, user ID, anonymous ID), when you link identifiers together, and how you handle the transition from anonymous to known user.

A clear identity schema prevents the common problem of user fragmentation, where the same person appears as multiple users because their sessions were not properly linked.

Event Naming Conventions

Naming conventions are the foundation of a maintainable tracking plan. Without them, your event namespace becomes an unnavigable mess within months. With them, events are self-documenting and queries are intuitive.

The Object-Action Pattern

The most widely adopted convention is the Object-Action pattern. Events are named as a noun (the object) followed by a past-tense verb (the action): “Account Created,” “Order Completed,” “Feature Activated,” “Email Opened.”

This pattern works because it groups related events naturally. All account-related events start with “Account,” all order-related events start with “Order.” When you search for events, you can quickly find all actions related to a specific object.

Consistency matters more than which specific pattern you choose. A team using “Verb Noun” consistently will have better data than a team using “Object Action” inconsistently. Pick a pattern and enforce it rigorously.

Casing and Formatting

Choose a casing convention and apply it universally. The most common options are:

• Title Case with spaces: “Order Completed” - human-readable, common in consumer analytics tools
• snake_case: “order_completed” - database-friendly, common in engineering-driven organizations
• camelCase: “orderCompleted” - JavaScript-native, common in front-end implementations

KISSmetrics works well with Title Case event names, as they appear cleanly in reports and are easily readable by non-technical stakeholders. Whatever you choose, document it explicitly and reject any events that deviate from the standard.

Naming Anti-Patterns to Avoid

Several common naming mistakes create long-term problems:

• Overly generic names: “Click” or “Event” tells you nothing. Always be specific: “CTA Button Clicked” or “Navigation Link Clicked.”
• Embedding variable data in event names: “Purchased Blue Widget” creates an unbounded namespace. Use “Product Purchased” with aproduct_name property instead.
• Inconsistent tense: Mixing “User Signs Up” with “Order Completed” creates confusion. Stick to past tense for actions that have occurred.
• Platform-specific prefixes: “iOS_Order_Completed” embeds platform in the event name. Use a platform property instead so you can analyze cross-platform and per-platform in the same event stream.

Property Standards and Data Types

Properties provide the context that makes events analytically useful. A “Purchase Completed” event without properties tells you how many purchases occurred. The same event with revenue, product_category, and payment_methodproperties enables revenue analysis, category comparisons, and payment optimization. The quality of your properties determines the depth of your analysis.

Property Naming Conventions

Apply the same rigor to property names as to event names. Use snake_case for properties even if you use Title Case for events - this mirrors how properties will be stored in databases and queried in SQL. Be descriptive but concise: order_total_usd is better than total or order_total_amount_in_us_dollars_currency.

Use consistent suffixes to indicate units and types: _at for timestamps (created_at), _id for identifiers (order_id),_count for counts (items_count), _usd for currency (revenue_usd). These conventions make data types self-evident.

Data Types

Every property should have an explicit data type. The core types are:

• String: Text values like names, categories, and identifiers. Always specify expected values or patterns where possible.
• Number: Integers or decimals. Specify whether the number should be an integer or can include decimals, and note the expected range.
• Boolean: True/false values. Use for binary states likeis_first_purchase or used_coupon.
• Timestamp: Date and time values. Always specify the format (ISO 8601 is standard) and timezone handling.
• Array: Lists of values, typically strings or numbers. Useful for properties like product_ids in a cart.
• Object: Nested key-value structures. Use sparingly and only when the nesting is analytically meaningful.

Required vs. Optional Properties

Marking properties as required or optional has implementation consequences. Required properties should cause the event to fail validation if missing - this catches implementation errors early. Optional properties may be absent in some contexts without indicating an error.

Be conservative with required properties. If a property cannot always be known at the time the event fires, make it optional. It is better to have some events with missing optional properties than to have events fail to fire because a required property was unavailable.

Example Property Specification

A well-documented property in your tracking plan might look like this:

Property: order_total_usd
Type: Number (decimal, 2 decimal places)
Required: Yes
Description: Total order value in USD after discounts, before tax and shipping
Example: 149.99
Notes: Convert to USD at checkout time if original currency differs

User Identification Strategy

User identification is the most technically complex aspect of a tracking plan, and getting it wrong creates problems that are nearly impossible to fix retroactively. Your identification strategy determines whether you can track users across sessions, connect anonymous browsing to post-signup behavior, and build accurate retention and lifetime value analyses.

Anonymous vs. Known Users

Before a user signs up or logs in, they are anonymous. Your analytics tool assigns them a temporary identifier (often stored in a cookie or local storage). After authentication, they become known and are identified by a persistent identifier like a user ID or email.

The critical moment is the transition from anonymous to known. When a user signs up, you need to link their anonymous pre-signup activity to their new known identity. This is called identity resolution or aliasing. Without it, the same person appears as two separate users: one who browsed your site and one who signed up.

Choosing Your Primary Identifier

Your primary identifier should be:

• Unique: No two users should ever share the same identifier
• Persistent: The identifier should never change for a given user
• Available early: You should be able to identify the user as soon as they authenticate, not hours or days later

For most SaaS and e-commerce applications, the database user ID (a UUID or auto-increment integer) is the best primary identifier. Email addresses can work but cause problems if users change their email. External IDs from authentication providers work well when you use services like Auth0 or Firebase Auth.

Implementing Identity Resolution

In KISSmetrics, identity resolution is handled through the identify call. When a user signs up or logs in, you call identify with their permanent identifier. KISSmetrics automatically links all anonymous events from that session (and past sessions on the same device) to the known user.

// Before signup: anonymous events are tracked automatically
_kmq.push(['record', 'Pricing Page Viewed']);

// At signup: identify links anonymous history to user
_kmq.push(['identify', 'user_12345']);
_kmq.push(['record', 'Account Created']);

// All subsequent events are attributed to user_12345

Cross-Device Identity

The hardest identity problem is connecting the same user across multiple devices. A user might research on their phone, evaluate on their work laptop, and purchase from their home desktop. Without cross-device identity, this appears as three separate users.

The solution is to call identify every time the user authenticates on any device. When they log in on their phone, all phone activity links to their identity. When they log in on their laptop, all laptop activity links as well. Over time, a complete cross-device picture emerges.

SaaS Tracking Plan Example

A SaaS tracking plan centers on the subscription lifecycle: signup, onboarding, activation, engagement, upgrade, and churn. The following example covers the essential events for a typical B2B SaaS product. Use it as a starting template and customize for your specific product.

Core SaaS Events

EVENT: Account Created
Trigger: User completes signup form
Properties:
  - signup_method (string, required): "email", "google", "sso"
  - plan_type (string, required): "free", "trial", "paid"
  - referral_source (string, optional): UTM source or referrer
  - company_name (string, optional): If collected at signup

EVENT: Onboarding Step Completed
Trigger: User completes a step in the onboarding flow
Properties:
  - step_number (number, required): 1, 2, 3, etc.
  - step_name (string, required): "Connect Data Source", "Invite Team", etc.
  - time_spent_seconds (number, optional): Seconds on the step

EVENT: Feature Activated
Trigger: User uses a core feature for the first time
Properties:
  - feature_name (string, required): "Dashboard", "Reports", "Exports"
  - activation_day (number, required): Days since signup
  - context (string, optional): How they accessed the feature

EVENT: Subscription Started
Trigger: User converts from free/trial to paid
Properties:
  - plan_name (string, required): "Starter", "Growth", "Enterprise"
  - billing_cycle (string, required): "monthly", "annual"
  - mrr_usd (number, required): Monthly recurring revenue
  - trial_days (number, optional): Length of trial if applicable

EVENT: Subscription Canceled
Trigger: User cancels their subscription
Properties:
  - plan_name (string, required): Plan at time of cancellation
  - cancel_reason (string, optional): Reason if collected
  - mrr_lost_usd (number, required): MRR being churned
  - tenure_days (number, required): Days as paying customer

SaaS User Properties

USER PROPERTY: plan_type
Type: String
Values: "free", "trial", "starter", "growth", "enterprise"
Updated: On subscription change

USER PROPERTY: company_size
Type: String
Values: "1-10", "11-50", "51-200", "201-1000", "1000+"
Updated: At signup or profile update

USER PROPERTY: signup_date
Type: Timestamp (ISO 8601)
Updated: Once, at account creation

USER PROPERTY: activation_status
Type: String
Values: "not_activated", "activated"
Updated: When user completes activation event

USER PROPERTY: lifetime_value_usd
Type: Number
Updated: On each payment

E-commerce Tracking Plan Example

An e-commerce tracking plan follows the purchase funnel: product discovery, cart building, checkout, and post-purchase behavior. The following example covers essential events for online retail. Adapt the properties to match your catalog structure and checkout flow.

Core E-commerce Events

EVENT: Product Viewed
Trigger: User views a product detail page
Properties:
  - product_id (string, required): SKU or product identifier
  - product_name (string, required): Human-readable name
  - product_category (string, required): Primary category
  - price_usd (number, required): Current price
  - in_stock (boolean, required): Availability status

EVENT: Product Added to Cart
Trigger: User adds item to shopping cart
Properties:
  - product_id (string, required): SKU or product identifier
  - product_name (string, required): Human-readable name
  - quantity (number, required): Quantity added
  - price_usd (number, required): Unit price
  - cart_total_usd (number, required): New cart total

EVENT: Checkout Started
Trigger: User initiates checkout process
Properties:
  - cart_total_usd (number, required): Cart value
  - items_count (number, required): Number of items
  - has_coupon (boolean, required): Whether coupon applied
  - coupon_code (string, optional): Coupon if applied

EVENT: Payment Info Entered
Trigger: User completes payment information step
Properties:
  - payment_method (string, required): "credit_card", "paypal", "apple_pay"
  - cart_total_usd (number, required): Current cart value

EVENT: Order Completed
Trigger: Order is successfully placed
Properties:
  - order_id (string, required): Unique order identifier
  - order_total_usd (number, required): Final order value
  - items_count (number, required): Number of items
  - shipping_method (string, required): Selected shipping
  - payment_method (string, required): Payment type used
  - discount_usd (number, optional): Discount amount
  - is_first_order (boolean, required): First-time purchaser

EVENT: Order Refunded
Trigger: Full or partial refund is processed
Properties:
  - order_id (string, required): Original order ID
  - refund_amount_usd (number, required): Refund value
  - refund_reason (string, optional): Reason category
  - is_full_refund (boolean, required): Full vs partial

E-commerce User Properties

USER PROPERTY: customer_type
Type: String
Values: "prospect", "first_time_buyer", "repeat_customer"
Updated: On first and subsequent purchases

USER PROPERTY: total_orders
Type: Number
Updated: On each completed order

USER PROPERTY: lifetime_value_usd
Type: Number
Updated: On each completed order (cumulative)

USER PROPERTY: average_order_value_usd
Type: Number
Updated: On each completed order

USER PROPERTY: favorite_category
Type: String
Updated: Calculated based on purchase history

USER PROPERTY: days_since_last_order
Type: Number
Updated: Daily or on each session

Building Your Tracking Plan Step-by-Step

Building a tracking plan is a collaborative process that involves product managers, engineers, and analysts. Rushing this process leads to gaps and inconsistencies. Taking the time to do it right creates a foundation that serves your analytics for years.

Step 1: Define Business Questions

Start with the end in mind. What questions must your analytics answer? Common examples include: Where do users drop off in the signup funnel? Which features correlate with retention? What is the LTV by acquisition channel? Which user segments have the highest expansion potential?

Write these questions explicitly. Every event and property in your tracking plan should connect to at least one question. If you cannot explain how an event helps answer a business question, you probably do not need to track it.

Step 2: Map User Journeys

Visualize the paths users take through your product. For SaaS, this typically includes: marketing site visit, signup, onboarding, first core action (activation), regular usage, upgrade consideration, and renewal or churn. For e-commerce: discovery, browsing, cart building, checkout, and post-purchase.

At each stage, identify the key decision points. These are the moments that determine whether a user continues forward or drops off. Your tracking should illuminate these decision points clearly.

Step 3: Identify Key Events

For each stage of the journey, identify the actions worth tracking. Prioritize actions that represent decisions or meaningful engagement over passive behaviors. “Started Trial” matters more than “Visited Homepage.” “Created First Report” matters more than “Opened Settings Page.”

A common mistake is tracking too much. Every event has an implementation cost and adds noise to your data. Start with 20-30 core events that answer your most important questions. You can always add more later.

Step 4: Define Properties for Each Event

For each event, brainstorm the context needed for analysis. Ask: How will we segment this event? What dimensions matter for comparison? What details will analysts wish they had when querying this event?

Be specific about data types and expected values. Vague property definitions lead to inconsistent implementations. If plan_type should only contain “free,” “trial,” or “paid,” document those exact values.

Step 5: Establish and Document Naming Conventions

Before any implementation, formalize your naming conventions in writing. Create a section in your tracking plan that explicitly states the rules: event casing, property casing, word separator, tense conventions, and any prefixes or suffixes. Include examples.

Step 6: Create the Tracking Plan Document

The tracking plan itself should be a structured document, typically a spreadsheet. Each row represents an event. Columns include: event name, description, trigger, properties (with sub-rows for each property), property data types, required/optional status, and implementation notes.

Step 7: Review with All Stakeholders

Before implementation, review the tracking plan with everyone who will implement or use it. Engineers should validate that the triggers are technically feasible. Analysts should confirm that the events and properties enable the analyses they need. Product managers should verify that key user actions are covered.

Step 8: Implement and Validate

Implementation should follow the tracking plan exactly. After implementation, validate each event by triggering it manually and inspecting the payload. Verify that event names, properties, and data types match the specification. Catch discrepancies before they reach production.

Template and Tools

A tracking plan lives in a document that everyone can access, edit, and reference. While enterprise teams sometimes use dedicated tracking plan tools, most teams start with a well-structured spreadsheet. The spreadsheet approach works well because it is familiar, collaborative, and flexible.

Spreadsheet Template Structure

Your tracking plan spreadsheet should include these columns:

• Event Name: The exact name as it will appear in your analytics tool
• Category: Group events by lifecycle stage or product area
• Description: When this event fires and what it represents
• Trigger: The specific action or system event that causes it to fire
• Owner: The team responsible for this event (product, marketing, etc.)
• Status: Planned, implemented, validated, or deprecated

For properties, use sub-rows or a linked sheet with:

• Property Name: The exact key name
• Data Type: String, number, boolean, timestamp, array, object
• Required: Yes or no
• Description: What this property represents
• Example Values: Representative values for clarity

Using the Template

We recommend creating your tracking plan in Google Sheets or a similar collaborative spreadsheet tool. Structure it with one tab for the event index (all events listed with basic info) and separate tabs for detailed property specifications by category. Link events to their property details for easy navigation.

Keep the spreadsheet as the canonical source of truth. When engineers implement tracking, they reference this document. When analysts investigate data issues, they consult this document. When product managers request new tracking, they propose additions to this document.

Implementing in KISSmetrics

Once your tracking plan is defined, implementing it in KISSmetrics follows a consistent pattern. The JavaScript library and API endpoints map directly to the concepts in your plan: events, properties, user identification, and user properties.

Basic Event Tracking

Track events using the record method. The first argument is the event name (matching your tracking plan exactly). The second optional argument is an object containing properties.

// Track an event with properties
_kmq.push(['record', 'Order Completed', {
  'order_id': 'ORD-12345',
  'order_total_usd': 149.99,
  'items_count': 3,
  'payment_method': 'credit_card',
  'is_first_order': true
}]);

User Identification

Identify users when they sign up or log in. This links all anonymous activity to their identity and enables cross-session analysis.

// Identify user at login/signup
_kmq.push(['identify', 'user_12345']);

// Or identify by email
_kmq.push(['identify', 'customer@example.com']);

Setting User Properties

Set user properties using the set method. These properties persist on the user profile and can be used for segmentation and filtering.

// Set user properties
_kmq.push(['set', {
  'plan_type': 'growth',
  'company_size': '51-200',
  'signup_date': '2025-01-15T10:30:00Z',
  'lifetime_value_usd': 2499.00
}]);

Validating Implementation

After implementing, use the KISSmetrics Live view to verify events are firing correctly. Trigger each event in your tracking plan and confirm:

• The event name matches your tracking plan exactly
• All required properties are present
• Property values have the correct data types
• User identification is linking events correctly

Common Mistakes to Avoid

Even teams that create tracking plans often stumble on implementation. These are the most common mistakes we see, along with how to avoid them.

Mistake 1: Tracking Too Much, Too Soon

Teams often try to track every possible action from day one. This creates implementation burden, clutters the data, and makes it harder to find the events that matter. Start with the minimum set of events needed to answer your top five business questions. Expand from there based on actual analytical needs.

Mistake 2: Inconsistent Property Names Across Events

Using user_id in one event and userId in another creates join problems and confuses analysts. Define global properties that should be consistent across all events (like user identifiers, timestamps, and platform) and enforce identical naming.

Mistake 3: Embedding Data in Event Names

Creating events like “Viewed Blue Widget” and “Viewed Red Widget” instead of “Product Viewed” with a product_color property makes analysis impossible. The event namespace becomes unbounded, and you cannot query across product views. Always use properties for variable data.

Mistake 4: Not Documenting When Events Fire

An event named “Checkout Started” could mean when the user clicks the checkout button, when they reach the checkout page, or when they enter payment information. Without precise documentation, implementations will vary and data will be unreliable.

Mistake 5: Forgetting to Track Failures

Teams track successful actions but forget to track failures. “Payment Failed,” “Signup Error,” and “Feature Error” events provide crucial insight into user frustration and technical issues. Include failure events in your event tracking plan.

Mistake 6: Not Validating After Implementation

Assuming that implementation matches the tracking plan is dangerous. Always validate by triggering each event and inspecting the actual payload. Discrepancies caught in QA cost hours to fix; discrepancies discovered months later in a broken report cost weeks.

Key Takeaways

A tracking plan is the foundation of trustworthy analytics. It transforms event tracking from a chaotic collection of ad-hoc implementations into a systematic, documented, and maintainable practice. The time invested in creating and maintaining a tracking plan pays dividends in data quality, implementation speed, and analytical confidence.

The difference between teams that struggle with analytics and teams that thrive is rarely the tools they use. It is the discipline of their tracking. A tracking plan enforces that discipline from day one. Build yours today, and every analysis you run for years to come will benefit from cleaner, more consistent, more trustworthy data.

Ready to implement your tracking plan? Start your free trial of KISSmetrics and see how person-level analytics brings your tracking plan to life with actionable insights.