What we capture, and everything we deliberately do not.

There is no session recording, no screen capture, no video, and no copy of your pages' content. Not as a policy we could quietly change: there is nothing in the product that could take one. No screenshot is taken, no page markup is copied, and no canvas or font fingerprint is read.

What a form contributes is how many characters were typed and how long it took — never the characters. Text reaches us only from the label of something a visitor actually interacted with: a button's name, a link's text. Before it is stored, anything that looks like an email address, a phone number or a run of four or more digits is removed.

We do not read your visitors' cookies, we do not use third-party storage, and we store no user ID of any kind.

Consent is a gate, not a checkbox we record. Before your visitor grants permission, the tag makes no request, writes no storage, and attaches no listener. Nothing is buffered waiting for a yes — there is nothing to leak and nothing to be compelled to hand over.

If behaviour arrives without a verifiable grant it is rejected outright, not stored and flagged. If your visitor withdraws, the queue is dropped rather than sent, and their identifier is deleted.

There are exactly two permissions, and they are separate on purpose:

Measure

Be measured on this site. This is the ordinary grant, and it is all that a consent banner can ever give us.

Recognise

Be recognised across your own other domains and devices. Never implied, never inferred. A consent-management platform cannot grant it, because no standard purpose means it. Asking to be recognised without agreeing to be measured is refused — there would be nothing to recognise anyone in.

Your visitor's IP address arrives with the request, as it must for any request on the internet. We shorten it — IPv4 to a /24, IPv6 to a /64 — before looking anything up, use the shortened value to resolve a country and a first-level region, and then discard it. There is no IP column in any table, and the lookup is an offline read of a database file inside our own server: the address is never sent anywhere.

Location is a country code and a region. Never a city, never coordinates, never a postcode. The record also says which source answered, so two different spellings of the same region are never quietly treated as two places.

One residual, stated rather than hidden: Google Cloud, which runs our servers, keeps its own request log, and that log holds the connecting address for 30 days. It is not ours, nothing in our product reads it, and no address from it ever reaches a stored row — but it exists, and a page that said “no log anywhere holds an address” would be wrong.

No identifier we create can follow a visitor to another company's website. Not “we choose not to” — no such field exists. The value that recognises a returning visitor is first-party and scoped to your site alone.

Two values can cross a boundary. Both are confined to your own domains, both require the separate Recognise permission, and neither is read by any feature today:

• A hand-off token when a visitor moves between your own domains: signed by our server, never by the public script on your page, valid for five minutes, and single-use — copy it into another browser and the second use is refused.
• An optional identity pivot you can supply: hashed in the browser before it leaves the page, then hashed again on our side with a secret only we hold. The original value never reaches us and cannot be produced by us on demand. If the secret is not configured, nothing is stored rather than something weaker.

Because of this we count sessions, not people — and every rate in the product shows the denominator it was measured over. We would rather show you a smaller honest number than a bigger invented one.

Tenant separation is not application logic that a bug could bypass. Every tenant-scoped table carries a row-level security policy, and the policy is forced — it applies to the table owner too. An application defect cannot read across customers, because the database refuses the query. An audit checks every one of those tables on every release and fails the build if one is unprotected or unforced.

The API that serves your data is not on the internet. It has no public address; only our own services inside a private network can reach it. Passwords are hashed with argon2id, and a password reset genuinely invalidates every session that was already signed in. Secrets live in Google Secret Manager and never in our source code.

Everything that stores data is in the European Union — Belgium: the collector that receives behaviour, the raw-event store, the database, the cache and the pipeline. Adding our tag adds no third party to your capture path.

We use five sub-processors. Two of them receive personal data and both are in the United States, so they are covered by Standard Contractual Clauses in our Data Processing Agreement.

If you connect Google Analytics 4 or Microsoft Clarity, those remain your tools under your arrangements. We read the aggregates you already had; connecting them adds no new company to your own list.

The current list is always this page. We give notice before it changes — see the DPA.

A single visitor’s data can be deleted on request. You resolve your visitor to their identifier — it is readable in their own browser storage and the tag exposes it for exactly this purpose — and we delete every row it identifies, including the rows they arrived on from another of your domains. You receive a receipt recording what was deleted, when, and by whom. The receipt stores a one-way hash of the identifier, not the identifier.

And when we cannot do it, we say so instead of issuing a receipt. Very recently captured rows sit in a write buffer that cannot be deleted for up to about 90 minutes. In that window the request returns a failure that tells you when to retry, and no receipt is written. A receipt claiming an erasure that did not happen would be worse than the delay — so the product refuses to produce one.

Raw behavioural data is held for 400 days and then dropped. The deletion is a metadata operation on a whole day’s partition — it does not even create a database job. This is also the honest limit on what the product can recalculate: change a rule today and history re-derives, but only as far back as 400 days.

1. Behaviour captured before your visitor consented does not exist, so there is nothing to delete. Where a grant arrives mid-visit, the earlier moments were never attached to any identifier. They cannot be erased because they cannot be linked to anybody — which is the point, not an excuse.
2. A deletion in our raw store is queued, not instant. The receipt records when it completed, not when it was asked for.
3. Database backups age out on their own schedule. We keep 7 automatic backups and 7 days of transaction logs for point-in-time recovery, in the EU. A row deleted today is gone from the live database immediately and leaves those backups as they expire.
4. Google Cloud's own request log holds connecting IP addresses for 30 days, as described above.

We hold no SOC 2 report, no ISO 27001 certificate, and no independent penetration test. We are not going to imply otherwise on the page where we ask you to trust us.

The honest position is: we built it right and nobody has certified it yet. That is a real gap, and it is a different kind of gap from a product that captured too much and now has to be rewritten — this product cannot leak what it never collected. If a certification is a requirement for you, tell us; it is money and calendar time, and a named requirement is what starts it.