Website analytics — what your numbers do when people refuse cookies

Companies treat the consent banner as a legal formality: you have to have one, so it gets pasted in and forgotten. An expensive mistake, because the banner is not a legal layer laid over the measurement — it is the layer that decides the measurement.

How it is built and what exactly it switches off determines how many of your visitors appear in the reports at all — and therefore whether any decision taken on those reports means anything.

This is about the architecture of measurement: what happens to the data after somebody clicks reject, what Google will not do to make up for it, and how to set consent up so you are not losing data for no reason. If you want instead how to read the numbers you already have, that is a separate article — on the four ways a report can lie.

Website analytics — four layers where something can break

Before consent, take apart what companies call by one word. Four separate layers, each with its own way of failing — and most conversations about "bad data" are about a different layer from the one the participants have in mind.

Collection. The site sends events: somebody arrived, scrolled, clicked, submitted a form. What breaks here is that the event is not sent at all, or travels under a name nobody is listening for.

Consent. Between collection and everything else sits the visitor's decision. This is the layer the whole article is about, because it decides how much of layer one travels any further.

Processing. Events reach a tool that groups them into sessions, users and conversions. What breaks here is double counting and the inclusion of your own traffic.

Reporting. Only at the end does a number appear that somebody looks at — and it is the only layer you can see, which is why every problem from the previous three looks like a problem with the report.

So: if the numbers look strange, do not start with the report. Start with layer one and work down. The report is almost never where something broke — it is where you can see it.

A tag manager — what it is actually for

The second word that comes up in every conversation about measurement and is rarely explained. A tag manager is an intermediate layer between your site and the tools that are supposed to receive data.

Without it, every tool needs its own snippet pasted into the pages, so adding anything requires a developer and a deployment. With it, the site sends events to one place and that place distributes them by rules set in a panel.

For a company that means three things, the second and third usually left unsaid:

• Changing the measurement stops requiring a deployment. A genuine saving of time and the main reason to use one.
• It creates a place where everything can be broken at once. The rules are powerful and pass through no code review. Access to a tag manager is therefore administrative access, not "access for marketing".
• It is where consent is configured. The declaration of what consent each tag requires lives in this layer — and it is where it is most often missing.

If you do not know who has access to your tag manager, that is the first thing to establish, before any conversation about data.

What happens to the measurement when somebody clicks reject

Consent Mode is a mechanism in which Google's tags are not simply switched off on refusal but change behaviour. With consent, measurement runs with an identifier — it is known that the same person came back three days later. On refusal, a cookieless signal is sent: no identifier, no recognition of a return.

The data does not disappear entirely, but it stops joining up. The same person who arrived from an ad on Monday and sent an enquiry on Thursday is now two unrelated events. The report still shows traffic. It stops showing the path.

For an advertiser in Poland, as in the whole EEA, this is not an architectural preference. Since March 2024 Google has required Consent Mode v2 signals for remarketing audiences and conversion measurement in its ad products — without them those features stop working, whatever the rest of the setup looks like.

The second, less understood consequence is losing the denominator. A conversion rate is a ratio — if the numerator and the denominator are collected under different consent conditions, the result stops being a percentage of anything. Which is why, where refusals exist, there is no sense in comparing "conversion" between months in which the banner changed.

The modelling a small business will never get

Here comes the sentence everyone hears when they ask about the hole in the data: "Google will model that." And it is true — under conditions almost no small company website meets.

Behavioural modelling in GA4 has hard entry thresholds: the property must collect at least 1,000 events a day with consent denied for a minimum of 7 days, and have at least 1,000 users a day with consent granted on 7 of the last 28 days. Meeting both guarantees nothing — the model has further criteria, among them the ratio of new to returning users.

To show the scale we use our own figures, because we cannot verify anyone else's:

Our own company site runs close to two orders of magnitude below that threshold. The units are not identical either, because Google counts users and events while we count sessions — but no correction of units closes a gap of that size. We publish the proportion rather than the volume, and the proportion is the part that decides the question.

The conclusion worth stating plainly, because tool vendors do not: on a typical company website there will be no modelling. Data you did not collect because of a refused consent is lost permanently. There is no mechanism that reconstructs it later — so the only thing to do is not lose it unnecessarily. The rest of this article is about that.

What to do instead when traffic is small

If there will be no modelling, the question tool vendors usually leave unanswered is: what then. There are three routes and each has limits worth knowing.

Count in aggregate, without an identifier. A counter that records how many times a page was opened without tying it to a person or recognising a return. It will not replace analytics — nothing about paths or returning visitors — but it gives you a denominator, a number everything else can be set against. On a small site, often the single most valuable figure available.

Move to an analytics provider that keeps the data in Europe. Two routes. The first is tools installed on your own server rather than used as a service — best known, Matomo. The second is a service with a declared EU data location: Piwik PRO, the closest to us because it is a Polish company, and its Business plan includes a consent module, precisely the layer this article is about. Checked at the vendor on 9 September 2026 and converted at the NBP rate of the same day (table 175/A/NBP/2026, euro at PLN 4.3171): Business from €36/month — about PLN 155, up to 2 million actions a month across a maximum of 20 domains with 25 months of retention, thirty-day trial, no card. Above it, Enterprise from €366/month billed annually — about PLN 1,580 a month. There is no free plan. Business data sits in a cloud in Sweden; Enterprise lets you pick the data centre, including Germany and the Netherlands.

Worth knowing what that does not solve, because it is sometimes sold as if it did. Changing provider does not remove the consent obligation — exactly as with server-side tagging, below. EU-located servers solve a different problem: transfers outside the EEA, not whether you may write an identifier onto a visitor's device.

