0%
Public Dashboard

Analytics

I run two analytics services side by side: Umami Cloud (the public dashboard embedded below) and Cloudflare Web Analytics (private dashboard at Cloudflare). Both are cookieless and IP-anonymised. See the privacy page for the full list of what's collected.

Dashboard pending

The public Umami share URL has not been wired up yet. Enable "Share URL" in the site's Umami settings, then paste the resulting https://cloud.umami.is/share/… URL into src/_data/site.js under analytics.umamiShareUrl.

In the meantime, what gets tracked is documented in full at /privacy/#analytics: cookieless, IP-anonymised, no personal identifiers, GDPR-compliant.

What's tracked

  • Page URL.
  • Referrer (which page or external site sent you here).
  • Device category (desktop, mobile, tablet).
  • Browser family.
  • Country (derived from a hashed, anonymised IP — never stored raw).

What's not tracked

  • No cookies.
  • No persistent visitor identifier.
  • No raw IP addresses.
  • No user accounts, no email addresses, no profile data.
  • No fingerprinting.
  • No third-party advertising or marketing pixels.

How to opt out

Block cloud.umami.is + api-gateway.umami.dev (Umami) and static.cloudflareinsights.com (Cloudflare) in your browser, ad blocker, or DNS resolver. Most of the major content blockers (uBlock Origin, Pi-hole, Brave) block all three by default. The site continues to work normally without any of them.

Custom events

Beyond page views, I track a small set of custom events to see how readers actually use the archive — which downloads land, which works finish, which sharing channels carry. None of these record anything personal.

  • download.work — per-work TXT / JSON / BibTeX / RIS download. Properties: slug, format.
  • download.volume — per-volume ZIP or Markdown bundle. Properties: volume, format.
  • download.corpus — full Conway Edition ZIP or Markdown bundle. Properties: format.
  • share.click — share-block click. Properties: network (x / linkedin / email / copy), path.
  • cite.copy — cite-dialog copy-citation button. Properties: style (apa / mla / chicago / bibtex), slug.
  • identifier.copy — stable identifier copied on /works/<slug>/history/. Properties: slug.
  • reader.open — work page opened. Properties: slug, path, title, volume, kind.
  • reader.finished — reader scrolled past 95 % of a work. Properties: slug, path, title, volume, kind.
  • reader.print — reader hit Print or Cmd+P. Properties: path.
  • setting.change — reader-panel preference (theme, font, ruler, etc.) changed. Properties: key, value.
  • start.step — reader on /start-here/ clicked one of the five numbered step links. Properties: step (1–5), slug, href. Powers the Start-here funnel.
  • volume.open — landed on a /works/volume-N/ page. Properties: volume, path. Pairs with download.volume in a funnel.
  • works.hub.open — landed on the /works/ hub. Pairs with download.corpus in a funnel.

The implementation is a single ~150-line script at /assets/js/analytics.js. It loads only when Umami loads, so blocking cloud.umami.is blocks the events too.

Why two services

Cloudflare Web Analytics is bundled with the host that already serves the site, so it costs nothing extra and gives me an operational view (latency, error rate, request paths) Umami doesn't surface. Umami gives me the public dashboard the privacy page promises. Together they let me see how the site is doing without storing anything personal.

Why publish this

If you can see what I see, you can hold me to the privacy promises on /privacy/. The dashboard makes "no personal data" verifiable, not just claimed.

Link copied