Cookieless visitor counts: how accurate are they?

Our script doesn't set cookies by default. Whenever that comes up with a new customer, the first reaction is almost always: "So are the numbers still accurate?"

It's a fair question and deserves a proper answer. The short version: most metrics are barely affected, and a few should be read a different way. Here is the longer one.

What the cookie was doing in the first place

A traditional analytics script writes a cookie in the visitor's browser holding a random ID. When the same browser comes back with the same ID, the system knows it's a returning visitor.

Sounds reliable. In practice that ID goes missing all the time:

• Visitors clear their browser data or browse privately.
• Browsers cap cookie lifetimes themselves; some major browsers keep script-set cookies for only a few days.
• One person on a phone and a laptop already has two IDs.
• More and more regions require consent before setting cookies, and people who decline get no ID at all.

So "cookies make it accurate" was always a discounted promise.

How visitors are told apart without cookies

When a request arrives, the collector combines the site, the request's network address and browser details with a random value only the collector knows (a salt) and computes a digest. The same person on the same network and browser produces the same digest for as long as the salt stays the same, and is counted as one visitor.

The IP address is used for that calculation and then thrown away. It's never stored.

What's barely affected

Pageviews, sessions, events. These count occurrences; how people are recognised doesn't enter into it.

Shares by source, page, device and region — "32% of visits come from organic search", for instance. As long as any error is spread evenly across sources, the shares don't move.

Conversion within a visit. Landing page to sign-up happens inside one visit and needs no recognition across days.

That covers most of the numbers most teams look at every day.

What can be skewed

Unique visitors across days

Someone visits on Monday on home Wi-Fi and on Tuesday on the office network. The network address changes, so does the digest, and they count as two people. Weekly unique visitors can run high.

By how much depends on your audience. Products for office workers who move between networks a lot see more of it; products used mainly at home on one network see less.

New vs returning

For the same reason, some returning visitors look new, so the new-visitor share runs high.

Many people behind one address

Schools, large companies and some mobile networks put many people behind one outgoing address. If they also happen to use the same version of the same browser, they can merge into one visitor — undercounting this time.

In real data the overcount and undercount partly cancel out, but you can't count on them cancelling exactly.

So how should you read the numbers?

Use counts for trends

To judge whether traffic is up or down, or whether a channel is good or bad, sessions and pageviews are enough — and steadier than unique visitors.

Answer cross-day questions with signed-in users

"How many people came back three or more times last month?" "What's day-7 retention for new users?" If your product has sign-in, the most accurate answer comes from signed-in users, not from any browser identifier. With identity mode on, your user ID is linked at sign-in and phone and laptop visits merge into one person, recognised across days and devices.

For content sites without sign-in, accept that cross-day unique visitors are an estimate, and watch their trend rather than the absolute number.

When reconciling with another tool, agree on definitions first

If you also run a cookie-based tool, visitor counts that don't match are normal. Neither is "the real number of people"; they are two estimates made differently. Compare sessions or pageviews first — those are usually much closer between systems.

Why we still default to no cookies

Because what you get in return is concrete:

• Nothing is written to your visitors' browsers, so your site has one fewer tracker to explain in its privacy policy.
• In many regions, analytics that sets no cookies and does no cross-site tracking faces much lighter requirements. What applies to you still depends on local law and the other tools on your site.
• A visitor who declines your consent banner doesn't disappear from your data entirely.

Trading a little cross-day precision for less compliance work and more complete visit data is a good deal for most websites. If your business genuinely needs to recognise people precisely, switch on identity mode and count by signed-in user — that's more reliable than any cookie ever was.

Related articles

Privacy & compliance·Oct 12, 2026·4 min read

Does website analytics need a consent banner? Break it down by region and method

Whether you need a banner depends on three things — where your visitors are, what you collect and what else runs on your site. A framework to structure the question, not legal advice.

Read article

Product notes·Oct 16, 2026·3 min read

Why bot traffic gets its own report

By default we take identified bots out of your human reports rather than dropping them or mixing them in. The three reasons behind that, and what it means for your numbers.

Read article

Playbooks·Oct 14, 2026·5 min read

Checkout drop-off: a seven-step investigation from data to fix

Plenty of add-to-carts, not many payments. A checklist to work through in order — rule out technical problems first, then find which step, which visitors and what cause.

Read article