Count outside analytics. Phone calls, emails, form enquiries, messages from a Google profile. Data you have regardless of consent, because it arises from contact rather than tracking. At a dozen or so contacts a month a hand-kept table is often more accurate than analytics — not a joke: at that scale every contact can be attributed with one question, "how did you hear about us".

These routes do not exclude one another; for a small company the first and third together usually make sense.

Three consents, not one

The commonest error in the implementations we look at is also the easiest to fix: consent is treated as a single switch. The visitor clicks reject and the whole of analytics goes off along with advertising tracking.

That is a loss with no justification, because people refuse these things to different degrees. Objection to advertising profiling is far more common than objection to plain visit counting — and a single switch welds both decisions into one.

In a correctly built setup, every recipient of data declares what it requires:

The rule we apply here: refusing marketing consent must not switch off analytics consent, or the other way round. That is simultaneously a matter of compliance with the ePrivacy rules (in Poland, the Electronic Communications Law — Prawo komunikacji elektronicznej) and — from the angle companies usually care about more — a matter of whether any denominator survives in the report.

The banner that inflates its own score

There is one more mechanism that quietly ruins data while looking like a success: the asymmetric banner. The kind where "Accept all" is one click on a highlighted button while refusing requires opening settings and unticking three toggles.

Such a banner raises the formal consent rate. That looks like good news and is often reported as such. In reality some people accepted because it was quicker, not because they wanted to.

Two consequences, both bad for the company. The first is formal: the guidance of European data protection authorities (the EDPB) and of Poland's UODO (Urząd Ochrony Danych Osobowych) points clearly towards symmetry — refusing must be as easy as consenting — a direction to be ahead of rather than behind. The second is practical and less obvious: consent forced by button layout inflates your own metric, so you also lose the ability to notice something is wrong. A company with "92% consent" will not ask itself about the quality of its measurement.

An honest banner with a real rate around sixty per cent is a better basis for decisions than a forced one at ninety — because you know what the first one is worth.

Server-side does not remove the consent obligation

This is the commonest myth sold with server-side tagging, and it deserves its own paragraph, because it is often presented as the main benefit of the work.

Server-side tagging does give you real things: fuller control over what leaves your site, less dependence on in-browser blocking, better conversion data quality. What it does not give is exemption from consent. The obligation arises from processing a visitor's data, not from which machine that data passes through. Moving a tag from browser to server changes nothing.

Practically: if somebody proposes server-side as a way to "get around the banner", they either do not understand what they are selling, or they do and are counting on you not to. Ask outright on what legal basis the data of people who refused is to be processed.

Auditing what you already have — five things to check

If analytics on your site has been running for years and nobody has looked at it since, start by checking rather than rebuilding. Five things, in order of frequency — all checkable without writing code, though some need a person with tag manager access.

1. Whether the events have a recipient. Surprisingly often a site sends events nobody receives: the name is generated, reaches the tag manager and stops there, because no tag passes it on. The report shows nothing, and it looks like a missing event rather than a missing receiver. Check by comparing the names the site sends against the tags that receive them.

2. Whether the tags declare a required consent. A tag that declares nothing fires after a refusal too. That is the class of error that is simultaneously a formal risk and a reason the data cannot be trusted.

3. Whether conversions are counted twice. If the same event travels two routes — browser and server — with no shared event identifier, both count separately. The report then shows twice as many conversions as happened, and every decision based on cost per acquisition is overstated by half.

4. Whether your own traffic is excluded. Visits from your computers, from the supplier and from monitoring tools stay in the data permanently if nobody filtered them out on the way in.

5. Whether anybody reads the reports. Not a technical question, but it decides the value of the other four. Measurement nobody reads is a cost, not a tool.

An honest note: we find these things at our own end too — our own tagging audit produced a list to fix. That is the normal state of an implementation that has lived a few years and passed through several people, not evidence of incompetence. What matters is that the list exists at all.

What to set up at implementation so you are not fixing it later

Four decisions that cost nothing on a new Google Analytics for a website setup and a great deal to reconstruct afterwards:

• Separated consents from day one. Adding this later means going through every tag and checking each one individually.
• A shared event identifier, if anything is to travel two routes. Without it deduplication will not work, and you will discover that only once you start comparing reports with reality.
• A filter for your own traffic, before the site goes to production. Data already collected cannot be cleaned retrospectively.
• A written list of events — what we send, at which moment and what for. One page of text that in two years saves a week of somebody's life unpicking it. It usually does not exist.

The technical name for that set is a measurement plan, and it sounds more serious than it is: a table with the columns "what", "when" and "why". An implementation without one is possible, but every later question about the data starts with archaeology.

What this means for a small business

Four things, cheapest first:

Separate the consents. Analytics apart from advertising. That is a setting, not a project, and it recovers the denominator from the people who do not want ads but have nothing against visits being counted.

Make refusing as easy as consenting. One button next to the other, on the first screen. You will end up with a lower consent rate, and that is good news, because from that moment the number means something.

Find out what it actually is. One of those figures almost nobody knows about their own site, and without it every report is read wrongly, because you do not know by how much it understates.

Do not plan on modelling. At your scale there will be none. Everything that is to be measured has to be measured for real — or counted another way, outside analytics: the phone calls, emails and form enquiries you have anyway. Though it is worth first checking that those enquiries arrive at all, because a silent form failure looks exactly like a lack of interest in the report — how to test that.

And one last thing, beyond the tools: some contacts will never appear in any report, because they come from a referral or a conversation. Measurement is there to narrow the area of guesswork, not to pretend there is none. Where contacts actually come from, we broke down using our own data.