What happens to a request before anything is written
The collector is the only component that ever sees an IP address, and it is written so that seeing one is transient.
- The IP is hashed with a daily-rotating salt and the original is discarded in the same function. Nothing downstream, not ClickHouse, not Postgres, not a log line, receives it.
- Salts are scoped per project and per day, so two hashes cannot be joined to prove the same person visited two tenants, or the same site on two days.
- Geography is resolved in-process from a local MaxMind database. No lookup leaves your network, and it degrades gracefully to no geography rather than falling back to a hosted service.
- Company identification uses the autonomous system the request arrived on, not personal data. Consumer ISPs and hosting providers are filtered out, so a visitor at home is never labelled with their broadband provider.
- PII masking is applied at ingest to the URL, path, referrer, title and both the parsed and verbatim property payloads, under per-project rules.
- Consent is enforced server-side. An opt-in batch arriving without consent is refused by the collector, and the explicit decision is logged.
A tracker that collects less than it could
Several of these are decisions to not collect something that would have been useful.
- Form values
- Never captured, at any setting. The tracker records that a form was submitted and which form it was, never what was typed into it.
- Cookieless mode
- A session-scoped identifier held in memory. Nothing is persisted to the device, so there is no storage to disclose or consent to.
- Do Not Track & GPC
- Both respected, and configurable. A visitor signalling either is not collected from.
- Session replay
- Deliberately not implemented. Recording somebody's screen is a far larger commitment than counting their clicks; the extension point is left open for deployments that decide otherwise.
- Third-party requests
- None. The script is served from your own subdomain and posts to your own collector.
- Size
- 2,943 bytes gzipped, zero dependencies, small enough to read the whole thing before you put it on your site.
Export and erasure that are jobs, not promises
A GDPR feature that exists as a support email is not a feature. Falorb models data requests as rows and processes them with a worker that runs every two minutes.
The dashboard also generates a privacy disclosure for each property from its real configuration (the retention window, the identity scope and the consent mode actually in force) rather than from a template somebody filled in once.
What Falorb will not do
Stated in the repository, not just on a marketing page.
Cross-site tracking of sites you do not own is not implemented and will not be. It requires third-party cookies, dead in modern browsers, persistent fingerprinting, or purchased data-broker profiles, and it is unlawful under GDPR and ePrivacy without a consent that this kind of collection never genuinely obtains.
Everything Falorb knows derives from first-party activity on properties you operate. Anonymous visitors are never joined across domains. Identity unifies only on a deterministic signal: the same identify() id on both properties, or a click through a decorated link between two of your own domains.
The integrations design carries the same boundary forward: nothing that ships personal data to an ad network for cross-site retargeting is planned, because it would reintroduce through a side door exactly the tracking the platform deliberately does not do.
Privacy, in practice
Do I need a cookie banner to use Falorb?
That depends on your jurisdiction and your configuration, and a software vendor is the wrong party to give you a legal answer. What is true technically: in cookieless mode nothing is persisted on the visitor's device at all, which removes the storage-access basis for a consent requirement in most readings of the ePrivacy Directive. In its default mode Falorb uses a first-party identifier, no third-party cookies, and stores no IP address. Many self-hosted deployments run cookieless and drop the banner; that decision is still yours to take with your own advice.
Where does the data physically live?
On the machines you run. Falorb has no cloud component, no telemetry back to a vendor and no outbound connection other than the ones you configure yourself: an email provider for alerts, a Slack webhook if you add one. If you deploy it on a server in Frankfurt, the personal data stays in Frankfurt, which is a materially simpler transfer story than any hosted analytics product can offer.
What exactly is stored about a visitor?
The events they generated, a daily-rotating hash of their IP scoped to that project, a device identifier, coarse geography from a local GeoIP database, parsed user-agent facts, and whatever you deliberately attach with identify() or track(). Not stored: the raw IP, form field values, anything from a third-party cookie, and anything about their activity on sites you do not operate.
How does erasure work?
A data request creates a job. Erasure cascades through both ClickHouse and Postgres and tombstones the profile so a later event cannot silently resurrect the person. Export produces the full profile and its event history. Both run in the background rather than blocking a request, and the worker that processes them runs every two minutes.
Why is cross-site tracking refused rather than optional?
Because there is no lawful, durable way to build it. It requires third-party cookies, which modern browsers have removed, persistent fingerprinting, or purchased data-broker profiles, and under GDPR and ePrivacy it needs consent that this kind of collection never actually obtains. Shipping it as an option would mean shipping a feature whose honest documentation is a warning. It is documented in the repository as permanently out of scope.
This page describes how the software behaves. It is not legal advice, and no analytics tool can make you compliant on its own: that depends on what you collect, why, and what you tell your visitors. The quickstart covers the settings referred to here.
Analytics that does not need a data-processing agreement
Because there is no processor. It runs on your machines, and the personal data never leaves them.