Skip to main content
Privacy

Consent and PII enforcement belongs at the collector, not the browser

Client-side consent gates and PII scrubbing are easy to bypass and easy to get wrong. Here is why leatmap enforces both server-side, at the collector, where the client cannot reach.

The leatmap team2 min read
A dark server rack with neatly bundled cabling, lit by a cool indicator light.

Almost every analytics SDK enforces consent and strips personal data in the browser. It is the obvious place to put it: the data is right there, the SDK is already running, and shipping a config flag feels like enough.

It is not enough. The browser is the one place you do not control.

The browser is the wrong trust boundary

When consent checks and PII scrubbing live in client code, three things follow:

  • They can be bypassed. Anything in the browser can be inspected, blocked, or replayed. A flag that says "do not track" is a suggestion, not a guarantee.
  • They are fragile. A botched deploy, a race between the consent banner and the first event, or a third-party script can leak data before the scrub ever runs.
  • They are inconsistent. Every SDK version, every browser, and every ad blocker behaves a little differently, so the rules you wrote are applied unevenly across your traffic.

You end up trusting the least trustworthy part of the stack to enforce your most sensitive policy.

Move the rule to where the data lands

leatmap enforces consent and PII rules server-side, at the collector. The browser SDK sends events. The collector decides what is allowed to be stored, and it decides before anything is written.

That single change fixes the trust problem:

  • Consent state is evaluated at ingest, so an event that should not be kept is never kept. The client cannot opt itself back in.
  • PII rules run before storage, not after. Fields you have not allowed do not make it into the event stream in the first place.
  • The policy is applied once, consistently, to every event from every client, regardless of SDK version or browser quirks.

Erasure that produces a real artifact

Server-side enforcement also makes deletion tractable. On Business, personally identifying fields are kept in a separate vault keyed to your tenant. A single call erases a subject across the entire event stream and writes an immutable audit-log entry. That entry is the thing a regulator actually asks for, and it exists because the data was governed at the collector, not scattered through client code.

What you give up: nothing that matters

Teams worry that server-side enforcement means losing flexibility. In practice you lose only the failure modes. You still define your own consent model and your own PII rules. You just stop relying on the browser to honor them.

The browser collects. The collector decides. That is the right order.

Read more about how the platform is built privacy-first on the pricing page, or see how we keep all of this EU-resident by default.

Stop measuring with crossed fingers.

Get a tracking plan you can trust, a collector that enforces it, and a dashboard you actually want to open.