A small beacon batches a fixed set of events from the public site and posts them to a first-party endpoint. Session ids are random per-tab strings; there are no cookies and no personal data. Events are capped and clamped per batch so the endpoint cannot be used to spam the table, unrecognised event names are dropped, and the endpoint always returns success so analytics can never break a page.
Also called: website traffic · who visits my site · page views · site analytics · no cookie banner
- 1The beacon batches events and posts them, at most 25 per request
- 2Only a known set of event names is accepted: page view, click, form submit, scroll 25/50/75/100, outbound, time on page
- 3Each row records path, referrer, UTM parameters and device class — phone, tablet or desktop
- 4Session and visitor ids are random per-tab strings, never a person
- 5Always returns 204 — 'analytics must never break a page'
Knowing which page a builder read before he picked up the phone is the difference between spending an ad budget and guessing with it, but the usual answer is a third-party tag that ad blockers strip, a cookie banner everyone dismisses, and a pile of personal data collected on people who never asked to be followed. Page views, clicks, form submissions, scroll depth, outbound clicks and time on page are collected first-party instead, with no cookies and nothing that identifies a person; the session marker is a random string that dies with the tab. Because nothing is loaded from somebody else's script, the numbers survive the blockers that strip the usual tags — and the collection can never break a page or slow it down.
- Third-party analytics tags are blocked and under-report traffic
- Cookie-based tracking creates a consent obligation
- A failing analytics call can break page rendering
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 →