Edge-native event schema validation

Make your events conform.

Sits in front of your event collection — GA4, Adobe Analytics, Snowplow, Mixpanel, custom — watching traffic, writing its own validation rules, telling developers in real time what values their events should have, and stopping bad tracking from ever reaching your warehouse.

page_view purchase add_to_cart form_submit user_engagement + any custom event

The problems Conform actually solves

Tracking quality is a structural problem, not a "if everyone just paid more attention" problem. Conform makes the schema executable so the system enforces it, not the data team.

The problem
How Conform solves it
Impossible to police a schema across multiple development teams with human review alone.

Even with the best intentions, hand-coordinating tag conventions across web, mobile, growth, and product teams breaks down past about 5 engineers.

The schema is executable.

Every event is validated at the edge against the same JSON Schema, regardless of which team wrote the tag, on which platform, in which sprint. The schema is the law and the gateway is the court.

Auditing existing GA4 / Adobe tracking takes weeks of warehouse spelunking.

"What does our purchase event actually look like in production?" requires SQL across millions of rows, spotting outliers, reconciling shapes — and the answer goes stale the day after.

Conform infers it from live traffic in a day.

Per-parameter presence ratios, value distributions, format detection, distinct-value enumeration — generated automatically and proposed as a PR you can review and merge. Audit becomes a Git workflow.

Tracking lives in tribal knowledge.

The canonical event spec is split across stale Confluence pages, GTM screenshots, BI team tickets, the data engineer's head, and a Notion doc nobody updates. Drift is guaranteed.

One JSON Schema in Git is the single source of truth.

Reviewable, diffable, version-controlled, enforced. Documentation that can't drift from reality because reality is checked against it on every event.

Tracking changes can't be unit-tested.

Code has tests, types, lint, code review. Tracking has "fire it and see if it appears in DebugView." Bad tags ship through clean CI all the time.

CI runs validators against your tracking before merge.

Schema changes go through PR with structure + bump-kind validation. Proposed tracking changes can be exercised against the same validators that run in production. Bad tracking fails the build.

Tracking errors are only visible AFTER they reach production.

A developer ships a tag change. Customers fire it. An analyst spots weird numbers days or weeks later. By then, real production data has been miscounted, downstream models retrained on it, dashboards are showing wrong figures, and stakeholders made decisions on the back of them.

Issues surface in dev, staging, and CI — long before production.

The debug client surfaces validation failures in the developer's browser console as they fire events locally. CI runs the same validators against tracking PRs. The production edge is the third safety net, not the first. Bugs caught in the session they're written, by the person who wrote them.

When a bug does slip through, you can't trace it.

Bad numbers in a dashboard with no Git-blame for analytics. Which deploy caused it? Which tag? Which team? Reconstructing the cause from warehouse data takes hours of forensics.

Every rejected event carries its full forensic trail.

The bad-events archive captures the original request, the parsed event, the validation errors, the cf-ray ID, headers, and timestamp. "Which PR caused this" goes from a quarter-long investigation to a single grep.

Vendor validators are too late.

Looker, dbt, your warehouse — they all validate after the row has been written. By the time you know currency contains "pounds", that row is in production data and downstream models are training on it.

Validation upstream of the warehouse.

Conform sits between the browser and your GTM server-side container. Invalid events are caught and quarantined before they ever reach storage. Your warehouse only sees clean data.

Cross-platform drift.

Web, iOS, Android each implement the same event slightly differently. The warehouse has to reconcile three flavours of purchase, none of which quite match the spec.

One schema, all platforms.

The same JSON Schema applies regardless of which client fires the event. Mobile drift surfaces as validation errors with the same reporting and same surfacing as web — visible immediately, fixable at source.

The data team becomes the tracking police.

Instead of doing analysis, they spend cycles chasing engineers to fix bad tracking, opening tickets, hand-cleaning data, explaining for the fifth time why currency matters.

The system polices tracking.

The data team sees only events that have already passed validation. Bad data is the engineer's problem, not the analyst's, and it surfaces in the engineer's tooling not the analyst's dashboard.

How it works

One CNAME change. Three modes per event. Zero changes to your existing GTM container or downstream tools.

  1. 1

    Point your collector at the gateway

    Whatever you use today — GA4 + GTM ss, Adobe Launch + AEP, Snowplow collector, a custom endpoint — change one URL so events flow through Conform first. Browser → Conform → your collector → your warehouse. The gateway is invisible to the browser and to your downstream stack.

  2. 2

    Let it learn

    Conform observes real production traffic and proposes a JSON Schema for every event it sees. After a day of traffic, you get a pull request with an inferred schema, evidence-backed: presence ratios, value ranges, format detection (UUIDs, currencies, dates).

  3. 3

    Promote to enforcement

    Review and merge the schema. Events that pass continue to your warehouse unchanged. Events that fail get logged with full context for debugging and — when you're ready — rejected at the edge so they never enter your downstream stack.

