Consent banners are eating your analytics
A third of this client's audience never appeared in the numbers they were making decisions from. Here is where it went, and how to measure without losing it.
We care about your privacy.
Everyone says it, nobody means it.
Last month I ran a cookieless setup alongside a client's existing, consent-gated analytics: same site, same period, two counts. Their tool reported 173 visitors. Mine reported 257.
Eighty-four people used that site and left no trace in the only record anyone was looking at.
That gap would still be survivable if it were random. It is not. The people who decline a banner skew more privacy-conscious, more likely to be on Safari or Firefox, more likely to be technical, which for a B2B site is frequently the exact audience you care about. You are not measuring a smaller version of your traffic. You are measuring a skewed version of it, and every decision you take downstream inherits the skew.
The same tool lies in both directions
I run this comparison on sites in Europe and in Australia, and the gap does not just differ in size. It goes opposite ways.
On European sites the consent-gated tool lands around a third below the cookieless count, month after month. The case above is not an outlier, it is the pattern. Australian sites do not need a banner for analytics, so the same tool runs unimpeded, and there the number is too high. Nothing much is removing the traffic that was never a person.
One market hides a third of your customers. The other counts machines as customers. Neither number is the one you think you are reading.
What Safari and Firefox actually do
It is tempting to say privacy browsers simply hide those visitors. That is half right, and the wrong half matters, so it is worth being exact.
Firefox does not block analytics by default
On its standard setting, analytics runs normally. Strict mode blocks trackers in every window, and private browsing blocks first-party ones too. In both of those, the session genuinely never appears. The default is not the problem; the people who changed the default are.
Safari rarely drops the visit. It drops the identity
Intelligent Tracking Prevention caps any cookie set by JavaScript at seven days, and at twenty-four hours when the visitor arrives on a link carrying a click ID. The visit is still counted. The person is not remembered, so a returning customer arrives as a new visitor and your returning-visitor and retention figures are quietly wrong in a way nothing flags.
And on the other side, bots
Every analytics tool filters bots, and I am not going to pretend mine does something categorically cleverer. GA4 matches against the IAB Spiders & Bots list; mine matches against a maintained crawler library that covers declared bots and the common headless-browser signatures. Both are reading the user agent, and both share the same blind spot: a headless browser sending an ordinary Chrome user agent from a residential address is invisible to either.
The difference is not the rule, it is that I can see it and change it.
In GA4 the bot filter is not a setting. You cannot inspect what it removed, you cannot turn it off, and you cannot re-run it over last quarter when a new pattern turns up. Here every event carries a flag, so I can audit what was excluded, re-classify a month retrospectively when something slips through, and tighten the rule the week it starts mattering rather than waiting for a vendor to ship it.
That is what brought the Australian numbers down: not a smarter detector, but the ability to look at what was being counted and act on it.
The banner is not about collecting data
This is the part that took me longest to properly understand, and everything else follows from it. The banner is not triggered by learning things about your visitors. It is triggered by storing or accessing information on their device.
That distinction comes from ePrivacy, Article 5(3) of Directive 2002/58/EC, which is a separate instrument from GDPR. GDPR governs what you may do with personal data once you hold it. ePrivacy governs whether you may put anything on someone's device in the first place, and it is the one that produces the banner.
A cookie is storage on the device. So is localStorage,
sessionStorage, an IndexedDB record. Read a device fingerprint and
you are accessing information on the device. Every one of them trips the same
wire.
Which implies something useful: a system that never writes anything to the visitor's device and never reads anything from it does not engage the rule at all. Not "we claim legitimate interest". Not "our banner is small and polite". The trigger never fires. That is not a loophole. It is the shape of the regulation.
So the platform stores nothing
Cookieless is easy to claim and harder to do, so here is the entire identity mechanism. There is no fourth step.
The request arrives
A visitor loads a page. Their IP address arrives with the request, as it must for any web request to work at all.
It is used in memory
The IP is read to derive an approximate location, the organisation behind the network, and a hash salted with a key that changes daily.
Then it is gone
The raw IP is discarded and never written to disk. Because the salt rotates every day, yesterday's hash cannot be matched to today's visitor.
Sessions can therefore be counted accurately within a day, and nobody, including me, can reconstruct who a visitor was afterwards. No banner is required, because nothing was stored to consent to.
What it costs
I would rather you hear the trade-offs now than discover them in month two. They are real, and for some businesses they are disqualifying.
What you give up
- Cross-device identity
- Someone who reads on their phone and converts on a laptop counts as two visitors. Any tool claiming otherwise is storing something on a device.
- Individual profiles
- You cannot look up what one specific person did last Tuesday. That is the point, but it does mean no user journeys in the CRM sense.
- Retargeting audiences
- Nothing here feeds an ad platform. If your growth depends on building custom audiences from site behaviour, this replaces your reporting, not your ad stack.
- Long-range visitor identity
- Because the salt rotates daily, a visitor returning next week counts as new. Traffic trends are solid; individual retention curves are not available.
For most of the sites I work on these cost nothing in practice, because nobody was using cross-device identity anyway. They were opening a dashboard once a quarter and squinting at it.
The part I did not plan for
Referrals started arriving from chatgpt.com. Then
perplexity.ai. People were asking an assistant a question, being
pointed at a client's site, and turning up. In most analytics tools those land
in a bucket marked "Referral", or get folded into "Direct", and you would never
know it was happening.
Splitting AI assistants into their own category took an afternoon, because I own the code. It is now a line on every monthly report, and for some clients it is among the fastest-growing sources they have.
The platform is not the point
Most analytics ends with a dashboard nobody opens. The measurement is the instrument; the useful part is somebody reading it. That is the part I do: monthly, in writing, what moved, what did not, and a short list of what is worth fixing, ranked by what it is worth against what it costs.
If a banner is quietly removing a third of your data, that is the first thing worth fixing.
How BTOP Analytics works