2026-08-03

Cookie banner free analytics: 6 steps to real traffic data

I put my first cookie banner on my own site and thought I had ticked off an admin task.

Then I opened the site on my phone.

A visitor searches for something. They land on my page. And what do they see?

A box covering half the screen, with two buttons they never asked for. They have not read a single line yet but they already have to decide something they do not understand.

Sound familiar?

I lived with it for a while. Then I compared the numbers. My server log showed clearly more visitors than my analytics did.

That makes sense. Anyone who rejects cookies or ignores the banner, never shows up in the stats.

So I knew nothing about my most privacy aware readers. Meanwhile I used those same numbers to decide what to write next. I kept the wrong topics. I fixed the wrong pages.

And every month I waited, I made another decision on distorted data.

Here is the good news. The way out is simpler than you think. Your site does not need a banner because it exists. It needs one because of what you put on it. Remove the cause and the banner goes with it.

This article shows you how, in six steps.

What a cookie banner really costs you

It takes two things from you. We usually talk about only one of them.

The first is user experience. The banner appears the moment someone arrives. It covers your content and asks for an action before you have given anything.

On mobile it takes half the screen. The consent tool is also a script so it slows the page down.

The second is measurement. This one hurts more, because you never see it.

If someone says no or says nothing, your system collects no data about them. You do not get an error. You get a smaller number that looks believable.

Do you want to know how big that gap is on your site? Do not guess. Check two things:

• Your consent tool statistics. Most of them show the accept, reject and ignore rates. This varies a lot by site and by audience so only your own number matters.
• Your server log or your hosting traffic report. Compare it with your analytics, for the same week. The two never match exactly but the size of the gap tells you a lot.

What happens in GA4 when someone says no?

It helps to understand the mechanism. It shows why configuring a consent tool does not fix everything.

Google Analytics stores an identifier on the visitor's device, in a cookie (these are the _ga cookies). That is how the system recognises the same browser again.

Sessions, returning visitors and most reports are built on it.

If the visitor does not consent, that identifier is never created.

Google offers modelling for this case. It estimates what the others probably did, based on the people who did consent. That is a defensible statistical method but you should know two things about it.

First, it is an estimate, not a measurement. Second, modelling only starts once enough data has come in so smaller sites are the ones left out.

With a few hundred or a few thousand visitors a month, the traffic of everyone who declined will simply be missing.

On top of that, GA4 hides rows in reports when too little data sits behind them. On low traffic you get empty tables even when something did happen.

The good news: the banner is not a legal duty, it is a consequence

Most people get this part wrong and everything depends on it.

No rule says that every website must show a cookie banner. Two separate things come together here.

The first is ePrivacy, the EU rule on privacy in electronic communications. Each member state implements it in its own national law. It says that you need prior consent if you store data on the visitor's device or read data from it.

There is an exception for whatever the service strictly needs: the cart, the login. Analytics does not belong there.

The second is the GDPR, which applies when you process personal data. An IP address and a device identifier count as personal data so you need a legal basis to store them and link them.

So the banner follows from two conditions. You store or read something on the device or you process personal data.

If neither is true for you, there is nothing left to ask consent for.

"We believe that privacy is a fundamental human right."

Tim Cook, CEO of Apple, at the data protection conference in Brussels, 2018

So the rule does not ban measurement. It protects the visitor from data being collected behind their back. If you collect nothing, you are not getting around anything. The situation the rule covers never arises.

One honest note. This is not legal advice. Your own case also depends on the other services you run. The steps below are there so you can check it on your own site.

Six steps to get rid of the banner

1. Make a list: what sets a cookie on your site

Open a private window and load your site. Do not click the banner.

Open the developer tools (F12), then the Application or Storage tab and inside it Cookies and Local storage. Write down what you find.

Then check the Network tab too. Look at which external domains get a request. You often find the forgotten one there.

2. Separate what you need from what tracks

Split the list into two columns.

The first one holds your session cookie, the cart, the login, the language choice. These are needed to run the site so you do not have to ask consent for them.

Everything else goes into the second column: analytics, ad pixels, A/B testing tools, heatmaps, chat.

You get rid of the banner when that second column is empty.

Still with me? The hard part is done. The remaining four steps go faster.

3. Swap your analytics for a cookie free one

This is the biggest item on the list. And usually the only one that really matters to you.

There is a sensible alternative: measurement that stores nothing on the visitor's device and builds no profile from it.

In return you get exactly what you look at every day. How many people came, where they came from, what they read, which campaign brought them.

4. Handle embedded content

An embedded video, a map or a chat widget will set a cookie even if you put nothing out yourself.

Here is what you can do:

• For video, use the cookie free embed mode. Or show a preview image and load the player only on click.
• For maps, a static image with a link to directions is often enough.
• For chat, load the widget only when the visitor clicks the bubble. That also helps your page speed.

5. Remove the banner and its script

Once the second column is empty, the consent tool has no job left.

Do not just hide it. Take the code out, because it keeps loading and slowing you down while it sits there.

6. Verify, then rewrite your privacy notice

Repeat step one in a private window. If Cookies and Local storage are empty, you are done.

Do not forget your privacy notice. Write down what you measure, why, where the data sits and that you use no cookies.

That is two paragraphs. It is also the first thing an audit looks for.

What you actually give up

It would not be fair to claim you lose nothing. Here is what goes:

• Cross device linking so you cannot tell that the same person came on mobile and on a laptop.
• Ad retargeting so remarketing. If you build those audiences, you still need consent and a banner with it.
• Individual visitor profiles so what one specific person did on your site over months.

What stays: visitor counts, traffic sources, top pages, campaign performance, journeys and drop off.

Let us be honest. That is exactly what you use for your daily decisions.

Where StatJolt fits in

I built StatJolt for this situation.

It sets no cookies and writes nothing to the visitor's device, because it does not need to. It collects no personal data so there is nothing left to ask consent for.

Two lines of code. The servers sit inside the EU, in Germany and Finland.

In practice, you swap the tracking code at step three, remove the banner at step five and the next day you see the traffic that was always there but never showed up.

The script is also a few kilobytes. Together with the consent tool, your load time drops as well.

The short version

A cookie banner is not a legal duty. It is the consequence of a tool that wants to store something on your visitor's device. Remove that cause and you get back both the user experience and the traffic you could not see.

Back