Event schema enforcement
A schema only protects data quality if something enforces it. Enforcement validates each event against the declared schema and decides what happens on failure — reject, drop a field, or quarantine. It can run in CI against instrumentation, in the SDK, or at the collection boundary. This page explains where to enforce an event schema and the trade-offs of each point.
Where enforcement can live
Schema checks can run at several points. In CI, a linter compares instrumentation against the tracking plan and fails the build on undeclared events. In the SDK, a wrapper validates before sending so bad events never leave the client. At the collection boundary, the server validates every event regardless of source. Each catches a different class of problem, and they compose.
The boundary is the backstop because it sees every event no matter which client or third party produced it.
- CI: catches undeclared events before release
- SDK: blocks bad events before they are sent
- Boundary: validates everything, the backstop
Failure policy without data loss
Decide deliberately what failure means: hard reject for malformed events, field-level dropping for an unexpected extra property, or quarantine to a side store for events worth inspecting. Always emit a rejection metric so a spike is visible — a silent drop hides a regression. Be careful that strict enforcement does not discard a new but legitimate event mid-rollout; coordinate schema changes with deploys.
Enforcement is the muscle behind tracking plans and data contracts; without it they are advisory.
How it appears in analytics and logs
Events with unexpected names or types reaching reports mean the schema is documented but not enforced anywhere in the path.
Diagnostic use case
Make an event schema actually hold by enforcing it at CI, SDK, or the boundary, instead of trusting every emitter to comply.
What WebmasterID can help detect
WebmasterID validates events at its server boundary, so the stored set conforms to the expected shape rather than whatever clients sent.
Common mistakes
- Documenting a schema but enforcing it nowhere.
- Silently dropping failures with no metric.
- Rejecting a legitimate new event because the schema lagged the deploy.
Privacy and accuracy notes
Enforcement can block events carrying disallowed personal data before storage. This page is educational, not legal advice.
Related pages
- Data contracts for events
A data contract is a versioned, machine-checkable agreement between the team that emits an event and the teams that consume it, fixing field names, types, semantics, and compatibility rules. Unlike a wiki page, it is enforced in CI or at the boundary, so a producer cannot ship a breaking change unnoticed. This page explains data contracts and how they protect analytics from upstream drift.
- Server-side event validation
Server-side collection gives one place to validate every event before it is stored or forwarded. Checks fall into shape (does it match the tracking plan), type (are values the right kind), and plausibility (is the sequence possible). Rejecting or quarantining failures keeps malformed and fabricated data out of downstream tables. This page describes how server-side event validation gates an analytics pipeline.
- Semantic versioning for events
Semantic versioning gives event schemas a shared vocabulary for change: a major bump means a breaking change, minor means a backward-compatible addition, patch means a fix that does not alter shape. Tagging events and their schemas this way tells consumers whether an upgrade is safe to ignore or requires work. This page maps semver to event-schema changes and how it coordinates producers and consumers.
- Events documentation
Define the schema enforcement validates against.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.