Web Analytics

I want to know which parts of this site are actually interesting, and what's driving traffic to it. That's it — not behavioral profiling, not ad targeting, just "which pages, from where."

The constraint: self-hosted, or it doesn't count

Everything else here — self-hosted fonts, no third-party embeds, its own Forgejo/GoToSocial instances — exists specifically to avoid sending visitor data to companies that have no reason to have it. Cloud-hosted analytics (including cloud Plausible) would undo that for the one thing that watches every page load. So: self-hosted, full stop.

"Privacy-friendly" is doing a lot of marketing work

Worth being precise about this rather than repeating the tagline: tools in this category (Plausible, GoatCounter, Umami) still process IP, User-Agent, referrer, and page path per visit — that's still personal data being handled, just briefly. The way they avoid cookies is usually a daily-rotating salted hash of IP + User-Agent + domain, producing an ephemeral "unique visitor" count with no persisted identifier. That's real and meaningfully better than cross-site, cookie-based tracking — no third-party sharing, no long-lived ID, nothing correlated across other sites. But it's not "no tracking happens." Self-hosting solves where the data goes, not whether collection is happening. Both matter; they're not the same claim.

The options considered

Plausible — the default answer in this space, and the one this site's own Privacy Policy explicitly ruled out before this note existed. Self-hostable, but requires ClickHouse alongside Postgres. ClickHouse is a columnar OLAP database — built for aggregating huge event volumes fast, which is exactly an analytics dashboard's query shape, but it doesn't scale down: even a minimal install wants several GB of RAM as a baseline, sized for workloads far bigger than a personal site generates. On infrastructure where every service's memory is already being actively budgeted, that's disproportionate to the actual data volume involved.

Umami — dodges the ClickHouse problem (Postgres or MySQL instead), similar cookie-less design. Ruled out for a more personal reason: it's a Node/TypeScript stack, and a single self-contained binary fits this project's self-hosting taste a lot better than a Node app with its own dependency tree to keep patched.

Matomo — the mature, full-featured option, also Postgres/MySQL-backed. Worth naming as the honest counter-example to the "privacy-friendly" framing above: out of the box it does much more than Plausible/GoatCounter/Umami — session data, optional fingerprinting, heatmap/session-replay add-ons. It only becomes privacy-light if you deliberately disable most of what it ships with. Not a default-safe choice the way the others are.

PostHog (self-hosted) — ruled out early. Full product-analytics suite, session replay available, more invasive by default posture than this needed. Wrong direction.

GoatCounter — landed here. Single self-contained Go binary, SQLite by default, packaged in nixpkgs (pkgs/by-name/go/goatcounter/package.nix), so it's a normal NixOS service module rather than a Docker Compose stack. Built by one developer with privacy stated as a design constraint, not a marketing layer — and unlike a claim in a README, this one has a track record: v2.5.0 (2023) removed raw User-Agent storage in favor of parsed browser/OS only, v2.6.0 (2024) stopped storing individual pageviews by default. The direction of travel is toward storing less, not more. The dashboard UI is dated-looking (server-rendered, not a modern SPA — accessibility was the stated priority over visual polish) but still actively released: v2.7.0 shipped December 2025.

Where this actually stands

Still a seedling — the decision is made, the infrastructure side (does chiba have the headroom, what the NixOS module looks like) isn't done yet. This note exists because writing down why GoatCounter and not the others felt worth doing before the implementation details push the reasoning out of memory.