What is an Event Validation?

Why Event Validation Matters

Event validation is the practice of checking that analytics events conform to their defined schema before the data reaches your warehouse. Without validation, bad data flows silently into your pipeline. A misspelled property name, a string where a number is expected, a missing required field: none of these cause errors in the application itself, so they go unnoticed until someone queries the data and gets unexpected results.

The cost of invalid event data compounds over time. Every day that bad data flows into your warehouse is a day of analysis you cannot trust. Backfilling corrected data is expensive and sometimes impossible, especially when the original context (which user, which session, which variant) cannot be reconstructed. Validation at the source prevents this by catching problems when they are cheapest to fix: before the code is merged.

Validation also builds team confidence in the data. When product managers know that every event has been validated against the event schema, they trust the dashboards built on that data. When engineers know that CI will catch schema violations, they can refactor tracking code without fear of silent breakage. Validation is the foundation of data quality.

How It Works in Practice

There are two main approaches to event validation: compile-time (static) validation and runtime validation. They serve different purposes and work best when used together.

Compile-time validation uses your event schema to generate type definitions for your tracking code. A tool like the Ordaze Scanner reads your schema and checks that every tracking call in your codebase matches the expected event name, property names, and property types. This runs in CI on every pull request, so violations are caught before code is merged. The key advantage is zero runtime overhead: the validation happens at build time, not in the user's browser or app.

Runtime validation checks events as they are sent from the application. This catches issues that static analysis cannot, such as dynamic property values that depend on user input or server responses. Runtime validation typically involves a middleware layer in your event pipeline that compares each event payload against the schema and either logs a warning, drops the event, or sends it to a dead-letter queue for review. The tradeoff is added latency and the risk of dropping valid events if the schema is too strict.

Common Mistakes

• Validating only event names and ignoring properties. Most data quality issues live in the properties, not the event name. A checkout_completed event that fires correctly but sends total as a string instead of a number will break every revenue calculation. Validation must cover property names, types, and required/optional status.
• Running validation only in production. By the time invalid events appear in production, the damage is done. Shift validation left into CI and local development so problems are caught before deployment. Production monitoring should be a safety net, not the primary defense.
• Using overly strict runtime validation that drops events. Dropping events in production means losing data permanently. A better approach is to flag or quarantine invalid events so they can be reviewed without data loss. Reserve strict blocking for CI where the cost of rejection is a failed build, not lost data.
• Treating validation as a one-time setup. Schemas evolve as the product changes. Validation rules must be updated alongside the schema, and the schema must be updated alongside the product. If any link in that chain breaks, drift begins.

Frequently Asked Questions

What is the difference between static and runtime validation?

Static validation analyzes your source code at build time and checks that every tracking call matches the schema. It runs in CI with no production overhead. Runtime validation checks event payloads as they are sent from the live application, catching issues that depend on dynamic values or server state. Static validation prevents most schema violations from reaching production. Runtime validation catches the edge cases that static analysis misses. Use both for complete coverage.

What should I validate on every event?

At minimum, validate the event name (does it exist in the schema?), required properties (are they all present?), property types (is price a number, not a string?), and allowed values for enum properties (is payment_method one of the defined options?). For type safety, also validate that no unexpected extra properties are being sent, which often indicates a copy-paste error or an event that was not properly defined in the schema.

How do I automate event validation?

The most effective approach is to integrate validation into your CI pipeline. Tools like the Ordaze Scanner run as a step in your build process and compare your tracking code against the schema. This means every pull request is automatically checked for schema violations before it can be merged. For runtime validation, add a middleware layer to your event pipeline that checks payloads against the schema and routes invalid events to a monitoring queue. The CI step catches structural issues; the runtime step catches value-level issues.