A self-hosted analytics script and a matching ingest endpoint. It generates a random per-tab session id and a random persistent visitor id, classifies the device, captures UTM and click identifiers from the URL, and batches nine event types to the platform. Everything is wrapped in try/catch and the endpoint always answers 204, so nothing about analytics can affect the page or the visitor.
Also called: website analytics · no cookies analytics · traffic tracking · who visits my site
- 1A random session id lives in sessionStorage; a random visitor id lives in localStorage. Neither is a cookie and neither is ever joined to an account.
- 2Events are queued and flushed in batches of up to 25, using sendBeacon when the page is going away.
- 3The endpoint whitelists nine event names, clamps every string length, and inserts what survives.
- 4Blocked storage degrades to counting views rather than people, instead of failing.
- 5The panel rolls the raw events into traffic, channels, funnel and per-page aggregates.
The design rules are stated at the top of the beacon: "No cookies, no PII, no third parties: a random per-tab session id, page views, scroll depth, outbound clicks, and any element carrying data-evt. Failures are silent — analytics must never break the page." The privacy position is documented in the migration too: it is "exactly the 'first-party usage analytics' the published Privacy Policy §11 permits, and nothing here identifies a person."
- Third-party analytics required consent banners and gave little that was actionable.
- Behaviour data lived in a separate tool from search data.
- An analytics failure could break a marketing page.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →