Analytics

Analytics implementation follows the rule in Privacy-first runtime: measure broad site usage without shipping a tracking script, setting cookies, or building visitor profiles.

Current implementation#

The sites currently report pageviews to Umami from the server side through the Cloudflare Worker. No analytics script ships to the browser.

The Worker owns the boundary between the request and the analytics service. That makes analytics a server-side integration rather than a browser-side dependency.

The pageview path contains only the URL pathname, never the query string. A same-site referrer is reduced to its pathname; an external referrer is reduced to its origin. The Worker also truncates the visitor IP address before the request leaves the Cloudflare runtime.

Implementation rules#

• keep the browser free of analytics scripts, pixels, and tracking cookies
• send only the fields needed for aggregate reporting
• avoid form content, full query strings, and personal data
• keep event names stable and documented
• test analytics dispatch through Worker tests when behaviour changes

npm run test:worker intercepts the outbound analytics request and verifies path and referrer minimization, IP-address truncation, and deferred dispatch through waitUntil().

Acceptable metrics#

Essential metrics are enough: pageviews, top referrers, paths, device classes, and broad trends. A question that requires visitor-level tracking to answer is out of scope.

Review triggers#

Review the implementation when changing the Worker, analytics endpoint, event payload, consent posture, or third-party disclosure inventory.

The public privacy rule stays in governance. This page documents the current mechanism.