Consent Mode and Cookieless Measurement: What Survives When the Visitor Says No

A hundred people land on your pricing page. Thirty-eight decline the banner. GA4 still reports a number, Google Ads still reports conversions, and nobody in the room can say which figures were counted and which were estimated. That gap is where European B2B reporting quietly becomes fiction.

Server-side capture covers collecting first-party events under the DSGVO. This covers the other half: what happens to measurement when consent is absent, and what you may claim about it.

Consent Mode is a signalling protocol, not a consent tool

Consent Mode does not ask anyone anything; your consent management platform does that. It is how the answer reaches Google's tags, as four parameters: ad_storage, analytics_storage, ad_user_data and ad_personalization. The v2 release added the last two, splitting permission to store identifiers from permission to send user data to Google and personalise on it.

The mechanics matter more than the naming. A default state must be set before any tag loads, usually denied for EEA traffic, and an update fires when the visitor chooses. Set the default late and tags fire in the unconsented window, the commonest defect and the easiest to find: load the site with the network tab open and watch whether anything leaves before you click.

Basic and advanced differ in what leaves the browser

In basic implementation, tags do not load until consent is granted. A visitor who declines is invisible: no request, no ping, nothing. It leaves the platform with no denominator.

In advanced implementation, tags load on every page and send a cookieless ping when consent is denied. That ping carries no identifiers and no ad click data, only that an event occurred and the consent state at the time. The platform then knows how many unconsented events happened, which is what it needs to estimate the ones it could not observe.

Choosing between them is a real decision, not a technical detail. Whether that ping is lawful in your context is a question for your data protection officer, not a vendor's documentation. A provider who has only ever implemented one of the two is guessing.

Conversion modelling estimates a ratio, then applies it

Modelling is often described as the platform "recovering" lost conversions. It recovers nothing. It observes the relationship between consented traffic and consented conversions, then applies a version of that ratio to unconsented traffic it can count but not identify, adjusting for device, browser, time of day and campaign.

That is directionally useful for optimisation and structurally unverifiable. If unconsented visitors behave differently, and in B2B they probably do, since the people declining cookies skew technical and security-conscious, the ratio applied is the wrong ratio, and no amount of volume fixes a biased base.

Platforms also will not model below a volume threshold. The published figures have moved more than once but sit around several hundred ad clicks per country and domain over a rolling week, and most German B2B advertisers running one campaign in one country are under it. If your account never crosses it, modelling is off and you are losing the unconsented conversions outright, which is worth knowing before you blame a decline on the market.

A modelled number in a board deck needs a label

Observed and modelled figures must never land in one cell without a note saying what the cell contains.

The rule: platform-reported conversions, modelled or not, are an optimisation signal, and CRM opportunities are the number that goes to a board. When they disagree the CRM wins, and the gap is worth reporting on its own, because it says how much of your paid picture is inference. Reconcile the two monthly for the same campaign and period, and put both on the slide.

The legal line is the device, not the server

This distinction gets muddled constantly, and it changes what you may build. The TDDDG, Germany's implementation of the ePrivacy rules, governs storing information on, or reading it from, the user's terminal equipment. Consent is required, with a narrow exception for what is strictly necessary to deliver a service the user requested. It covers cookies, localStorage and device fingerprinting, and it does not care whether the instruction came from JavaScript or from your server's Set-Cookie header.

The DSGVO governs processing personal data, with six possible legal bases, of which consent is one. A server log of a request you received is processing, not device storage, and the question there is whether you have a basis for data that is personal, which an IP address generally is.

So an aggregate, non-identifying count that stores nothing on the device sits in a different legal box from a first-party cookie set by your own server. The second needs consent, which is why server-side tracking is not a consent workaround.

Consent rates in Europe, honestly

A banner where "reject all" is as prominent as "accept all", which is what German authorities require, typically produces acceptance between 50 and 70 per cent for a general B2B audience. A technical or developer audience runs lower, often 30 to 50 per cent, because ad blocking and refusal correlate with the job.

Those are working ranges, not findings. The ten-minute check: put your consent platform's count of consented sessions next to your server-side count of total sessions for the same week. That ratio is your real consent rate, and it is usually lower than the dashboard suggests, whose denominator is banner impressions and misses everyone who scrolled away.

What is still measurable when nobody consents

More than teams assume.

Server-side aggregate counts. Your infrastructure knows how many requests hit the pricing page and how many form submissions arrived. In aggregate, with no per-device identifier, that is a clean trend line. It cannot tell you who, and for channel-level trends you rarely need to.

Self-reported attribution. One required field on the demo form, a short option list plus free text, captured with a submission you already have a basis to process. Unfashionable, biased toward recent memory, and at B2B volumes more informative than anything modelled. It is also the only measurement that sees the podcast and the colleague's recommendation.

Holdouts. An incrementality test compares two groups in aggregate and never identifies a person, so consent state is irrelevant to it. As consented coverage falls, experiments get relatively more valuable, not less.

CRM outcomes. Once someone becomes an opportunity you are processing on a contractual or legitimate-interest basis, and the pipeline record is unaffected by whether they accepted a cookie eight months earlier.

Where this approach runs out

Consent state solves gating, not truth. You can record consent perfectly on every event in your signal ledger and still have a paid channel you cannot measure, because 40 per cent of its clicks declined and the platform will not model at your volume. Lean on aggregates and experiments rather than pushing the banner into a grey area for a few points of coverage.

None of this is legal advice. Supervisory authorities differ in how they read these rules, and the choices above have compliance consequences. Have your data protection officer or counsel sign off the consent defaults, the basic-versus-advanced decision and the retention periods before anything goes live.

Frequently asked questions

What is Google Consent Mode v2?

Consent Mode v2 passes a visitor's consent choices to Google's tags through four parameters: ad_storage, analytics_storage, ad_user_data and ad_personalization. It does not collect consent itself; your consent platform does. A default state must be set before any tag loads, and an update fires when the visitor chooses. In basic implementation tags do not load without consent; in advanced they load and send identifier-free pings that let the platform model.

Are modelled conversions real conversions?

They are estimates, produced by applying the observed relationship between consented traffic and consented conversions to unconsented traffic the platform can count but not identify. They are useful for steering bids, unverifiable at the individual level, and biased if unconsented visitors behave differently, which in B2B they probably do. Treat them as an optimisation signal and use CRM opportunities for the board.

Does server-side tracking mean I do not need consent?

No. German rules on storing or reading information on a user's device apply whether the instruction came from browser JavaScript or your server's response header, so a server-set cookie still needs consent. Separately, processing personal data such as an IP address needs a legal basis under the DSGVO. What server-side capture improves is your ability to record consent on every event and gate each destination on it.

What consent rate should a European B2B site expect?

With a compliant banner where refusing is as easy as accepting, a general B2B audience commonly lands between 50 and 70 per cent acceptance, and a technical audience often 30 to 50 per cent. These are working ranges, not benchmarks. Measure your own by comparing your consent platform's consented session count against your server-side session count for the same week, a more honest denominator than banner impressions.