Privacy & data handling

Every request that reaches the ingest service carries an IP address, as every HTTP request does. Coruve uses it for exactly two things, in the same function that receives it, and then discards it: it resolves the address to a coarse country, region and city, and it mixes the address into the one-way daily visitor identifier described below. The address itself is never written anywhere. There is no IP field in the event schema at all, so there is no column for one to be written into by accident later, and nothing stored can be turned back into an address — the identifier is a SHA-256 digest that also contains a secret only Coruve's servers hold, and it is discarded and rebuilt from scratch every day.

The tracker takes your project ID, the browser's user-agent string, its language, its timezone offset and today's date, joins them, and hashes the result with SHA-256 in the browser. Two facts fall out of that recipe. Because today's date is in the input, the identifier changes at midnight every day on its own — there is no expiry to configure and no cleanup job that could fail to run. And because your project ID is in the input, the same browser visiting two different Coruve customers produces two unrelated hashes, so nobody can be followed from one site to another.

SHA-256( projectId | userAgent | language | timezoneOffset | YYYY-MM-DD )

What the browser sends is never what is stored. On arrival the server builds the identifier again, adding two things the browser cannot know: a secret derived from Coruve's own key and today's date, and the network address the request came from — trimmed to its network block for IPv6, so a phone rotating its address stays one visitor. Neither is kept. The secret is recomputed each day from a key that never leaves Coruve's infrastructure, and the address is used here and in the geography lookup and then discarded. So an attacker holding the event store cannot reproduce an identifier from a browser they control, cannot recover an address from one, and cannot link yesterday's identifiers to today's. Session identifiers are salted on the server the same way.

SHA-256( projectId | HMAC(secret, "anon-daily:" + YYYY-MM-DD) | browserHash | networkBlock )

Without it, the recipe above contains nothing that distinguishes one device from another — only the browser's user agent, its language and its timezone. Two different people on the same browser build, in the same language and timezone, produced the same identifier and were counted as one person. That undercounted visitors, most severely on audiences that are alike: one company, one country, one browser. Adding the coarse network address separates them without storing anything new, and without a cookie, a device fingerprint or a persistent identifier of any kind. The trade is stated below.

A returning visitor on a different day counts as a new visitor. That is the trade Coruve makes on purpose, and it is why the retention report is measured in weekly cohorts rather than by following individuals. Anyone offering both daily-unique visitors and long-term individual tracking is keeping a persistent identifier somewhere.

The network address separates two devices on two networks, and it cannot separate two devices on ONE. Two people in one household, or two colleagues behind one office address, running the same browser build in the same language and timezone, still produce the same identifier for that day and are counted as one. People sharing one network and one browser set-up may still be counted once per day, so this can undercount. For IPv6 the address is trimmed to its network block on purpose — a phone that rotates its address during the day would otherwise become several visitors, which is the same error pointing the other way. This is the same limit Plausible and Fathom publish, and it is a much smaller one than the browser-only recipe had. We are telling you which way the number errs because a limit you cannot see is one you would otherwise mistake for precision.

Not a first-party cookie, not a session cookie, not one that expires quickly. There is no call to document.cookie in the tracker. That is what puts Coruve outside the consent-banner requirement for analytics in most jurisdictions — but whether YOUR site needs a banner depends on everything else your site loads, and that is a question for your own counsel, not for this page.

Four keys, one per project, and none of them identifies a person. Three are written for an ordinary visitor; the fourth is a flag you set on your own browser, deliberately, and no visitor ever has. Everything else the tracker knows lives only for the length of a page view. The tracker no longer uses sessionStorage at all.

offlineBuffer: false in your snippet is the whole switch, and it is honest rather than partial: the buffer is cleared and never written again, the session id falls back to living in memory for the length of a tab, and the capture switches fall back to the compiled defaults on every page load rather than being cached. A site that set it stores nothing persistent on a visitor's device at all — which is the claim the option exists to make true, so it cannot be allowed to acquire a fourth key silently. Your own exclude-my-visits flag is the exception and is not governed by it, because it is not a visitor's key: it is set by your own deliberate action on your own browser.

Coruve.init("proj_YOUR_ID", {
  apiHost: "https://ingest.coruve.com",
  offlineBuffer: false,
});

When the browser sends Do Not Track, or when Global Privacy Control is set, the tracker stops before it captures anything. There is no reduced mode and no anonymised mode — no page view, no event, no request to the ingest endpoint. Both signals are checked at initialisation and again on every capture, so a signal that appears mid-session is honoured mid-session.

Coruve.init("proj_YOUR_ID", {
  apiHost: "https://ingest.coruve.com",
  // respectDNT is true by default. Setting it to false is a decision
  // you would have to make deliberately, and we do not recommend it.
});

No canvas rendering, no WebGL probing, no font enumeration, no audio-context fingerprinting, no battery or hardware interrogation. The identifier's whole input is listed above — user agent, language, timezone offset — and that is deliberately weak entropy, because a strong fingerprint is exactly the persistent identifier this design exists to avoid.

Coruve does not record sessions, does not capture the screen, and does not observe what is typed. The Click & scroll maps are built from click coordinates and scroll depths on a grid — there is no image of your page anywhere in the system, which is why the report is not called a heatmap.

