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.
Three layers of checks
A server boundary lets you validate consistently regardless of which client sent the event. Shape validation confirms the event name and required parameters exist and match the tracking plan. Type validation confirms each value is the expected kind and within range. Plausibility validation confirms the event makes sense in sequence — a purchase after an add-to-cart, a geography the audience could have.
Doing this once, server-side, is more reliable than hoping every client validates itself.
- Shape: required name and parameters present
- Type: values are the right kind and range
- Plausibility: the event fits a possible sequence
What to do with failures
Decide per failure whether to reject outright, drop the offending field, or route the event to a quarantine/dead-letter store for inspection. Quarantining preserves evidence of a tagging regression without polluting trusted tables. Emit a metric for rejection rate so a sudden spike pages someone, because it usually means a release broke instrumentation or someone is injecting.
Validation is the enforcement point where the tracking plan, data contracts, and PII rules actually bite.
How it appears in analytics and logs
A rise in rejected or quarantined events at the boundary signals a broken tag, a schema change, or injection — surfaced before it reaches reports.
Diagnostic use case
Catch malformed, mistyped, or implausible events at the collection endpoint before they corrupt reports or trigger downstream errors.
What WebmasterID can help detect
WebmasterID validates first-party events at its server boundary, so the stored total reflects events that passed shape and plausibility checks.
Common mistakes
- Trusting clients to validate their own events.
- Silently dropping failures instead of measuring them.
- Discarding bad events with no quarantine for inspection.
Privacy and accuracy notes
Validation can also enforce that disallowed PII never enters storage. This page is educational, not legal advice.
Related pages
- 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.
- Dead-letter queue for events
When an event cannot be processed — it fails validation, throws in a transform, or repeatedly errors — a dead-letter queue (DLQ) holds it instead of discarding it. The DLQ preserves the data for inspection and replay, and its depth is a live signal that something upstream broke. This page explains how a dead-letter queue protects analytics completeness and surfaces failures.
- Fake event protection
Fabricated events reach analytics through the Measurement Protocol, replayed beacons, or scripted bots. Because collection endpoints accept well-formed requests by default, defense relies on validation: allow-listing hostnames, checking event shape, and flagging implausible patterns. This page describes layered protections that keep fake events out of trusted totals without claiming any single control is foolproof.
- Event Explorer
Inspect events that pass and fail validation.
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.