Analytics
Website analytics without cookies
Sessions, funnels, and campaign attribution, identified by a server-side hash instead of a browser cookie, with nothing stored before a visitor identifies.
How it works
How cookieless identification works.
No cookie jar, no client-side identifier planted on first visit. Just a hash computed where the request lands.
Anonymous visitors are identified by a gfh_ hash computed on the server from the incoming request, not a value a script writes into the browser. There's no cookie to accept, block, or expire, because there's no cookie in the first place.
Nothing about a visitor is stored before they identify themselves, whether that's a signup, a login, or a form submission. There's also no fingerprinting library reading canvas, fonts, or device signals to reconstruct an identity when a cookie isn't available. See how this fits into the rest of our approach on the security page.
The one exception: if you click to consent or opt out, we store a small local flag so we can remember that choice. Nothing else touches your browser before you sign up.
The honest tradeoff: recognizing the same anonymous visitor across devices, or across a long gap between visits before they've identified themselves, is weaker than what cookie-based tracking can do. That's the deliberate trade for not tracking anyone before they've told us who they are. Once someone identifies, their history attaches to one profile and stays there.
Still included
What you still get.
Dropping cookies doesn't mean dropping the reporting. See how the core metrics stack up against a cookie-based tool like Google Analytics.
Sessions and session streams
Every visit lands as a session, with the page path, referrer, and event stream attached, so you can watch a real visit unfold without a cookie backing it.
Funnels
Define a funnel across pages or events and see where a session drops off. Funnel math runs on session and event data, not on a persistent client id.
Referrers and campaign attribution
Source, medium, and campaign parameters are read from the request and the landing URL, so referrer and campaign reporting works the same as it would with cookies.
Per-person profiles after identify
The moment someone signs up, logs in, or fills out a form, their prior sessions attach to a single profile. Identity starts there, not before.
Boundaries
What we never store.
The short list, stated plainly. Full detail lives on our privacy page.
01
No third-party cookies
Nothing is planted in the browser to read back on a later visit. The gfh_ hash is computed on the server, per request, and never written to a cookie jar.
02
No persistent client id before consent
There is no long-lived identifier tied to a visitor until they identify themselves. Before that point, there is nothing to look up and nothing to link across visits.
03
No device fingerprint
We don't read canvas, font lists, audio context, or battery state to reconstruct an identity when a cookie isn't available. If it isn't a cookie, it isn't a fingerprint either.
04
No data sold or shared
Session and event data is used to run your analytics and your account, full stop. It isn't sold, shared with ad networks, or used to build a profile outside your project.
Our own site
The banner story.
Our own marketing site runs a single-dismiss notice that reads "Never mind. No cookies." It isn't a consent wall with an accept button and a preferences panel, because there's nothing to consent to for analytics: no cookie is set, no persistent id is created, and nothing is stored before a visitor identifies themselves. Dismiss it once and it's gone.
That's the same default every GetFluxly project starts with. For a full walkthrough of where this lands under GDPR, read our GDPR-compliant analytics page.
See it running on your site.
Add the source, watch sessions and funnels arrive cookieless, and decide for yourself whether you still need a banner.
FAQ
Questions, answered.
Do I need a cookie consent banner with GetFluxly?
For analytics-only tracking, most teams don't. Nothing is stored before a visitor identifies themselves, there's no persistent client-side id, and there's no fingerprinting, so there's nothing to ask consent for. See the full breakdown on the GDPR page and check your own obligations if the page runs other trackers too.
What is the gfh_ id and where does it come from?
It's a hash computed on the server from the incoming request, not a value read from or written to a browser cookie. It lets us group events into a session without planting anything client-side.
Does cookieless mean less accurate?
Within a session, no. Across devices, or recognizing a returning visitor weeks later before they've identified themselves, yes, that's weaker than cookie-based tracking. That's a deliberate trade: we'd rather not track someone before they've said who they are.
Can I still see funnels and campaign attribution without cookies?
Yes. Funnels, referrers, and campaign attribution all run on session and event data, which cookieless mode still captures in full. What you lose is long-window, pre-identify recognition of the same anonymous visitor, not the core reporting.
How does this compare to Google Analytics?
GA4 sets a persistent client id and typically needs a consent banner to do it. GetFluxly's default tracking doesn't set that id, so most teams skip the banner for analytics traffic. See the full comparison on our Google Analytics alternative page.