Analytics without cookies: what you can still measure in 2026
Most company websites are measured badly, and the reason is circular: the site loads a tracker that needs consent, a banner appears asking for it, a third of visitors decline, and the numbers that come back are wrong in a way nobody adjusts for.
The way out is not a cleverer banner. It is to measure less, from your own server, and to know exactly what you gave up. This article is what we do on the sites we build, including this one.
What a consent banner actually costs you
Refusal rates vary by country and by how the banner is designed, but a business planning around “we lose a few percent” is planning around the wrong number. The share of visitors who decline is large enough that any funnel built on consented data is measuring a self-selecting group — and the people who decline are not a random sample of your audience.
That has a second effect nobody budgets for. If your analytics only sees consenting visitors, every comparison you make is against a moving baseline, because the consent rate itself changes with the banner, the browser and the season.
There is a third cost, and it is the one we care about most: a banner is friction on the first screen of a page you paid to bring someone to.
What you can measure with no cookies at all
More than most people assume. A cookie exists to recognise the same browser on a later visit. Everything that does not depend on that works without one:
- Pages, referrers and sources
- Which page was viewed, where the visit came from, which campaign brought it.
- This is the bulk of what a company website is actually judged on.
- What happened in this visit
- Which pages in what order, how long, whether the form was submitted.
- A single visit is one server session; it needs no persistent identifier.
- Conversions you own
- Enquiries, downloads, calls started, newsletter signups.
- These are recorded by your backend when they happen, and they are the most reliable numbers you will ever have.
- Performance and errors
- Core Web Vitals from real visitors, 404s, failed form submissions.
- Never needed a cookie in the first place.
What you genuinely lose
Being honest about this matters, because the vendors selling cookieless tools are not always.
Returning visitors. You cannot tell a second visit from a new one. Someone who reads three articles over two weeks counts as three people.
Multi-visit attribution. You will see the source of the visit that converted, not the six that came before it. For a considered purchase — which yours is, if a project takes months to decide — that means the last click gets all the credit and the article that started it gets none.
Individual journeys. No “this person read the pricing article, then came back and enquired”. You get aggregates.
If your business depends on the second one, say so out loud and accept a consent banner for it. What is not defensible is running a banner and still not using the data.
Decide what decision the number is for. If nothing changes based on it, you are collecting personal data to fill in a dashboard nobody acts on — which is the one thing the law is genuinely unimpressed by.
The MinCode team
How to set it up
Start from the conversion, not the pageview. Your contact form already knows when someone enquires. Log that on your own server with the page and the referrer, and you have the only number the business truly cares about, with no third party and no consent question.
Then add aggregate traffic. A privacy-focused analytics tool that stores no persistent identifier, or logs processed on your own server. Both give you pages, sources and trends. Both work for every visitor rather than the consenting subset.
Keep the third parties out of the first paint. Anything external that loads before the page has drawn is costing you LCP as well as privacy. If a tool cannot be deferred, ask what it is buying.
If you do add something that needs consent, gate it properly. Not “show a banner and load the script anyway” — which is what most implementations do, and which is worse than no banner at all. The script must genuinely not run until someone says yes.
What this site does
Worth stating, since we are giving advice: this site sets no cookies, loads nothing from a third party, and stores one value in the browser — whether you chose the light or the dark theme, written only when you click the switch.
That is not a boast about restraint. It is what happened when we asked, for each external thing, what decision it would inform. The fonts were the last third party to go; self-hosting them removed the only request that left this server.
We built the consent mechanism anyway. Its category list is empty, so no banner appears — and the day something is added that needs one, it appears on its own and the script does not run before consent.
A test you can run this week
Open your own site in a private window and watch the network panel while the first screen loads.
- How many requests go to a domain that is not yours?
- Which of those load before the page has drawn?
- For each one: what decision has it changed in the last six months?
The third question is the one that matters. Most tracking on most company sites survives because nobody has asked it, not because anybody uses the output.
How to know it worked
- Realistic target: every enquiry, call and signup recorded on your own server, attributable to a page and a source, for 100% of visitors — not for the fraction who accepted a banner;
- Watch: requests to third-party domains before first paint. The number should be zero, and if it is not, each one should have a name attached to who needs it;
- Success signal: you can answer “which page brings the enquiries” without qualifying the answer with “of the people who accepted cookies”.
Practical guides on automation, integrations and ecommerce — written by the engineers who apply them daily.
Let's talk about your project!