For clicks on interactive elements, Coruve stores what was clicked as a structural descriptor — the tag, its id and its classes — and where it was clicked. Whether the element's text and its aria-label are read at all is a switch, and since tracker 1.4.0 it lives in Project Settings → Tracking rather than in your snippet: a project created from 1.4.0 onwards starts with it ON, and a project that existed before 1.4.0 starts with it OFF and is asked once before anything changes. The one unconditional veto is writing collectText: false in your own snippet — an explicit false there is never overruled by a dashboard switch. Whenever it is on, anything matching a personal-data pattern is redacted before it leaves the browser, the words are used to write a name and are then dropped — the row written to the event store carries the structural descriptor and nothing else, and there is no column for the text to be written into. Whenever it is off, the two fields that carry the text are deleted at ingest before the job that would process them is even created, which is a stronger promise than not storing them: they do not reach the worker at all. Clicks on non-interactive parts of the page, the ones that feed the click map, have no branch that can carry text at all: a click can land on a paragraph of prose, and there is no code path in which that prose is read.

Since tracker 1.4.0 a form submission is recorded by default, so this page has to say what that means rather than leave the impression that forms are untouched. What is recorded is that a form was sent, the form's structural descriptor, the path its action points at, and HOW MANY fields it had. Never a field's name and never a field's value: Coruve counts the fields, it does not read them. Nothing typed into a form reaches Coruve on this path or any other — there is no keystroke observation anywhere in the tracker, and an input, a textarea and a select are the three element types the text capture refuses to read from even when it is switched on.

Put data-coruve-ignore on any element and nothing inside it produces an event of any kind — no click, no dead click, no form submission, no text. It is checked FIRST in both listeners, before the project's own settings are consulted, deliberately: a customer's suppression of their own markup must not be conditional on ours. On <body> it makes a page report its page view and nothing more. Every serious tracker ships one of these; this is the spelling of ours.

What Coruve is allowed to record is six on/off switches in Project Settings → Tracking: form submissions, outbound links, file downloads, contact links, using the words on buttons to name them, and counting #anchors as pages. Two properties make them worth calling a privacy control rather than a preference. First, a switch stops COLLECTION — it is not a read-time filter over data that is still being written, so there is nothing to un-hide later. Second, the five that govern what a row CONTAINS are enforced at ingest, server-side, on the way in: what a switch forbids is refused or deleted before the row is queued, whatever the browser tracker believes it is allowed to send. The tracker's copy of the switches only decides what leaves the page, which is the cheaper and more private half, never the authoritative one. (The sixth, counting #anchors as pages, is not a collection switch at all — it changes the URL a page view is reported under, so there is nothing at ingest for it to strip.) Turning a switch off takes effect on your visitors' next page view; what you already collected stays and keeps counting, and the change is marked on your charts so a step in a number has a reason beside it.

Your plan's retention is stamped onto every event row at the moment it is written, and the event store's own time-to-live rule deletes the row when the window closes. It is not a filter over data that is still there — the row is gone. Which also means upgrading does not recover data that has already passed its window.

You do not have to wait for the clock. Project Settings → Privacy & data has an Erase history control: name a date and every event recorded before it is deleted, scoped to that project alone. It is the workspace OWNER's decision and nobody else's — an admin can change what is counted, only the owner can destroy what was — and a date in the future is refused, because erasing everything is what deleting the project is for and that asks you to type the name first. The confirmation says 'queued' rather than 'deleted' on purpose: the event store applies the deletion asynchronously, so reports can take a few hours to settle, and a past-tense claim that is still briefly false is not a sentence this page will print.

The Coruve application and its Postgres database — your account, your projects, your goals, your billing records — run on Railway in Amsterdam. Your visitors' analytics events live somewhere else entirely: a ClickHouse instance Coruve operates itself, on dedicated infrastructure in Frankfurt. Both sit in the EU, and the separation is still the point: the behavioural data is held in a store Coruve runs on its own machine, not alongside your account in a managed platform.

Raw developer event names like btn_submit_final_v2 are sent in batches to Anthropic's Claude, together with the draft label Coruve's own heuristics produced, and it suggests a readable name and a category. Only the names and the drafts go — no properties, no visitor identifiers, no page URLs. Suggestions stay pending until you approve them.

The Brief's cards, the Explain panel and Ask each put one sentence over numbers a deterministic engine already computed. The model is shown that computed answer — the metric name, the figures, the date window, and the row labels those figures belong to, which for a report about pages means page paths and for one about events means event names. It is shown nothing beyond what is already rendered on your screen underneath the sentence, and its output is checked against the answer before it is displayed. If the model is unavailable, a template sentence renders and not one number changes.

Visitor identifiers, session identifiers, IP-derived location for an individual visit, your custom event properties, the text of a question you asked Ask, any note you wrote, your project id, your account, your organisation, and any row belonging to another project. Row labels crossing this boundary are treated as untrusted text and length-bounded on the way out — anyone can cause a name to be recorded on a website, so a name is never read as an instruction.

This page explains how the system is built. Where the wording matters legally, these are authoritative: the privacy notice, the data processing addendum, and the cookie notice.