Incrementality testing under GDPR: consent, holdouts and small European markets

Your consent setup decides which tags run and what they send. That changes the data a test can rely on. We do not summarise the law here. Three layers are in play.

ePrivacy and GDPR. The European Data Protection Board adopted guidelines on the technical scope of Article 5(3) of the ePrivacy Directive (version 2.0, 7 October 2024). Their use cases include URL and pixel tracking, tracking based on IP only, and unique identifiers¹. What that means for your tags and your banner, your counsel decides.

Google's rules for advertisers. Google's help article on its EU user consent policy says advertisers must collect consent from end users in the European Economic Area and pass consent signals to Google to keep using its tags for measurement, ad personalisation and remarketing. It names two separate consent signals, one for sending user data to Google for advertising and one for ad personalisation². If you run Google Ads in Europe, read that policy with your counsel.

Your own consent banner. Whatever visitors choose in the banner flows into what your tags collect. Visitors who decline drop out of user-level reports, or appear only as modelled estimates.

The practical result: fewer people appear in tag-based data than actually visited and bought. A test that depends on that data sees a smaller and possibly skewed slice of the audience.

A user-level holdout test splits an audience into a group that sees ads and a group that does not. To read it, you need to know who was in each group and who bought. That depends on identifying people, so consent matters a lot.

A geo test works differently. Ads are switched off, or changed, in selected regions, while control regions show what would have happened. You compare aggregated sales between regions and periods. Google's Meridian GeoX documentation lists holdback, go-dark and heavy-up as tailorable geo designs³.

Our reasoning, not a legal view: sales totals by region come from your own orders. You do not need to follow individual visitors through a banner to read them. So a geo test reduces dependence on user-level tracking.

That does not settle the legal question. Regional totals start as individual customer orders, and how you collect, store and combine them is a data-protection question. Your counsel decides whether anything in your setup needs attention. If your order system already holds first-party data, such as orders and accounts, that is where a geo test reads its results from.

Do you need consent to run a holdout test? We do not answer that, and neither should your agency. A geo test on regional order totals and a user-level test built on tags collect different data. Take your specific design to your counsel. Your counsel decides.

Europe is many markets, not one. Languages, shipping zones, currencies and shopping habits change at borders. That helps and hurts.

It helps because country borders can make natural test regions. A country is a clean unit that people understand.

It hurts in two ways.

• Small markets are noisy. A small country has fewer orders per day. A smaller sample makes it harder to tell a real effect from random swings. A test may end as "can't tell". That is a proper result, not a failure.
• Cross-border buying leaks. Shoppers near a border may see ads in one country and buy in another. Ads can also reach people who live in a control region through shared languages or travel. That is spillover: ads reaching the other group, which distorts the result.

Can you run geo tests in small European markets? Yes, but with limits. You may need to group countries or regions, test for longer, or accept that only a large effect will show. Pick regions that share little language and few delivery links. Check where orders actually ship. For the steps, see how to run a geo holdout test.

Example (illustrative): A brand sells in two neighbouring countries that share a language. It switches ads off in one and keeps them on in the other. Customers browse in one country and order from the other. The control group is partly exposed, and the measured effect shrinks. Choosing regions that do not share a language would reduce that leak.

Consent Mode is a Google mechanism that passes the visitor's consent choices to Google tags. The tags then change how much data they send. Google's Tag Manager documentation describes two implementations. In basic mode, tags do not load until the visitor interacts with the banner, and nothing is sent if consent is denied. In advanced mode, tags load and send cookieless pings while consent is denied, and Google uses those pings to model the missing metrics⁴.

Those modelled conversions are estimates. They are not orders you can see in your shop.

Google's GA4 documentation sets prerequisites for behavioural modelling. The property needs advanced Consent Mode, at least 1,000 events a day with analytics storage denied for at least 7 days, and at least 1,000 daily users with analytics storage granted for at least 7 of the previous 28 days⁵. Google adds that meeting these does not guarantee modelling⁵. A smaller shop may not reach those levels, and then GA4 does not report events from visitors who declined⁵.

So how does consent affect incrementality measurement?

• User-level data gets thinner. Fewer users appear in platform reports.
• Platform reports may include modelled numbers. You cannot audit them from your own data.
• Test readouts built on platform numbers inherit both problems.

Our view: where you can, read test outcomes on your own sales data. Orders in your shop system are the same whether the visitor clicked "accept" or not. Use platform reports for context, not as the answer.

You are not asking for a verdict on testing in general. You are asking about your setup.

For your legal team:

• Which of our tags are covered by consent requirements, and how does our banner handle them?
• Does the test design collect or combine any personal data, or only aggregated orders?
• Do the Google consent obligations in the EEA apply to how we advertise?
• What would you want documented before we start?

For your agency (or for us):

• Which design are you proposing: user-level or geo, and why?
• What data does it need, and which of it depends on consent?
• Which regions are control, and how do you handle spillover between them?
• Will the readout use our order data or platform-modelled numbers?
• What is the plan if the result is inconclusive?

Our view: a good agency can answer the second list in plain words and does not mind you taking the first list to counsel. If you also want the tracking side, read server-side tracking GDPR.