Cookieless analytics at $10/1M events. Lightweight tracking script, no visitor identifiers.
Update, August 2026. This post was written in June 2025 and described a two-mode design that no longer exists. The daily-rotating visitor hash was retired — the code path is gone, not disabled — and with it city, region, timezone, browser/OS version numbers and raw screen dimensions. There is now no visitor identifier of any kind and no tier selector; what remains is a per-attribute basket with two presets. The sections below have been corrected to describe what actually ships. The deep-research appendix at the end is preserved as a June 2025 design document and is not a current description of the tool.
Most analytics tools track users across sessions using cookies or other persistent client-side identifiers. That has cost: regulatory exposure under GDPR, the ePrivacy Directive, and CCPA, plus the user-facing friction of consent prompts. This tool takes a more minimal approach:
The one thing it does put on the device, in its default configuration, is a tab-scoped sessionStorage key so a visit's pageviews group into a session. That is a write to terminal equipment and I don't pretend otherwise - see the two presets below.
How that maps onto your own GDPR / CCPA / ePrivacy obligations depends on your site, your jurisdiction, and your regulator. This post describes what the tool does, not what your privacy policy should say. For that, see a lawyer.
You pick, per site, which attributes that site may collect. Two presets sit on top of that basket.
No cookies, no persistent identifier, no cross-site tracking, and nothing in localStorage beyond the opt-out flag. Per request:
Two honest asterisks on that, because I'd rather write them than have you find them.
The script reads one localStorage key on every page load, notrack, to see whether the visitor has opted out. That is a read from terminal equipment like any other. I'm comfortable resting an opt-out check on Article 5(3)'s strictly-necessary limb - honoring a refusal is the one read that exists for the visitor's benefit - and the tool models it rather than leaving it to prose: regime.ts declares it as STRICTLY_NECESSARY_READ and the regime indicator renders it under every verdict.
The script also writes one thing, on every preset including this one: an ephemeral session id in sessionStorage, which the browser discards the moment the tab closes. Under zero-footprint the server drops that id on arrival, so it is never stored and never counted - but the write itself happens on the device, and Article 5(3) attaches to the act, not to what the server does afterwards. So this preset is not banner-free by construction; it is the lightest posture the tool offers, resting on the same audience-measurement argument as the default, with strictly less retained.
Best for: marketing sites, landing pages, basic traffic monitoring.
Everything above, plus:
sessionStorage, cleared when the tab closes, so a visit's pageviews group into a sessionutm_source / utm_medium / utm_campaign read from the URLWriting that session key and reading UTM tags are both operations ePrivacy Article 5(3) reaches, so this preset is not banner-free by construction. The tool labels it exemption-resting: it rests on the audience-measurement exemptions several national regulators apply to first-party analytics, subject to their conditions. That is a weaker claim than zero-footprint, and I'd rather ship the weaker word than the flattering one. ocdevel.com itself runs on this preset, not the zero-footprint one. Whether it holds for your site is a question for your counsel and your DPA. Your site will need a privacy policy that describes this processing either way.
Best for: content sites, SaaS apps, e-commerce where understanding entry paths matters.
There is no tier that reads device state or builds a per-visitor linkage key. The daily salted hash this post originally described was retired, along with city, region, timezone and browser/OS version numbers - every one of them was a field nothing in my own dashboards actually read, which made it pure liability. No preset offers that tier and no basket can reach it.
| Feature | This Tool | Plausible | Matomo | Google Analytics |
|---|---|---|---|---|
| Price | $10/1M events | $9-19/mo (10k-100k views) | Free (self-host) or $23+/mo | Free* |
| Cookies | None | None | Optional | Required |
| Unique Visitors | None (sessions only) | Daily hash | Depends on config | Full tracking |
| Self-hostable | Yes | Yes | Yes | No |
| Real-time | No (~20 min) | Yes | Yes | Delayed |
| Data Ownership | You own it | You own it | You own it | Google owns it |
*Google Analytics has knock-on costs: data ownership trade-offs, more involved consent UX, and the data feeds Google's ad network.
Before discussing the competition, GA. GA is best-in-class for analytics depth, less so for privacy. Server-side tagging and consent mode help but still leave a consent story to manage. If you want the full GA feature surface and have the appetite for the consent UX, use it - it is free, powerful, and sometimes expected for ad-network audits (e.g., Mediavine). Smaller sites that mainly want pageviews, sources, and basic events tend to want something lighter.
These tools are powerful, privacy-focused, and open-source/self-hostable. I particularly like Plausible - dirt simple, but robust enough that you don't miss Google Analytics. All-in-one dashboard, no hunting around. I modeled this tool after it.
Why I didn't stick with Plausible: Cost. $40/month for my ~20k monthly events with custom properties and funnels. The tooling is simple enough to build and host on a shoestring forever. Plus, analytics is foundational - something all my projects need. So I decided to take control.
Matomo and Umami are also expensive. Yes, they're open source - you can self-host for free. But their Community Editions lack the features I need (custom properties, funnels).
At the other extreme is GoatCounter - totally free. But too simplistic for my taste. I missed Plausible's power. Also, free services can change pricing when they succeed. Open source, so I could fork it, but I prefer control in my stack (SST v3, AWS Serverless).
Posthog pricing is excellent - pay as you go, very inexpensive. The tool is powerful. The downside: achieving banner-free tracking requires careful configuration. I discovered Posthog late in development - I probably would have used it otherwise. If you want to compare, give it a spin.
More powerful than GoatCounter (but you can't beat free!), significantly cheaper than Plausible & company (but less powerful, for now). $10 per million events. Plausible is around $40 per 100k events, so this is 2.25% the cost!
And the cost is per event, not per month. You don't owe another $10 until you've spent 1 million events. For this site, that's about 4 years. $10 for 4 years.
Why so cheap? I'm focusing on price, spending time with AWS S3, Glue, Iceberg, Athena to pare down costs. The more I optimize (next: S3 Tables + Materialized Athena Views), the more I'll pass savings on to users.
The tracking script uses no cookies and no device fingerprinting, and collects only data browsers send in standard HTTP requests - plus, on the default preset, the tab-scoped session key and UTM tags described above.
Cookieless analytics at $10/1M events. Lightweight tracking script, no visitor identifiers.