Your Analytics Are Undercounting You (And That's the Good News)

Your analytics are wrong. Not slightly — structurally, in a known direction, by an amount you can estimate.

This isn't a scandal and it isn't anyone's fault. It's the accumulated result of a decade of privacy engineering: ad blockers, Safari's tracking prevention, cookie banners nobody consents to, and browsers that have quietly stopped cooperating with the way third-party analytics was built.

The useful response isn't to panic about the number. It's to understand which way it's wrong, stop making decisions that depend on the missing part, and get the parts that still work right.

Where the traffic goes

Four leaks, roughly in order of size.

1. Ad blockers

A meaningful slice of visitors — the estimates range from 10% to well over 40% depending on the audience — run a blocker. And every one of those blockers ships with google-analytics.com and googletagmanager.com on the list. The script never loads. The visit never happens, as far as you're concerned.

The bias here is what makes it dangerous, and it's the part people miss. Ad-blocker use is heavily skewed toward technical, younger, higher-income users. So if you sell developer tools, your analytics may be missing half your actual audience, and the half it's missing is the half that matters. Your data isn't just incomplete — it's systematically unrepresentative of exactly the people you're trying to reach.

2. Safari, and cookie lifetimes

Safari's Intelligent Tracking Prevention caps client-side cookies at 7 days. In some configurations, 24 hours.

Which means: a returning visitor on Safari — a third-plus of mobile traffic in many markets — looks like a brand new visitor every week. Your "new vs returning" split is fiction. Your attribution window is a week long no matter what you set it to. Your loyal customer who visits monthly has been counted as twelve different people.

3. Cookie banners

Under GDPR, analytics cookies need consent. Consent rates run roughly 40–80% depending on how aggressively the banner is designed. Everyone who declines is invisible.

And there's a second-order effect: the more honest and less manipulative your banner is, the more data you lose. You are literally penalised in your own reporting for respecting people. It's a bad incentive, and the way out of it is to not need the consent in the first place.

4. Server-side and bot noise, in both directions

Bots inflate. Filters over-correct and remove real people. Single-page apps double-count route changes, or miss them entirely. Every one of these is fixable, and every one of them is silently wrong on a lot of sites right now.

The fix for most of this: first-party and cookieless

Two changes, and they solve different leaks. They're worth separating because people conflate them.

First-party means the tracking script is served from your domain, and the data goes to your domain — not to google-analytics.com. Blocklists work on domains, so a request to your own domain isn't on anyone's list. This recovers most of the ad-blocker leak.

Cookieless means you don't set a cookie at all. You identify a visitor for the purposes of "was this the same session?" without storing anything on their device. This means there's nothing to consent to under the cookie rules, no banner needed for analytics, and nothing for ITP to expire. That kills leaks 2 and 3.

How you count a visitor without a cookie

The mechanism is worth understanding, because it's where the honesty lives.

You take some things about the request — the IP address, the user agent, the site id, and today's date — and you hash them together into an opaque identifier. Same person, same day, same site, same hash. So you can count sessions and unique visitors within a day.

Tomorrow, the date changes, so the hash changes. The same human is a different identifier tomorrow, by design. You have deliberately made yourself unable to follow someone across days.

The critical engineering detail, which most descriptions skip: the hash must be keyed — an HMAC with a secret only you hold. Without a key, this offers no privacy at all. Think about what an attacker with a copy of your database knows: the date is obvious, the site id is public, and the user agent is narrowed to a handful of candidates by the device and browser columns you've stored alongside. That leaves only the IP unknown — and there are just four billion IPv4 addresses. That's minutes of brute force to reverse a "hashed" identifier back into an IP address. A plain sha256 here is not de-identification; it's the appearance of de-identification, which is worse, because you'll trust it.

The secret key is the thing doing the work. Everything else is decoration.

What you give up, honestly

This is a real trade, and anyone selling it as free is selling something:

• No cross-day user journeys. You cannot say "this person first came from Twitter in March and bought in June." You've made that impossible on purpose.
• No cross-device identity. Phone and laptop are two visitors.
• Multi-touch attribution mostly doesn't work.

Here's the thing though: most of that was already broken. ITP had capped your Safari cookies at 7 days. The ad-blocker users were never in the data. Your sophisticated 90-day multi-touch attribution model was running on a badly biased sample and reporting to two decimal places. Cookieless doesn't take away a capability you had — it mostly takes away a number you believed.

What you get in exchange is a count of pages, sessions and conversions that's closer to true and unbiased — the same for blocker users and non-blocker users, Safari and Chrome. For the actual questions you ask daily (what's growing? what's dying? did the fix work?), unbiased-and-approximate beats precise-and-skewed every single time.

What no analytics tool will ever tell you

Even with perfect measurement, analytics answers what and never why. It's the dashboard problem in its purest form.

"Your pricing page has a 78% bounce rate" is a fact. It supports at least five different explanations — price shock, wrong audience, slow load, broken mobile layout, an ambiguous CTA — and the number is exactly equally consistent with all of them. You cannot resolve it by looking harder at the number, and you certainly can't resolve it by adding another chart.

So pair it with the things that do answer why:

• Heatmaps and scroll depth — did they even see the pricing table, or does everyone stop at 40%?
• Conversion checks — is the CTA below the fold on a phone? Is the form asking for a phone number?
• Who they are — if you're B2B, the fact that the bounce was a competitor rather than a buyer changes the entire reading.

The metric localises the problem. Something else has to diagnose it. Confusing those two jobs is how people end up with six analytics tools and no answers.

The two questions worth asking of traffic data

Once the counting is honest, almost everything valuable comes from two questions.

"What's growing?" Pages trending up are telling you where the demand actually is — which is frequently not where you thought it was, and is nearly always more useful than a keyword tool's opinion. Find them and invest.

"What's dying?" A page that steadily lost 60% of its traffic over three months is a silent failure. Nothing broke. No alert fired. It just slid, and unless someone looks at page-level trends over a long window, nobody notices until it's gone.

This is why we report traffic as trends and losing pages rather than a wall of charts — the absolute number is nearly meaningless (it's approximate, and it's yours to compare only against itself), but the direction, per page, over time, is the whole signal.

What to do this week

1. Estimate your own leak. Compare your analytics sessions against your server logs or CDN request counts for the same period. The gap is roughly what you're missing. Most people find this genuinely shocking.
2. Stop trusting "new vs returning" if you have meaningful Safari traffic. It is not measuring what its name says.
3. Serve your analytics first-party. Biggest single recovery available, and it's a configuration change, not a migration.
4. Ask whether you need cookies at all. If you're not doing cross-day individual journeys — and most people genuinely aren't, they just have the capability switched on — you can drop the cookie, drop the banner, and get more data.
5. Look at page-level trends over 90 days, not sessions this week. That's where the dying page is hiding.

The goal isn't a perfect number. A perfect number isn't available at any price, and chasing it is a way of avoiding the harder question. The goal is a number that's wrong in a consistent, unbiased way — because that one, you can actually make decisions with.