Consent signals a year on: what broke in measurement

A year ago the deadline was the whole conversation. Google required the newer consent signals on EEA traffic for anyone using its audience and measurement features. Agencies sent identical warning emails. Most teams shipped the change in a fortnight, because the alternative was losing remarketing.

The tags went out, the banner was updated, the ticket was closed. What nobody scheduled was the follow-up conversation about what the numbers mean now.

Twelve months later that conversation is overdue in most programmes we look at. Reporting works, in the sense that charts render. It is the reconciliation that has quietly stopped. Analytics conversions do not match the order table, audience sizes drop without explanation, and country comparisons mislead in a way that is hard to see.

What actually changed in the plumbing

The mechanism is worth stating plainly, because a lot of teams implemented it without ever being told how it works.

Before consent, tags fire in a restricted mode. They send a signal describing what the visitor has and has not agreed to, without the identifiers that would normally accompany a hit. The signal carries separate flags for analytics storage, advertising storage and the use of data for personalisation. After consent, the full tag fires.

So the measurement platform receives something from a non-consenting visitor, but that something is not a row about a person. It is an input to a model. Google then estimates the conversions it could not observe, using the behaviour of consenting traffic as the training signal, and modelling requires enough volume to be produced at all. Smaller properties and smaller markets may see little of it.

None of this is a bug, and consent mode is the correct implementation under GDPR. The operational consequence is what matters: a growing share of your reported performance is an estimate, and estimates cannot be joined to a customer record.

The missing data is not missing at random

If consent were declined uniformly, you could scale everything up and move on. It is not. Consent rates vary by country, by device, by traffic source, by banner design and by whether the visitor arrived on a landing page or the homepage.

That makes every uncorrected cross-segment comparison suspect. A market that looks like it has weakened year on year may simply have a stricter banner and a lower consent rate. A device split that shows mobile declining may be showing a consent difference instead.

The practical response is to treat consent rate as a first-class reporting dimension rather than a tagging detail. We ask for it broken out weekly by market, device and landing template, and we look at it before we look at conversion trends.

Two rules follow. Do not compare markets on analytics-sourced conversion data without showing their consent rates alongside. Do not read a step change in performance until you have checked whether the banner, the consent library or the page template changed in the same week.

Estimates cannot be joined to a customer

This is the part that hits CRM hardest, and it is often discovered late, in the middle of building something.

A modelled conversion exists in an aggregate report. It has no customer key, no email address and no row in an export. You cannot put it in a warehouse table, you cannot use it to trigger a journey, and you cannot use it to build an audience of people who did the thing.

So any lifecycle logic that depends on analytics-derived behaviour has developed holes. Browse-based triggers fire for consenting visitors only. Audiences built on site behaviour are systematically biased towards whoever accepts banners. Segments defined on "visited the pricing page" quietly became "visited the pricing page and accepted cookies", which is a different population.

We spent a good part of last year deleting segments built on that foundation. If you have not done that exercise, it pairs directly with the work in pruning segments that nobody uses. A segment that cannot be reproduced from data you own is not a segment, it is a snapshot.

Report observed and modelled as two numbers

The most useful change we make in reporting is also the simplest. Split every analytics-sourced conversion figure into what was observed and what was estimated, and show both.

It takes an afternoon in most stacks and it changes the quality of the conversation immediately. When the marketing director can see that a third of a channel's conversions are modelled, the request stops being "why is CRM down" and becomes "what can we measure directly instead".

Alongside that, write down the attribution model you are actually using and note where it depends on modelled input. Most teams have never written it down, which means nobody can tell whether a discrepancy with finance is a definition difference or a data gap.

Then set expectations in advance. Paid channels lean harder on the modelled portion than CRM does, since email and app traffic often arrive with a known identifier. A CRM programme that looks weaker in the analytics tool than in the order table is usually being under-counted, not underperforming.

Rebuild the numbers you rely on from data you own

The long-term answer is to stop depending on third-party measurement for lifecycle questions. The data that survives consent decisions is the data a customer gave you directly, in a relationship they can see.

Where we concentrate effort:

• Order and subscription records. These are complete by definition. Cohort retention, repeat rate and revenue per customer should all be computed here and nowhere else.
• Authenticated behaviour. Events from signed-in sessions and the app carry a customer key and do not depend on a banner decision.
• Message engagement from your own platform. Sends, clicks, and downstream orders matched on the customer key rather than on a click parameter.
• Declared preferences. What someone tells you in a preference centre is first-party data with a timestamp and a source, and it does not degrade when a browser changes policy.

Server-side tagging helps here, but be honest about what it does. Moving tag execution to your own endpoint improves control, resilience and payload quality. It does not create consent you were not given, and treating it as a way around the banner is both wrong and a legal risk that will land on someone else's desk.

The conversation to have this quarter

Book an hour with analytics, media and legal in the same room, and answer three questions on paper. What share of our reported conversions is modelled, by market. Which lifecycle triggers currently depend on non-authenticated site behaviour. Which of our headline CRM metrics can be rebuilt entirely from order and message data.

The third answer is usually more encouraging than people expect. Most of what a CRM team is judged on can be computed from sources that no browser policy touches. The work is deciding to move it there before the next reporting cycle rather than after the next argument.