Cookieless web analytics with no cookie banner required
A tracking snippet under 2 KB counts visitors without ever setting a cookie. Sessions are worked out server-side using a hash that rotates once every 24 hours, so there's no persistent identifier to disclose in the first place.
The banner is the tool's fault, not the law's
A cookie consent banner exists because the analytics script writes something to the visitor's browser and reads it back later — a cookie, a fingerprint, some identifier that persists. That's what most consent frameworks are built to catch. Reject the banner and the analytics tool loses the visitor; accept it grudgingly and the numbers are already skewed toward whoever didn't bother to click "decline."
The alternative isn't a smaller cookie or a shorter expiry. It's not writing one at all.
A snippet under 2 KB
The tracking script that goes on a page is under 2 KB — small enough that it doesn't touch page-load performance in any way a Core Web Vitals check would notice. It fires a pageview, captures the referrer and any UTM parameters, and reads the visitor's country and device type from the request. It doesn't set a cookie, doesn't fingerprint the browser, and doesn't load anything from a third-party domain.
Live visitors, goals and events
A live-visitor count updates as people move through the site right now — useful during a launch or a campaign send when you want to watch traffic arrive in real time rather than wait for tomorrow's report. Beyond raw pageviews, goals and events track the actions that actually matter: a form submit, a signup, a download, a scroll past the fold — whatever counts as success for a given page.
Conversion and revenue attribution, back to the post that sent it
Because every link WDIBoard publishes gets a UTM tag automatically, a click that arrives from a scheduled social post is identifiable in analytics as coming from that specific post, not just "social" as a channel. Conversion and revenue attribution carries that through to the outcome — which post, which click, which conversion, which value. That loop, from a scheduled post to the traffic and revenue it produced, is the specific thing that's impossible when scheduling and analytics are two unconnected tools. More on how the two pillars share a workspace on the website suite.
Per-brand dashboards, CSV export, and public shared links
Analytics data sits under the same workspace → brand hierarchy as everything else, so a dashboard for one client brand never shows another client's traffic. Any dataset exports as CSV for further analysis or for pasting into a client's own spreadsheet. Dashboards can also be shared publicly — a link that opens without the recipient logging in — for a client who wants to check numbers between formal reports, or for a report that's meant to be public.
How the daily-rotating hash works
This is the actual mechanism the whole page is about, so it's worth explaining properly rather than waving at it.
-
A visitor loads a page
The under-2 KB snippet fires a single request to the analytics endpoint. Nothing is written to the browser — no cookie, no localStorage entry, nothing that survives a page reload on its own.
-
The server computes a session hash
On the server, request details such as the visitor's IP address and user-agent string are combined with a salt value and run through a hash function. The result is a short string that identifies "this visitor, today" without storing anything identifiable in the raw.
-
The salt rotates once every 24 hours
That's the part that matters. The salt used in the hash changes on a daily rotation. Every visit from the same person on the same day produces the same hash, so repeat pageviews correctly collapse into one session and one visitor count — the numbers stay accurate within a day.
-
The next day, the same visitor produces a different hash
Because the salt has changed, the same IP address and user-agent produce a completely unrelated hash tomorrow. There is no calculation that links yesterday's hash to today's — nothing to reverse, nothing to correlate. A "new visitor today" genuinely can't be matched back to "the same person yesterday" from this data.
-
The result: no cookie, no persistent identifier
Nothing is stored in the browser, and nothing computed on the server survives past its own day in a form that identifies an individual across time. That's the literal definition of "no persistent identifier," not a marketing description of one.
Cookie consent banners are generally required because of the cookie or persistent identifier itself — that's what most frameworks are built to detect and regulate. A design that sets neither removes that specific trigger. That's a description of how the mechanism works, not a legal conclusion: confirm your own consent-banner obligations with your own legal advisers, since other tools or cookies elsewhere on the same site can change the answer for the site as a whole.
Who this is for
Agencies who don't want to add a cookie banner to a client's site just to get traffic numbers, or who are tired of watching consent-rejection rates eat into their data. Site owners who want honest pageview and conversion numbers without running a script that fingerprints visitors to work around a rejected cookie. Developers who care that the tracking snippet is small enough not to show up in a performance audit.
Frequently asked questions
Does cookieless analytics mean I don't need a cookie banner?
The analytics itself sets no cookie and stores no persistent identifier, which removes the specific trigger most consent-banner requirements are built around. Whether a given site needs a banner depends on everything else running on it and on your own reading of your obligations — check with your own legal adviser, this isn't legal advice.
How do you count a visitor without a cookie?
A session hash is computed server-side from request details combined with a salt that rotates every 24 hours. Repeat visits on the same day produce the same hash, so they correctly collapse into one visitor and one session. The next day the salt changes, so the same person produces an unrelated hash — accurate within a day, unlinkable across days.
Can I see returning visitors across multiple days?
Not as an identified individual across days — that's the same design choice that removes the persistent identifier. You get accurate daily and aggregate visitor counts, referrers, goals and conversions, just not a cross-day profile of one specific person.
What data does the snippet actually collect?
Pageviews, referrers, UTM parameters, country and device type, plus whatever goals or events you configure. No cookie is set and no third-party script is loaded.
Does it track conversions and revenue, or just traffic?
Both. Goals and events cover on-site actions, and conversion and revenue attribution connects a click through to its outcome — including tracing traffic back to the specific UTM-tagged social post that sent it.
Can I export the data or share it with a client?
Yes. Any dataset exports as CSV, and dashboards can be shared publicly via a link that opens without the recipient needing to log in.
How is this different from a cookie-based analytics tool?
Cookie-based analytics tools set an identifier in the browser to recognise the same visitor across visits and days, which is what triggers consent-banner requirements in most frameworks. This design never writes that identifier, which is a real architectural difference, not just a smaller cookie.
See your traffic without adding a cookie banner
Get early access — a sub-2 KB snippet, no cookie, no persistent identifier.
Get early access