How to track website visitors without cookies

To understand cookieless tracking, it helps to understand what cookies actually do in an analytics context. When a visitor loads a page with Google Analytics, the tracking script checks for an existing _ga cookie. If one exists, the visitor is recognized as returning. If not, the script generates a random client ID and stores it in a new cookie.

This cookie persists for two years by default. Every subsequent page load reads the same cookie, which is how GA4 knows that the person who visited your pricing page on Monday is the same person who visited your signup page on Thursday. Sessions are tracked through a separate cookie (_ga_) with a 30-minute expiry — if the visitor is inactive for more than 30 minutes, the next interaction starts a new session.

This model works well for accuracy but creates several problems. Cookies require consent under GDPR and ePrivacy — which is why most sites need a cookie banner. Safari limits first-party cookies set via JavaScript to 7 days (or 24 hours in some cases via ITP), meaning "returning visitors" on Safari are often counted as new after a week. And cookie blockers — used by roughly 30% of technical audiences — make visitors completely invisible.

The simplest cookieless approach is to not identify visitors at all. Each pageview is treated as an independent event. You count total pageviews, track referrers, record device and browser information, and capture UTM parameters — but you cannot distinguish between a returning visitor and a new one, and you cannot track sessions.

Pros: Zero privacy concerns. No consent needed. No storage mechanism to manage. Every visitor is counted regardless of browser settings.

Cons: No unique visitor counts (only pageviews). No session tracking (no bounce rate, no time on site, no pages per session). No conversion attribution across pages. If 10 pageviews happened, you cannot tell if it was 10 people visiting once or 1 person visiting 10 pages.

This approach is too limited for most use cases. You lose the most valuable analytics metrics — unique visitors, session behavior, and conversion paths.

A step up from session-only tracking is using IP addresses to identify visitors. The server hashes the visitor's IP address (often combined with the User-Agent string) and uses this hash as a pseudonymous identifier. Visitors from the same IP with the same browser are grouped together.

Pros: No client-side storage required. Works regardless of browser settings or JavaScript capabilities. Server-side only — the tracking script does not need to manage state.

Cons: IP addresses are considered personal data under GDPR, even when hashed. Multiple users behind the same corporate NAT or household router share an IP, inflating unique visitor counts. Mobile users change IP addresses frequently (cell tower handoffs, WiFi/mobile switching), deflating returning visitor counts. VPN usage further distorts the data.

Some analytics tools use daily IP rotation — the hash salt changes every 24 hours, so the same IP produces a different identifier each day. This improves privacy (you cannot track a visitor across days) but means you have zero visibility into multi-day visitor behavior. A visitor who comes back tomorrow is always "new."

Browser fingerprinting collects a combination of browser attributes — screen resolution, installed fonts, timezone, language settings, WebGL renderer, audio context properties — and combines them into a hash that is relatively unique per browser. Libraries like FingerprintJS can achieve high uniqueness rates.

Pros: No storage needed. Works across sessions and even after browser restarts. Relatively stable over time (most people do not change their screen resolution or timezone frequently).

Cons:Fingerprinting is increasingly viewed as invasive by privacy advocates and regulators. The GDPR's ePrivacy Directive does not specifically address fingerprinting, but recent guidance from several EU DPAs treats it as equivalent to cookie tracking in terms of consent requirements. Browsers are also actively fighting fingerprinting — Firefox has fingerprint protection, Safari randomizes certain APIs, and Chrome has announced plans to reduce fingerprinting surfaces.

Heavy fingerprinting is also fragile. Browser updates can change fingerprint components. Two people with the same laptop model, OS version, and browser version may have identical fingerprints. The accuracy degrades on mobile devices where hardware diversity is lower.

This is the approach used by sourcebeam and several other privacy-focused analytics tools. It combines a minimal set of attributes — typically the IP address, User-Agent string, and a daily-rotating salt — into a hashed identifier that cannot be reversed to reveal the original data.

The key design decisions that make this approach privacy-respecting:

No raw data is stored. The IP address is never written to disk. It is used in memory to generate a hash, then discarded. The resulting hash cannot be reversed to recover the original IP. This means even if the analytics database is breached, no personal data is exposed.

Limited attribute set. Unlike heavy fingerprinting that probes dozens of browser APIs, this approach uses only the information that the browser sends in every HTTP request anyway — IP address and User-Agent. No additional JavaScript APIs are called for identification purposes. This avoids the ethical and legal concerns of device fingerprinting.

Client-side session state. Sessions are tracked using sessionStorage or in-memory state — both of which are automatically cleared when the browser tab is closed. This is not a cookie — it does not persist across browser sessions, is not sent to the server with each request, and is not accessible by other websites.

Visitor recognition via localStorage. For multi-session visitor recognition, a random visitor ID can be stored in localStorage. Unlike cookies, localStorage is not sent to the server automatically — it stays on the client. The ID contains no personal information and cannot be used for cross-site tracking. Some privacy-focused tools avoid localStorage entirely and rely solely on server-side hashing for returning visitor detection.

Pros:No cookies. No consent banner needed in most jurisdictions. Good accuracy for unique visitors within a day. Session tracking works. Conversion attribution works within a session. Resistant to ad blockers (no cookie to block). Works with Safari's ITP since there is no cookie to expire.

