Why cookies became a problem for analytics

Cookies have been the backbone of web analytics for two decades. Drop a cookie on a visitor’s browser, read it on their next visit, connect the sessions — simple and effective. The problem is that cookies, under EU privacy law, require informed consent when used for analytics purposes.

The ePrivacy Directive (the “Cookie Law”) and GDPR together create a framework where placing a non-essential cookie without consent is a legal violation. Analytics cookies are non-essential by definition. Hence: cookie consent banners.

And those banners work. Studies show that 40–60% of European visitors exercise their right to decline. Your analytics tool dutifully ignores them — and your data develops a systematic blind spot covering nearly half your audience.

Cookie-free analytics solves this at the source. Instead of relying on browser cookies, it uses techniques that fall outside the consent requirement entirely.

How FPAI tracks sessions without cookies

FPAI uses two complementary mechanisms: hashed IP addresses for privacy-safe visitor identification, and localStorage for session continuity within a browser.

Mechanism 1: Hashed IP address

When a visitor arrives on your site, FPAI’s server-side code reads their IP address from the HTTP request. It never stores the raw IP. Instead, it immediately applies a SHA-256 hash combined with your WordPress site’s secret salt:

# Conceptual flow (simplified)
raw_ip = “203.0.113.42” ← never stored
salt = wordpress_secret_key
visitor_id = sha256(raw_ip + salt) ← this is stored
= “a3f9b2c1d4e8…” ← not reversible

The hash is a one-way function. There is no way to recover the original IP address from the stored hash. Even if someone obtained your database, they could not use the visitor IDs to identify individuals. The WordPress salt also means visitor IDs from your database cannot be matched against hashed IDs from a different site.

Mechanism 2: localStorage for session continuity

IP addresses alone have a problem: multiple people behind the same router (an office, a household, a café) share an IP and would look like one visitor. To handle this, FPAI uses localStorage — a browser storage mechanism distinct from cookies.

On a visitor’s first pageview, FPAI generates a random visitor ID and stores it in localStorage under your domain. On subsequent pages in the same session, it reads this ID to link pageviews into a session. LocalStorage persists until the user clears their browser storage — it’s not a session-level store like sessionStorage.

localStorage vs cookies: the legal distinction The ePrivacy Directive specifically regulates “cookies or similar tracking technologies” when they are used to access information stored on the terminal device. However, regulators and legal scholars generally view localStorage used for first-party analytics — where data is sent only to the same domain’s own server and not to third parties — as falling outside the consent requirement, particularly when combined with privacy-preserving design like IP hashing. You should still disclose your analytics approach in your privacy policy.

What data FPAI collects per session

For each visitor session, FPAI captures:

  • Hashed visitor ID — derived from IP + salt, not reversible
  • Session ID — a random UUID generated fresh each session
  • Device type — mobile, tablet, or desktop (derived from User-Agent)
  • Browser and OS — Chrome, Safari, Firefox, etc. (derived from User-Agent)
  • Referrer domain — where the visitor came from (e.g., google.com, twitter.com)
  • UTM parameters — campaign tracking values from the URL
  • Session start time
  • Session duration and page count — updated as the session progresses
  • Bounce status — single-page sessions flagged as bounces

For each pageview within a session:

  • Page URL and title
  • Scroll depth (Pro) — how far down the page the visitor scrolled
  • Time on page (Pro)

The raw IP address is never written to disk. The User-Agent string is parsed for device/browser/OS and then discarded — only the derived values are stored.

What FPAI does NOT do

To be explicit about the privacy boundaries:

  • FPAI does not set any cookies in the visitor’s browser
  • FPAI does not store raw IP addresses
  • FPAI does not send data to any third-party server — all data goes only to your own WordPress database
  • FPAI does not use browser fingerprinting (canvas fingerprint, font detection, etc.)
  • FPAI does not track visitors across different websites
  • FPAI does not create advertising profiles

Cookie-free tracking is more privacy-preserving, but it comes with real limitations you should understand:

Visitor deduplication across sessions is approximate

Because hashed IPs change when a user gets a new IP (home vs. mobile vs. office), the same person may appear as multiple “visitors” across different sessions. This is an inherent trade-off of cookie-free design. Session-level data (bounce rate, pages per session, duration) is accurate. Cross-session “returning visitor” counts are approximate.

Shared IPs create noise

People sharing a network (office, school, carrier-grade NAT) will share a hashed visitor ID. FPAI’s localStorage mechanism partially addresses this by differentiating browsers, but it’s not a perfect solution.

No cross-domain tracking

If your funnel spans multiple domains, FPAI cannot link sessions across those domains without additional configuration. This is the same limitation as any cookie-free solution.

Plausible and Fathom also use cookie-free tracking — both are good products with this in common. The key difference is where data is stored:

  • Plausible / Fathom: cookie-free, but data is sent to their servers (cloud-hosted). You’re trusting a third party with your data.
  • FPAI: cookie-free, and data goes directly to your own WordPress MySQL database. No third party receives it.

For sites where data residency matters — legal, healthcare, finance, or simply principled data ownership — FPAI’s approach gives you full control.

What to put in your privacy policy

Even without cookies, you should disclose your analytics approach. A straightforward disclosure:

Sample privacy policy language “This site uses FPAI, a first-party analytics plugin for WordPress. FPAI collects anonymized visitor data including a one-way hash of IP addresses, browser type, device type, pages visited, referral source, and UTM parameters. No cookies are set. All data is stored exclusively on our own servers and is not shared with third parties. This analytics approach does not require cookie consent.”

You should adapt this to your specific circumstances and have it reviewed by a legal professional if you operate in a regulated industry or jurisdiction.

FPAI is a free WordPress plugin that collects cookie-free, first-party analytics into your own database. Download free →