Building an Analytics Stack That Does Not Need a Cookie Banner

Every site with a cookie banner is telling you the same thing: a third-party script is setting identifiers on the visitor's device before they agreed to it. The banner is the patch. The cause is the analytics tool.

There is a simpler path. If the analytics tool does not set cookies and does not collect personal data, most of the consent obligation disappears, and so does the banner. This is not a legal loophole, it is how the tools are designed.

Why the banner exists

European data protection rules treat cookies and similar identifiers as requiring consent unless they are strictly necessary for the service the user requested. A cookie that remembers your login session is strictly necessary. A cookie that assigns a random ID so an analytics dashboard can count unique visitors is not.

Most analytics products work by setting exactly that kind of identifier. Google Analytics 4 uses cookies by default. Mixpanel and Amplitude use a device ID. Because the identifier is set before consent, sites need a consent management platform to ask first, which means the analytics script must wait, which means the data is incomplete and biased toward people who click accept.

That bias is worth stating plainly: consent-gated analytics systematically undercounts privacy-conscious visitors, which is often the audience most worth understanding.

What "cookieless" actually means

A cookieless analytics tool does not write anything to the device and does not build a persistent identifier for a visitor. Instead it records an event: this page was viewed, at this time, from this referrer, from this country, with this browser.

To count unique visitors without an identifier, these tools typically compute a daily rotating hash from IP address, user agent, and a site-specific salt. The hash is discarded after 24 hours and cannot be reversed to an individual. The result is accurate daily uniques without a persistent identifier, which is the technical distinction that matters legally.

The tools that work this way include Plausible, Umami, Fathom, and a few others. They are not interchangeable in features but they share the property that matters here.

What you lose

Be clear about the trade, because it is real.

No cross-session journeys. You cannot see that the person who bought today visited three times last week. There is no person to follow.

No funnels across sessions. A funnel within one session works. A funnel that spans a week of visits does not, because the tool cannot tell it is the same person.

No user-level segmentation. No cohorts, no retention curves by acquisition channel, no "users who did X then Y".

If you are running a product where those questions matter, cookieless analytics is the wrong tool and you should build a proper consent flow instead. If you are running a content site where the questions are "which pages get read" and "where does traffic come from", you lose nothing.

A stack that works

For a content site or a marketing site, this is the whole stack:

Collection: Plausible or Umami. One script tag, under 2 KB, no cookies. Plausible is hosted and paid. Umami is open source and can run as a single container against Postgres, or be bought hosted for less than Plausible.

Reporting: the tool's own dashboard. One page with visitors, sources, top pages, and goals. For most sites this is genuinely sufficient, and the reason people want more is usually curiosity rather than a decision they need to make.

Deeper analysis: your database, not your analytics tool. When you need real analysis, export events to a warehouse and query them. Metabase over Postgres will answer questions a dashboard cannot, without per-event pricing.

That last point is the important architectural one: keep collection cheap and dumb, keep analysis separate. Tools that try to do both charge you for the analysis layer whether you use it or not.

The technical setup

Umami in Docker against Postgres is about fifteen lines of compose file. The tracking script is one line in your template's <head>.

The things that actually need care:

• Put it behind your own domain. A first-party path like /stats/js/script.js avoids ad blockers that maintain lists of known analytics domains. This is not evasion, it is the same practice as self-hosting fonts.
• Respect Do Not Track if you claim to. Some tools do it by default. If yours does not, say so in the privacy policy rather than implying otherwise.
• Set retention. Even aggregate data should have a retention policy. Most tools let you set it; most people never do.
• Document it in the privacy policy. Say what is collected, that it is aggregate, and that no cookies are used. This is what makes the no-banner position defensible.

The legal caveat, stated honestly

Whether cookieless analytics needs consent depends on jurisdiction and on how the regulator interprets "personal data". The consensus reading in the EU is that aggregate, non-identifying measurement does not require consent, and several data protection authorities have said so publicly. Some member states interpret it more strictly.

This is not legal advice, and if you operate in a regulated industry or at scale, ask a lawyer. But the direction is clear: the fewer identifiers you collect, the less consent machinery you need, and the difference between a cookie-based tool and a cookieless one is the difference between a banner and no banner.

What to do this week

If you are running GA4 on a content site, install Umami or Plausible alongside it for two weeks. Compare the numbers. In most cases you will find the cookieless tool reports higher traffic, because it is not losing the people who dismiss the banner, and the extra detail GA4 gives you is not detail you were using.

Then delete GA4 and the banner. That is one less script, one less consent flow, and a faster page.