Event Schema

A structured definition of all tracked events in an analytics system, specifying each event's name, required and optional properties, data types, and allowed values.

Also known as: tracking schema, event specification, tracking plan

Why It Matters

An event schema is the contract between your engineering team and your analytics consumers. Without it, developers make ad hoc tracking decisions that result in inconsistent event names, missing properties, and data that is impossible to analyze reliably.

A well-defined schema prevents the most common analytics problems before they happen. It ensures that "purchase_completed" is never accidentally tracked as "Purchase Completed" or "purchase-completed" in different parts of the codebase. It specifies which properties are required versus optional, and what data types each property should contain.

The schema also serves as documentation. When a new analyst joins the team, the event schema tells them exactly what data is available, what each event means, and what properties they can use for filtering and segmentation. Without this documentation, onboarding new team members requires expensive tribal knowledge transfer.

Industry Applications

E-commerce

A marketplace creates a comprehensive event schema with 45 core events covering the full purchase lifecycle. The schema includes standardized product properties (SKU, category, price, brand) that enable consistent analysis across all product pages and checkout flows.

SaaS

A collaboration platform maintains a versioned event schema in their git repository. When a developer needs to add tracking for a new feature, they submit a schema change as a pull request that must be reviewed by both engineering and analytics before merge.

How to Track in KISSmetrics

Define your event schema before implementing tracking in KISSmetrics. Document each event with its trigger condition, required properties, optional properties, and example payloads. Use KISSmetrics event management to enforce naming standards and monitor for unexpected events that deviate from the schema.

Common Mistakes

  • -Starting tracking without a schema and trying to retroactively document what you already have
  • -Making the schema so complex that developers avoid adding new events because the process is too burdensome
  • -Not versioning the schema, making it impossible to know when event definitions changed
  • -Defining events from the engineering perspective (button_clicked) rather than the business perspective (item_added_to_cart)
  • -Not including trigger conditions - the same event name can mean different things if the conditions are ambiguous

Pro Tips

  • +Name events as verb phrases that describe business actions: "subscription_started," "report_generated," "team_member_invited"
  • +Include trigger conditions in your schema: "fires when a user completes checkout, not when they click the buy button"
  • +Use a schema validation tool or linter in your CI pipeline to catch tracking errors before they reach production
  • +Review and update your schema quarterly, deprecating events that are no longer relevant and adding new ones as the product evolves
  • +Keep a changelog for your event schema so analysts know when definitions changed and can account for it in historical analysis

Related Terms

See Event Schema in action

KISSmetrics tracks every user across sessions and devices so you can measure what matters. Start free - no credit card required.