Why teams choose Conform

🪄

You don't write the schemas

Conform watches your traffic for a day and proposes a JSON Schema for every event it sees — required fields, value enums, numeric ranges, format detection, all evidence-backed. You review the PR, edit if you want, merge. Focus on the real problems, not on documenting page_view.

💬

Real-time fixes in the developer's console

When a tag fires an invalid event, the developer sees it in their browser DevTools as it happens — with the recommended value for the broken field. Bugs caught by the person who shipped them, in the session they shipped them, before the next deploy.

🚧

CI blocks bad tracking before merge

Schemas live in Git with PR-based review. CI validates every change: structure, naming, SchemaVer bump correctness — you can't tighten a constraint without bumping the model digit. Tracking changes that would produce events your validators reject fail the build, just like any other broken test.

🤖

AI needs clean data — and a clean spec

Garbage in, garbage out. Models, attribution, dashboards, RAG pipelines — only as good as the events they feed on. Conform delivers two things to your AI stack: validated events into the warehouse, AND a machine-readable JSON Schema your semantic layer (dbt, Cube, LookML, MCP servers) can consume directly. The same schema that validates purchase also tells your AI what purchase.value means — half your semantic layer, generated for free.

🛡️

Three modes, one per environment

Learning — observe real traffic and infer a starter-for-ten schema, proposed as a PR. Use it on any event you haven't documented yet.

Warning — for dev and staging. Validate against the schema, surface failures in DevTools, but always forward. Nothing breaks while you iterate.

Strict — for production. Invalid events are rejected at the edge before they reach your warehouse. The schema is the contract; if it doesn't match, it doesn't ship.

Each event walks the ladder at its own pace, never globally.

📚

Documentation that can't go stale

The schema is the spec. New developers can see exactly what events exist, what shapes they take, and what every field means — by reading one file. Because the schema is enforced on every event, the docs and the live data can't drift apart. The documentation is always current, by definition.

For the AI era

Models trained on "pounds" instead of "GBP" produce broken predictions.

Pipelines that crash on a malformed transaction_id burn engineering hours.

Dashboards built on missing required fields lie to the people deciding the budget.

Conform catches all of them at the edge — before they hit the warehouse, the training data, the dashboard.

Where it sits

A drop-in intercept on the path you already use. The gateway is upstream of your GTM server-side container — your existing tag fan-out, transformations, and downstream destinations don't change.

1
App / browserFires an analytics event
→
2
ConformParse → resolve schema → validate → forward (or drop)
→
3
Your collectorGTM ss / Adobe / Snowplow / custom
→
4
Warehouse / GA / dashboardsClean, validated data
What happens inside Conform
// On every event:
1. Parse the wire format (today: GA4 /g/collect; Adobe + Snowplow next)
2. Resolve schema by event name from the manifest
3. If no schema → forward + observe (learning mode)
4. If schema → validate against versioned JSON Schema
5. On pass  → forward to your collector, emit metric
6. On fail  → queue full payload to bad-events archive
              + emit metric
              + (if strict) DROP, else forward
7. Always return 200 to the client — never 4xx the browser

What it's like to use

No new dashboard to live in, no new vendor to learn. Conform shows up in the tools your team already uses every day.

Your rules live with your code

Validation rules sit in your Git repo, just like the rest of your codebase. Changes go through pull requests, get reviewed by humans, ship through your normal release process. No vendor portal to log into, no proprietary config UI, no surprises when someone changes something.

Schemas write themselves

You don't need to know what your events look like before you start. Watch a day of real traffic and Conform proposes a schema for every event it sees — what fields appear, what shapes they take, what values are typical — ready for you to review and merge.

Every failure is captured for you

When an event fails validation, Conform keeps the full story: what was sent, what was wrong, when, and from where. Investigate any incident from the past 30 days in seconds. Nothing is ever silently lost.

Two safety nets, always on

Kill switch: turn Conform into a transparent pass-through in seconds if anything ever feels wrong. Events keep flowing exactly as before, validation stops. Shadow mode: deploy strict rules without ever blocking real traffic — test enforcement on live data first, then turn it on when you're confident.

Nothing to install, nothing to scale

Conform runs on a global network milliseconds from your visitors anywhere in the world. There are no servers to size, no infrastructure to manage, no scaling decisions to make. Whether you fire 10,000 events a day or 100 million, it just works.

Drops in next to what you have

Conform doesn't replace your tag manager, your collector, or your analytics destination — it sits in front of them. Everything you have today keeps working exactly as it does. Add Conform with one config change; remove it later just as easily if you change your mind.

Want to see it on your stack?

A 20-minute demo, no commitment. We'll point Conform at a test stream of your real traffic and show you the inferred schemas + the validation errors it surfaces.

Prefer email? hello@conversion-works.co.uk