You can track every visitor, session, and conversion on your site without setting a single cookie, and without a consent banner getting in the way. This guide walks through exactly how it works and how to set it up in minutes.
The short answer
Modern privacy-first analytics tools track visitors using a temporary, salted hash instead of a stored cookie. The hash is built from things like the visitor's IP address, user agent, and date, then rotated daily so no individual can be identified or followed across days. No cookie file ever touches the browser, so there's nothing to store, nothing for a browser to block, and nothing that legally requires a consent banner under GDPR or ePrivacy rules.
That's the whole trick. You still get accurate visitor counts, session data, referrers, and conversion tracking. You just lose the ability to stalk one person across months, which you probably didn't need anyway.
Why cookies aren't necessary in the first place
Google Analytics leans on cookies because it was built for long-term audience profiling: remarketing lists, cross-session identity, ad attribution across properties. Most site owners don't need any of that. You need to know:
- How many people visited today and where they came from.
- Which pages convert and which ones leak visitors.
- Whether a marketing campaign paid off, not who clicked it personally.
None of that requires identifying a specific returning human being. It just requires counting sessions accurately, which cookieless methods do just fine.
Method 1: Rotating salted hashes (the standard approach)
This is what most privacy-focused analytics platforms, including Pelagic, use under the hood.
- A visitor loads your page. The tracking script fires once, collecting the IP, user agent, and site domain.
- The server hashes those values together with a daily salt. The salt changes every 24 hours, so the same visitor generates a different hash tomorrow.
- The hash becomes a temporary session ID. It's enough to tell "this is one session" apart from "this is a different session," but it can't be reversed to reveal an IP or matched across days.
- The IP itself is discarded, not stored, not logged, not retained anywhere.
The result: you get real session counts and real uniques for the day, without a persistent identifier ever existing.
Method 2: Server-side aggregation
Some setups skip client-side scripts almost entirely and count visits from server logs or edge functions. A request hits your server or CDN, gets logged with basic metadata (URL, referrer, device type), and gets aggregated into totals. No script runs in the browser at all in the strictest versions of this.
It's more work to build yourself and it doesn't give you the JS-based events (button clicks, form submits, revenue events) that most founders actually want. That's why most teams use method 1 with a lightweight script instead of building raw log parsing from scratch.
Method 3: First-party, event-based tracking
This is really a layer on top of method 1. Instead of just counting pageviews, you fire custom events for things that matter to revenue: signup completed, trial started, plan upgraded. Each event still rides on the same cookieless, hashed session, so you can see "this session converted" without ever knowing who the session belonged to.
This is the piece most generic "cookieless tracking" explanations skip, and it's the one that actually matters if you're running a SaaS or startup. Visitor counts are vanity. Visitor counts tied to MRR are the whole point.