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 event schema 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.

The newsletter

Join our KISS newsletter

One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.

No spam. Unsubscribe in one click.

Event Schema examples

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

Further Reading

KISSmetrics

Build your business intelligence layer for free.

KISSmetrics reads your site, infers the event structure and implements it, then shows you the schema so you can correct anything it got wrong.