Privacy is a product decision, not a settings page

A lot of analytics products treat privacy as a compliance layer: collect everything, then add consent banners, retention settings, and anonymization toggles on top. I think that gets the architecture backwards. If the privacy story lives in settings, it's one misconfiguration away from not existing. Tracely's approach is to make the privacy properties structural — things the product can't do, not things it's currently configured not to do.

Cookieless by construction

Tracely sets no cookies and stores no client-side identifier for tracking. Visitor identity in storage is a hash derived from IP, user agent, and site — computed in memory at ingest, never stored raw. There's no cross-site identifier because there's nothing that could serve as one: the hash is scoped to a single site, so the same person visiting two Tracely-tracked sites produces two unrelated values. A cross-site ad graph isn't a feature we decline to enable; it's a query the data model can't answer.

The same goes for geography: IP is used in memory to resolve coarse location, then discarded. What lands in a pageview row is aggregate-friendly by the time it lands.

Non-goals, in writing

The more important half of the posture is what Tracely deliberately doesn't build. The documentation keeps an explicit product boundary — not marketing copy, an actual table of out-of-scope data classes — and the top of the list is:

• No session replay. No DOM or video-style playback, no mutation logs, no serialized HTML to reconstruct what a visitor saw. Heatmaps exist, but as binned grid aggregates — a 40×40 click grid, not a recording of anyone's session.
• No fingerprinting. No stable device fingerprints across unrelated sites, no high-surveillance signals like keystroke logging or raw clipboard contents.
• No form contents. Form analytics use labels and field IDs, never what anyone typed.

These aren't just policy — they're enforced twice. The tracker applies property limits, blocked key fragments, and depth and size caps before data leaves the browser, and the server applies the same filtering again at ingest, so replay-shaped payloads aren't retained even if someone tries to send them. Writing the non-goals down publicly matters too: it means a procurement or legal review can evaluate what the product is, and it means I can't quietly drift across the line later without contradicting my own docs.

The subtle one: small cohorts

Cookieless and aggregate-first handle the obvious risks. The subtler one is that aggregates themselves can leak when they get small. "Visitors from Liechtenstein on Firefox who read the pricing page: 1" is an aggregate in name only — if you know one person matching that description, the dashboard just told you what they read.

Tracely's answer is small-cohort masking. Any per-row count in a breakdown table that is strictly between zero and a threshold renders as an em dash (—) instead of a number. The threshold defaults to 5, is configurable via TRACELY_SMALL_COHORT_THRESHOLD, and setting it to 0 disables masking entirely for deployments that don't want it.

The "strictly between" wording is doing real work:

• Zero still shows as 0. Absence isn't identifying, and "no traffic" is an answer dashboards should give plainly.
• 1 through 4 show as —. These are the rows where a count is small enough to be a person.
• 5 and up show normally.

The masking applies across breakdown rows — sources, pages, technology, countries, events, campaigns, entry and exit pages, and the rest — because those are exactly the tables where slicing gets narrow. It deliberately does not apply to whole-site headline totals on Overview: your site's total pageview count isn't a sparse cohort, and masking it would be theater. The logic lives in one small class (PrivacySafeCount) and one Blade component, so every dashboard renders counts through the same rule rather than each table reimplementing its own idea of "too small."

Is a display-layer mask a complete defense against inference? No — and I won't pretend otherwise. It's one honest layer: the UI alone can no longer hand someone a row that says "this one person did this thing."

Why this framing matters

Every one of these decisions cost something. Session replay is a checkbox on competitors' comparison pages. Fingerprinting would make visitor counts more precise. Masked cells occasionally hide a number a customer legitimately wants to see. Taking the costs is what makes it a product decision rather than a slogan — a settings page can be flipped back; a data model can't.

The customer-facing summary of all this lives at /privacy, and the fuller technical boundary — the non-goals table, the enforcement points — is on /trust. If you're comparing against tools that lead with replay-style capture, that's the page to send your legal team.