The banner is triggered by what you store on a visitor's device — not by having analytics. Switch to a tracker that stores nothing, and you can legally drop the banner. Here's the full playbook.
EU/UK cookie law requires consent for storing or reading information on a device — cookies, localStorage, and anything similar. It is not a rule about "analytics." If your only reason for the banner was cookie-based analytics like GA4, then swapping to a tool that sets zero cookies and stores no personal data removes the legal trigger, and you can take the banner down.
The whole switch is an afternoon of work for most sites. Below is the exact process, plus the cases where you legitimately still need a banner.
Almost every consent banner on the web traces back to a single European rule that is older than GDPR: the ePrivacy Directive (2002/58/EC, as amended in 2009), specifically its Article 5(3). That article says that storing information, or gaining access to information already stored, on a user's device requires the user's prior, informed consent — unless the storage is strictly necessary to deliver a service the user explicitly asked for. In plain English: if you want to drop a cookie that isn't essential, you have to ask first.
GDPR then raises the bar for what "consent" means. Under GDPR, consent has to be freely given, specific, informed, and unambiguous — a clear affirmative action, not a pre-ticked box and not "by continuing to browse you agree." That combination is why modern banners look the way they do: an explicit Accept, a genuine Reject that's as easy to click as Accept, and granular toggles by category. The ePrivacy Directive creates the requirement; GDPR defines the quality of the consent you must collect.
In the UK the same mechanism lives in the Privacy and Electronic Communications Regulations (PECR), enforced by the ICO, with UK GDPR supplying the consent standard. Different acronym, same logic. Other jurisdictions borrow the pattern too, though the strictest, most banner-driving regime is the EU/UK one.
The crucial takeaway for this guide: the law hangs the whole obligation on the act of storing or reading something on the device. It never says "you must show a banner because you measure traffic." If nothing non-essential is being written to or read from the visitor's browser, the Article 5(3) trigger simply isn't pulled — and that is the entire opening we're going to walk through.
Read Article 5(3) carefully and you'll notice it is deliberately technology-neutral. It talks about "information stored" and "access to information already stored" on a user's "terminal equipment." It does not say "cookies." Regulators have consistently confirmed that the rule covers any equivalent technique: HTTP cookies, of course, but also localStorage, IndexedDB, cache-based identifiers, ETag tricks, pixel-plus-fingerprint combinations, and device fingerprinting. If it reads from or writes to the device to track or identify, it's in scope.
So the real question is never "do I use cookies?" It's "does my site place or read non-essential information on the visitor's device?" Two words carry all the weight: non-essential.
Storage is considered essential — "strictly necessary" — only when it's required to provide something the user actively requested. Classic examples: a session cookie that keeps someone logged in, a cookie holding shopping-cart contents, a token that balances load or protects against CSRF, a flag that remembers the user's own choice to reject cookies. These don't need consent because without them the requested service can't function. Notably, the widespread view among EU regulators is that even a purely first-party analytics cookie is not strictly necessary, because the site works perfectly well for the visitor without it — the measurement benefits you, not them.
That's why analytics is the usual culprit behind a banner. Google Analytics, most heatmap tools, most A/B testing platforms, and ad pixels all write non-essential identifiers to the device. Each one, on its own, is enough to trigger the consent requirement. Which means the path to removing the banner is not "turn off analytics" — it's "make sure every remaining technology is either strictly necessary or stores nothing on the device at all." Get to that state and the legal basis for the banner evaporates.
Cookieless analytics is built specifically to sidestep Article 5(3). The design goal is simple and testable: never store anything non-essential on the visitor's device, and never keep personal data at rest on the server. Hit both and there is nothing for the consent rule to attach to.
Here's how a well-built cookieless tracker pulls that off. It sets no cookies and writes nothing to localStorage. The only per-visit state it needs — enough to tell a bounce from a two-page visit — lives in sessionStorage, which the browser wipes the moment the tab closes, so there is no persistent identifier left behind. Instead of a stored ID, it derives a short-lived, in-memory session signature and never plants it on the device. Because nothing durable is written or read, the "storing or accessing information on terminal equipment" condition is never met.
The other half is the data-at-rest question. A serious cookieless tool never logs raw IP addresses. Take GhostMetrics, which we build and run: the visitor's IP is used only in memory to compute a rotating hash, then discarded on the spot — it's never written to the database. That hash is salted with random bytes, scoped per-site so the same person on two different sites gets two unrelated values (it can never behave like a cross-site cookie), and the salt rotates every UTC day and is deleted, so yesterday's hashes can't be reversed or linked to today's. Geography is resolved to country, region, or city at the edge and the IP is dropped immediately; city level is the finest location it ever sees. No cookies, no localStorage, no stored IPs, no fingerprinting.
Put those two properties together and the consequence is legal, not just technical: with no device storage and no personal data at rest, the ePrivacy consent trigger isn't pulled and there's nothing requiring a banner. That's the whole reason "designed to be GDPR-friendly: no cookies, no consent banner, no personal data stored" is a claim a cookieless tool can make honestly. Compare the cookieless tools that let you drop the banner before you commit to one.
"Cookieless" has become a marketing word, and marketing words get stretched. Before you trust a tool enough to take your banner down, verify the claims yourself — because the legal exposure lands on you, not on the vendor's homepage copy.
Here's what to actually check:
localStorage or IndexedDB to persist a visitor ID. That's storage on terminal equipment — legally the same category as a cookie, banner requirement intact. Open your browser's DevTools, go to the Application tab, and confirm Cookies, Local Storage, and IndexedDB are all empty after a visit./gm.js so anyone can verify it. It's honest about the rest too: the dashboard is hosted and closed-source (like Fathom or Simple Analytics), it runs on US Cloudflare by default with EU data residency available on request, and if open-source self-hosting or strict EU residency is a hard requirement it will point you to Plausible, Umami, or Simple Analytics instead. That kind of caveat is a good sign — vendors who overpromise on residency are the ones to distrust.Verify these four things and you'll know whether a tool actually earns the no-banner claim or just borrows the word.
You can't safely remove a banner until you know exactly what your site stores. Most teams are surprised by this step — the culprit is rarely just analytics. Give yourself twenty minutes and do it properly.
Open DevTools on a real page load. In Chrome or Edge, press F12, open the Application tab, and inspect four panels under Storage: Cookies, Local Storage, Session Storage, and IndexedDB. Reload the page and click through your key flows — homepage, a blog post, checkout, any embedded content. Watch what gets written. Note the name, the domain that set it, and whether it's first-party (your domain) or third-party (a script you loaded).
Classify each entry into one of three buckets:
_ga cookies, a heatmap tool, your own A/B test. These are your removal targets.Cross-check with the network tab and your tag manager. Some storage is set conditionally — only after a user interacts, only on certain pages. Trigger those paths. If you run Google Tag Manager, open it and list every tag; GTM is where forgotten pixels go to hide. Also scan your HTML for third-party <script>, <iframe>, and pixel tags.
At the end you should have a written inventory: every stored item, its bucket, and who sets it. That inventory is your map. If everything in buckets 2 and 3 can be removed or replaced, the banner can go. If something in bucket 3 has to stay, jump ahead to the "when you still need a banner" section.
For most sites, GA4 is the single biggest reason the banner exists. In the EU/UK it sets cookies and processes personal data, so it falls squarely under the consent rules — you generally need prior consent, and therefore a banner, before it's allowed to run. (Several EU data protection authorities have gone further and flagged certain Google Analytics configurations over transfers of personal data to the US; the details are evolving, but the direction of travel is why so many teams are leaving.) Replacing it is usually the highest-leverage move you can make. If you're specifically coming off GA4, our GA4 alternatives guide covers the migration in depth, and the background reading on whether Google Analytics is GDPR compliant explains the underlying legal debate.
The swap itself is mechanical:
<script defer src="https://ghostmetrics.nullagency.io/gm.js" data-site="your-site"></script> and you're collecting data immediately.Run both tools in parallel for a few days if you want a comfort check on the numbers — cookieless counts often look higher than consent-gated GA, because you're finally measuring the visitors who would have clicked "Reject." Once you trust the new data, delete GA for good.
Do this step only after your DevTools audit shows a clean slate: no non-essential cookies, no localStorage, no fingerprinting, no third-party tags quietly storing anything. Once you're there, the removal is straightforward — but the paperwork matters as much as the code.
Remove the banner code. Delete the consent-management script and its markup from your templates. If your CMP (consent management platform) was also gating scripts — loading them only after consent — make sure the scripts you actually kept still load on their own now. Test in an incognito window: no banner should appear, and your analytics should still record the visit.
Rewrite your privacy policy to match reality. This is the part teams forget, and it's the part a regulator or a privacy-conscious visitor will actually read. Your policy should now state plainly:
Keep a record of your reasoning. Save your cookie audit and a short note on why you concluded no consent is required. If anyone ever asks, "we store nothing non-essential on the device, here's the audit" is a far stronger answer than "our vendor said it was fine." Remove any stale mentions of Google Analytics or advertising cookies from the policy — a policy that describes cookies you no longer set is its own small compliance problem.
The fear that stops most teams is "if I kill the banner and GA, I'll go blind." In practice you lose remarkably little, and you gain a few things.
What you keep. All the reporting most sites genuinely act on survives the switch: total and per-page traffic, trends over time, referrers and UTM-tagged campaign sources, search vs. social vs. direct splits, country and device breakdowns, and real-time "who's on the site right now." With a fuller cookieless tool you also keep Core Web Vitals (FCP, LCP, CLS, TTFB, broken out by page and device), scroll depth and time-on-page, custom events and conversion funnels from entry to goal, and engagement scoring. For the overwhelming majority of marketing and product decisions, that's the same toolkit you were using inside GA4 — minus the cookie.
What changes. A few things are genuinely different, and honesty here matters:
Net effect for a typical content, SaaS, or e-commerce site: you keep the numbers you make decisions with, you drop the friction, and your data gets more complete rather than less.
Removing analytics cookies is necessary but not always sufficient. The banner obligation comes back the moment anything else on the page stores or reads non-essential information on the device. Be honest about your own stack — this is exactly where the DevTools audit from Step 1 earns its keep.
You still need a consent mechanism if you run any of these:
youtube-nocookie.com domain, click-to-load wrappers, self-hosted alternatives), but the default embeds pull the trigger.The practical move is to sort your bucket-3 items into "can replace or configure cookieless" versus "must keep as-is." If you can get every remaining technology into the cookieless-or-strictly-necessary category, the banner goes. If even one ad pixel or cookie-setting embed has to stay, keep a properly-built consent banner for those specific technologies — but note that your analytics no longer contributes to that requirement, which often lets you simplify the banner to a single category. And if this section describes your site, that's fine: this guide still saved you the analytics-shaped chunk of your consent problem.
We're Null Agency, and we build GhostMetrics — so treat this as the vendor's own section, written to the same evidence bar as the rest of the page. It's cookieless and IP-less by design: no cookies, no consent banner, no visitor IPs stored, no personal data at rest. The whole tracker is public at /gm.js so you can verify every claim, and it honors Global Privacy Control and Do Not Track (those visits are never recorded).
Free is $0 forever with no credit card ever: one website, a real-time dashboard with unlimited pageviews, and every analytics view — geo, sources, funnels, vitals — with cookieless, banner-free tracking. Pro is a flat $9.99/mo (30-day free trial, card required to start it, and you're emailed before it ends) and adds unlimited websites, unlimited pageviews at a flat price with no metering, public shareable dashboards, and CSV export so there's no lock-in.
The self-referential proof: because it stores nothing, GhostMetrics can publish its own real, unfiltered traffic live — no signup required. Open the demo and you'll watch your own visit appear in real time while DevTools shows an empty cookie jar. That's the "no cookies" claim proving itself rather than asserting itself.
Start free — no card Watch the live demoHonest fit note: the dashboard is hosted and closed-source (only the tracker is public), and it runs on US Cloudflare by default with EU data residency available on request. If open-source self-hosting or strict EU residency is a hard requirement for you, we'll point you to Plausible, Umami, or Simple Analytics instead — no hard feelings.
The tools that let you drop the banner
Moving off Google Analytics 4
The legal debate, explained
GhostMetrics vs Plausible vs Fathom
How cookieless tracking works
Real, unfiltered traffic, no signup
This article is general information about how EU/UK cookie and privacy rules work in practice — it is not legal advice, and it doesn't create a lawyer–client relationship. Cookie and data-protection law varies by jurisdiction and by how your specific site is built. If your setup is complex, high-risk, or you're unsure, confirm your approach with qualified counsel before removing a consent banner. GhostMetrics is built and operated by Null Agency; we've described it against the same factual bar as every other tool mentioned here.