Cookieless Analytics: The Complete Guide
Cookie-based analytics is becoming less reliable every year. This guide explains what cookieless analytics is, how it works technically, what you actually give up by dropping cookies, and how to pick the right tool.
What Cookies Are and Why Analytics Tools Relied on Them
A browser cookie is a small key-value string that a server sends to a browser, which the browser stores locally and sends back on every subsequent request to that domain. Cookies were invented in 1994 by Lou Montulli at Netscape to solve a specific problem: HTTP is stateless, so without some client-side persistence, a shopping cart could not remember what you added on the previous page.
Analytics tools adopted cookies for the same reason: they needed a way to recognize the same visitor across multiple page loads and across multiple sessions. The typical approach was to generate a random UUID, store it in a cookie with an expiration date set years in the future, and read that UUID on every pageview. This gave you a persistent visitor identifier that survived browser restarts and multiple visits over months or years.
That approach worked well when cookies were ubiquitous and users rarely thought about them. It no longer works well.
Why Cookie-Based Analytics Is Breaking Down
Intelligent Tracking Prevention (ITP) in Safari
Apple introduced ITP in Safari in 2017. The current version aggressively limits cookie lifetimes and blocks third-party cookies entirely. First-party analytics cookies (set on your own domain via JavaScript) are capped at a 7-day expiration in many cases. A visitor who comes back two weeks later looks like a brand-new visitor. Safari represents roughly 19% of global browser market share and a higher proportion in higher-income demographics that many SaaS products target.
Firefox Total Cookie Protection
Firefox implemented Total Cookie Protection in 2022, which puts third-party cookies in isolated "jars" per site, preventing cross-site tracking. While this affects advertising trackers more than first-party analytics, it signals the broader direction: browsers are actively working against cookie persistence.
Chrome's Third-Party Cookie Reversal
After years of promising to deprecate third-party cookies in Chrome, Google reversed course in July 2024 and announced it would not eliminate them. Instead, Google introduced its Privacy Sandbox initiative, which gives users more browser-level control over cross-site tracking. Third-party cookies remain active in Chrome. However, the broader ecosystem shift away from cross-site cookie tracking continues, and relying on third-party cookies for analytics remains a fragile long-term strategy.
GDPR and CCPA Consent Requirements
Even if browsers allowed unlimited cookie persistence, GDPR requires that you get explicit consent before storing cookies that identify users, because those identifiers count as personal data. A consent banner is not optional for cookie-based analytics if you have EU visitors. CCPA adds similar obligations for California residents.
The problem with consent banners is that many users decline. The numbers vary depending on the study, the country, and how the banner is designed, but industry data consistently shows that 30-40% of users in regions with consent requirements click "reject all," depending on banner design and geography. That means your analytics are missing data for a third to half of your visitors from day one. Conversion rates, bounce rates, and funnel drop-off numbers all become unreliable.
How Cookieless Analytics Actually Works
The goal of any analytics system is to answer questions like: how many people visited, where did they come from, what did they do, and did they convert? You can answer most of those questions without ever storing a persistent identifier.
The naive approach (and why it fails): fingerprinting
Browser fingerprinting uses a combination of signals (installed fonts, canvas rendering, WebGL capabilities, screen resolution, installed plugins, and more) to generate a hash that is statistically unique to a specific browser. Tools like AmIUnique.org have shown that a combination of these signals can identify individual browsers with high accuracy.
Fingerprinting is not a good solution. It is invasive, it constitutes processing of personal data under GDPR, it requires consent, and it fails in predictable ways (shared machines, VPNs, corporate proxies, and newer browsers are increasingly resistant to it). Avoid any analytics tool that uses fingerprinting.
A better approach: server-side session hashing with daily rotation
The privacy-respecting alternative uses only the information that is already sent with every HTTP request, derives a temporary session identifier from it, and never persists that identifier.
When a visitor loads your site, their browser sends:
- The client IP address (visible to your server automatically)
- The
User-Agentheader (browser name, version, OS) - The
Accept-Languageheader (preferred language)
From the JavaScript snippet, you can also collect screen dimensions and viewport size without storing them as cookies.
You combine these signals with a salt value that rotates every 24 hours and hash the result with a one-way hash function (SHA-256 or similar). The output is an anonymous session token that identifies this browser for this calendar day. The next day, the salt changes, so the same visitor generates a completely different token. There is no way to link yesterday's token to today's token, even if you have access to the database.
How Abner specifically implements this
Abner's tracking script is split into two files: abner.js (core, approximately 1.8KB minified) and abner-vitals.js (lazy-loaded for Web Vitals collection, approximately 1.9KB). No cookies are set. No data is written to localStorage or sessionStorage.
On the server side, when an event arrives, Abner hashes the visitor's IP address together with their User-Agent string and a salt value that changes every 24 hours. The raw IP address is never written to disk or to any database. The resulting hash cannot be reversed to recover the IP, and it cannot be matched against hashes from a different day.
Here is a simplified diagram of that flow:
What You Lose and What You Keep
This is the question that matters most practically. Here is an honest breakdown.
What you lose with cookieless analytics:
- Persistent visitor identity across sessions. You cannot say "this is the same person who visited 14 days ago." Each day is a fresh start.
- Cross-site tracking. You cannot follow a user from your marketing site to your app across different domains without application-level logic.
- Long-term returning visitor counts. "Returning visitor" metrics become less accurate because each day's hash is different.
What you keep:
- Total pageview counts, accurate to 100% of visitors
- Session counts and bounce rate
- Traffic sources: referrer domains, UTM parameters, direct vs. organic vs. paid
- Top pages and entry/exit pages
- Custom events (button clicks, form submissions, purchases)
- Real-time data
- Geographic distribution (country, region) derived from IP before hashing
- Device and browser breakdown from User-Agent
For most SaaS products, the metrics that actually matter for business decisions, such as which marketing channel drives signups, which landing pages convert, and where users drop off in onboarding, are fully available in a cookieless system.
GDPR and CCPA Compliance Without a Consent Banner
Why cookieless analytics is generally exempt from consent requirements
The key question for a cookieless analytics tool is whether any personal data is actually processed or stored. Because no personal data is processed, GDPR does not apply at all -- there is no need for a lawful basis.
Under GDPR, IP addresses are personal data. The European Court of Justice confirmed this. If you store IP addresses in your analytics database, you are processing personal data and you need a legal basis.
Abner's approach avoids this entirely: the IP is used transiently during hashing, the hash cannot be reversed, and the raw IP is never written to any storage. The end result in the database is an anonymous hash that cannot be linked to a specific person, even by Abner. Because no personal data is stored, GDPR's consent requirements are not triggered.
The specific legal reasoning
Recital 26 of GDPR states that "the principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person." If your analytics system genuinely cannot identify a natural person, even indirectly, you are outside the scope of the regulation's consent requirements.
This is why tools like Abner, Plausible, and Fathom all take the position that they do not require a consent banner: the anonymization is real and irreversible, not just a policy claim.
CCPA is less of an issue for analytics
CCPA focuses primarily on businesses that sell or share personal information. If you are running analytics to understand your own product, and you are not selling that data to third parties, CCPA's opt-out mechanism (the "Do Not Sell My Personal Information" link) does not apply. CCPA also only applies to for-profit businesses with annual gross revenues above $25 million, businesses that buy or sell data from more than 100,000 consumers or households per year, or businesses that derive more than 50% of revenue from selling personal information. Most early-stage SaaS products do not meet any of these thresholds.
Accuracy: Cookieless vs. Cookie-Based Analytics
A common assumption is that removing cookies reduces accuracy. The opposite is often true.
Google Analytics 4's accuracy problems
GA4's free tier applies data sampling when your property exceeds certain event thresholds. Reports are generated from a statistical sample of your data, not from all of it. For high-traffic sites, this can introduce significant error margins.
More importantly, any analytics system that requires a consent banner is automatically missing data from users who decline. In Germany and France, decline rates can exceed 50%. Your GA4 data for EU traffic may represent only half of actual visitors.
How cookieless analytics compares
A tool like Abner counts every page load that hits the server, including visitors who would have declined a consent banner (because no consent is required). There is no sampling on any plan. The trade-off is that you lose long-term individual visitor tracking, but you gain accurate aggregate counts.
For almost all product and marketing decisions, aggregate accuracy matters more than individual tracking.
The main accuracy limitation of cookieless analytics is at the session boundary. If two people share an IP address (office Wi-Fi, university network, NAT gateway), they may be counted as one visitor. This is a known and accepted limitation. It affects bounce rate and session counts more than it affects pageview totals.
How to Choose a Cookieless Analytics Tool
The market includes several solid options. Here is what to evaluate:
Script size
A tracking script that adds 50KB to your page load is not free. Abner's core script is approximately 1.8KB. Plausible's script is around 1KB. Matomo's full script is significantly larger. For performance-sensitive products, this matters.
IP handling
Ask specifically: is the raw IP address ever written to a database or log file? Some tools claim to be cookieless but still log IPs in their access logs, which are personal data under GDPR. Look for explicit statements about IP hashing or truncation on ingestion.
Data retention policy
Check whether the vendor imposes limits on how long your historical data is kept. Some lower-tier plans purge data after 12 months. Abner keeps data indefinitely on all plans.
No sampling
Confirm that reports are generated from 100% of your data, not from samples. This should be a standard feature, not an upsell.
EU data residency (if required)
If your users are primarily in the EU and you have strict data residency requirements, check where the analytics servers are hosted. Plausible and Simple Analytics both process data in Europe. Abner is hosted on GCP with US-east infrastructure.
Pricing comparison
- Abner: Starter $19/mo, Pro $49/mo, Business $99/mo (14-day free trial, no credit card required)
- Plausible: starts at $9/mo (open source, EU-hosted)
- Fathom: starts at $14/mo (Canadian company, cookieless)
- Simple Analytics: starts at $9/mo (Dutch company)
- Matomo: open source self-hosted (free) or cloud plans starting higher
FAQ
Is cookieless analytics less accurate than cookie-based analytics?
For aggregate traffic metrics, no. Cookieless analytics often produces more accurate numbers because it counts all visitors without requiring consent. The accuracy trade-off is specifically around multi-session tracking for individual users: you cannot identify the same visitor across different days. For the product and marketing questions that most SaaS teams actually need to answer, this rarely matters.
Do I still need a privacy policy if I use cookieless analytics?
Yes. A privacy policy is a separate legal requirement that exists independently of consent banners. You should document what data you collect, why, how long you keep it, and who has access. The advantage of cookieless analytics is that your privacy policy entry for analytics becomes much simpler: "We use Abner Analytics, which collects anonymized page view data. No personal data is stored. No cookies are used."
What about bot filtering?
This is a real concern with server-side analytics. If every HTTP request generates a pageview, search engine crawlers, uptime monitors, and malicious bots inflate your numbers. Good cookieless analytics tools filter known bots using the User-Agent string. Abner's bot filtering uses a maintained list of known bot user agent strings and filters them server-side before data is stored.
Can cookieless analytics track logged-in users?
Not automatically. If you want to tie analytics events to specific user accounts (for product analytics, user journey analysis, or cohort reporting), you need to pass a user identifier from your application explicitly. This is the same approach used by product analytics tools like Mixpanel or Amplitude. You pass a hashed or pseudonymous user ID as a custom property on your events. Abner supports custom event properties, so this is possible while still avoiding raw personal data in your analytics.
Can I use cookieless analytics alongside my existing tools?
Yes. There is no conflict in running multiple analytics tools. Many teams run a lightweight cookieless tool for accurate traffic counts while also running a product analytics tool (Mixpanel, PostHog) for logged-in user behavior. The cookieless tool handles the top of the funnel; the product tool handles everything after login, where you already have consent through your terms of service.
Try Abner
Abner is a privacy-first analytics platform built for SaaS products. The tracking script is under 2KB, sets no cookies, and requires no consent banner. You get real-time traffic data, custom events, Web Vitals, Google Search Console integration, and Stripe-connected SaaS metrics (MRR, churn, LTV, ARPU) in a single dashboard.
14-day free trial. No credit card required. Get started with Abner.