Cons: Multi-day visitor recognition depends on localStorage (which can be cleared) or server-side hashing with rotating salts (which resets daily). Less accurate than long-lived cookies for tracking visitors over weeks or months. Users behind the same IP with the same browser are still grouped together.

Cookie-based analytics is not as accurate as people assume. Safari ITP limits cookie lifetime to 7 days for JavaScript-set cookies. Firefox Enhanced Tracking Protection blocks known analytics cookies. Browser extensions like uBlock Origin and Privacy Badger block analytics scripts entirely. Ad blockers affect 25-40% of technical audiences.

The result is that cookie-based analytics significantly undercounts visitors on Safari (roughly 20% of global web traffic) and overcounts unique visitors when cookies expire and the same person is counted again as "new." For sites with a technical audience, 30-40% of visitors may be invisible to cookie-based analytics.

Cookieless analytics tools like sourcebeam avoid most of these problems. The tracking script is first-party (served from your domain or a subdomain), so it is not blocked by third-party cookie restrictions. It does not set cookies, so Safari ITP does not affect it. Most ad blockers target known analytics domains (google-analytics.com, plausible.io), but first-party scripts served from your own domain are typically not blocked.

In practice, cookieless analytics often counts more visitors than cookie-based analytics — not because it overcounts, but because it does not lose the visitors that cookies miss due to consent rejection, ITP expiry, and ad blocking.

Honesty matters here. Cookieless analytics involves real trade-offs:

Long-term visitor recognition is less reliable. A cookie with a 2-year expiry can recognize the same visitor over months. Cookieless methods that rely on server-side hashing with daily salt rotation cannot — the same visitor appears as "new" each day. Methods using localStorage for visitor IDs are more persistent, but users can clear localStorage, and different browsers on the same device are counted separately.

Cross-device tracking is impossible. Without login-based identity (which requires cookies or tokens), there is no way to know that the person who visited on their phone is the same person who later visited on their laptop. Cookie-based tools have the same limitation unless the user logs in, but marketing platforms like Google Analytics can sometimes infer cross-device identity through Google account signals.

Multi-touch attribution over weeks is harder. If a visitor discovers your site through a blog post, returns a week later from a newsletter link, and converts two weeks after that — a cookieless system with daily hash rotation cannot connect all three visits. Tools using localStorage for visitor IDs can track this chain, but with less reliability than a persistent cookie.

For most websites, these trade-offs are acceptable. The majority of analytics questions — which pages are popular, where traffic comes from, what converts, how many unique visitors we get — are answered accurately by cookieless methods. The edge cases where cookies provide more accuracy (long-term cohort analysis, multi-week attribution) affect a small percentage of analytics use cases.

You have two options: build it yourself or use a purpose-built tool.

Building it yourself is possible but involves more than most teams expect. You need to handle: visitor identification (hashing, salt rotation, collision management), session detection (timeout logic, tab handling, SPA navigation), data collection (batching, offline queuing, retry logic), data storage (time-series database, aggregation queries), and a dashboard to visualize it all. You also need to handle bot filtering, rate limiting, and privacy compliance review. This is a substantial engineering project.

Using a cookieless analytics tool gets you to the same result in minutes. sourcebeam, for example, is a single script tag:

That one line gives you cookieless visitor tracking, session detection, pageview recording, referrer and UTM attribution, device and country breakdowns, and a real-time dashboard. The script is under 1 KB, does not set cookies, and does not store personal data.

Other cookieless analytics tools include Plausible, Fathom, and Simple Analytics. Each makes slightly different trade-offs around pricing, features, and privacy approach — but all avoid cookies. If you are evaluating options, our guide on how to choose the right analytics tool covers what to look for.

The legal question is not "are cookies bad?" but "does my analytics setup require user consent?" Under the EU's ePrivacy Directive (implemented through national laws like GDPR), you need consent before storing or accessing information on a user's device — with exceptions for what is "strictly necessary" for the service the user requested.

Cookies set by analytics tools are generally not considered strictly necessary, which is why Google Analytics requires a consent banner in the EU. But cookieless analytics that does not store anything on the user's device (no cookies, no localStorage for tracking purposes) typically does not trigger the consent requirement.

Several EU data protection authorities have explicitly stated that cookieless, privacy-respecting analytics can be used without consent. The French CNIL, in particular, has published guidance recognizing that certain privacy-focused analytics tools can be exempt from consent requirements when they meet specific criteria: no cross-site tracking, no personal data storage, and data used only for aggregate statistics.

This is not blanket legal advice — regulations vary by country, and interpretations evolve. But the direction is clear: the web is moving toward analytics approaches that respect user privacy by design, rather than relying on consent banners to retroactively legitimize invasive tracking.

Cookieless tracking is not a compromise — it is the future of web analytics. The cookie-based model is eroding from every direction: browser restrictions, privacy regulations, user expectations, and ad blocker adoption. Tools built around cookies are fighting a rearguard action with server-side tagging, consent mode, and modeled conversions.

Tools built without cookies — like sourcebeam, Plausible, and Fathom — are designed for the world we are moving into. They are simpler, lighter, more private, and often more accurate than their cookie-dependent predecessors. The trade-off in long-term visitor recognition is real but narrow, and for the vast majority of websites, the benefits far outweigh the costs.