How ICO cookie consent rules change CRO analytics for British stores

What to take away

What the ICO expects for consent under UK GDPR

The ICO regulates data protection in the UK. It enforces the UK GDPR and the Data Protection Act 2018, and it publishes guidance that analytics teams can be held to.

Consent is one of six lawful bases. For tracking cookies and similar technologies, it is normally the only workable one, because the processing is not necessary to perform a contract and legitimate interests are hard to defend for advertising or cross-site analytics.

The ICO requires consent to be given freely, be specific, informed and clear. A pre-ticked box, a cookie wall that blocks access, or a banner where rejecting is harder than accepting will not meet that bar.

Your privacy information must name the purposes, the categories of data, the recipients and the retention period. Vague wording such as "we may share data with partners" is not enough.

Withdrawal must be as easy as giving consent. If a user can accept in one click, they should be able to reject or withdraw in one click, and your analytics pipeline must honour that change.

Record keeping matters. The ICO expects you to show what a user consented to, when, and which version of your notice they saw. That record is also useful evidence in a CRO audit.

Before you choose a basis for checkout or account data, map the data flows first; the lawful basis decision follows the map, not the other way round.

Regulation 6 of PECR and the cookie consent rule for analytics

Regulation 6 of The Privacy and Electronic Communications (EC Directive) Regulations 2003 governs the storage of information on a user's device. It applies to cookies, local storage, pixels and device fingerprinting.

The rule is simple to state and hard to operate: you must obtain consent unless the cookie is strictly necessary to provide a service the user requested, or falls within a narrow exemption.

Analytics cookies rarely qualify as strictly necessary. Knowing how many people viewed a product page is useful to you, but it is not required to deliver the page the shopper asked for.

PECR sits alongside the UK GDPR, not instead of it. A cookie can breach PECR for lack of consent even where the personal data processing would otherwise be lawful.

The ICO's Cookies and similar technologies | ICO guidance sets out the consent standard and the limited exemptions. It is the document your consent banner will be judged against.

Enforcement can follow a complaint or a sweep. The ICO has powers to require changes and to issue fines, and it has used them against organisations whose banners made rejection difficult.

For a British retailer, the practical consequence is that your analytics tag fires only after a positive consent signal, and your tag manager must be able to suppress it otherwise.

How consent choices change A/B testing tools and their data

Most A/B testing tools identify a visitor, assign a variant and log an outcome. If a visitor does not consent, the tool cannot do that lawfully.

So your experiment population becomes consenting visitors only. That is not a random sample of all shoppers, and the difference is not random either.

Consent rates vary by device, traffic source, age and country. Shoppers arriving from paid social often reject more than loyal email subscribers. Your test group is therefore skewed towards the people most willing to be tracked.

The skew matters most when the behaviour you are testing correlates with privacy attitudes. Banner design, personalisation, loyalty prompts and data-heavy checkout steps all interact with who consents.

Non-consenting visitors still convert. Their orders appear in your platform data but not in your testing tool, so your measured conversion rate is a rate among consenters, not among shoppers.

If consent rates differ between variants, and they can if the banner renders differently, you have a confound. Check consent rate by variant before you read the result.

A practical fix is to keep the consent banner outside the experiment. Serve the same banner to both variants, and exclude banner tests from the main experiment queue unless the banner is the thing under test.

Attribution under consent gaps and modelled conversions

Attribution depends on linking touchpoints to a conversion. Consent gaps break those links, and the break is not evenly distributed across channels.

Channels with high consent rates, such as logged-in email or app traffic, will look better than they are. Channels with low consent rates, such as some paid social placements, will look worse.

Platform-reported conversions and your own analytics will disagree. Neither is wrong; they observe different populations, and the gap is a consent artefact as much as a measurement one.

Modelled conversions fill gaps using consented data and aggregate patterns. Google's consent mode is the common implementation in the UK, and it estimates conversions for non-consented users.

The ICO's Online tracking | ICO guidance is clear that modelling does not remove the need for a lawful basis where personal data is processed. Treat estimates as estimates.

Do not let modelled numbers drive budget decisions alone. Keep a consented-only view and a modelled view, and compare them; if they diverge, investigate before you shift spend.

Compare methods deliberately rather than defaulting to the platform's number. A structured review of conversion attribution methods helps you pick one that matches a single merchant decision.

Sample sizes when consenting traffic is a fraction of sessions

Sample size drives test duration. If consent rates halve your eligible traffic, your test takes roughly four times as long to reach the same sensitivity.

That is the arithmetic of variance: detectable effect scales with the square root of sample size. Halving the sample roughly increases the minimum detectable effect by about 40 per cent.

A worked example. Suppose you need 20,000 sessions per variant to detect a 5 per cent relative lift. If only 40 per cent of your traffic consents, you need 50,000 sessions per variant, or 100,000 in total.

At 30,000 sessions a week, that is over three weeks of running. Add a weekly cycle and you are looking at four weeks, with the usual risks of seasonality and stock changes.

The table below shows how consent rate changes the traffic you need for the same sensitivity.

Longer tests raise the chance of interference: promotions, paydays, weather and competitor activity. Sequential testing and careful peeking rules become more important, not less.

One mitigation is to raise your minimum detectable effect and test only bigger changes. Another is to pool traffic across similar pages, which needs a clear pre-registered plan.

Do not let the arithmetic push you into sloppy practice. Pre-register the sample, the primary metric and the stopping rule, and report the consent rate alongside the result.

Consent exemptions for analytics cookies and what they do not cover

The exemption that matters most is the one for analytics. The ICO accepts that some first-party analytics can be exempt from consent if the conditions are met.

The conditions are narrow. The analytics must be for your own purposes, used to improve the service you provide, and must not be used to build profiles or to track users across other services.

No data may be shared with third parties for their own purposes. If your analytics vendor uses the data for its own product development or advertising, the exemption is gone.

The data must not be used to identify individuals, and the processing must be limited to what is necessary. IP addresses and identifiers need to be handled accordingly.

The exemption does not cover advertising pixels, cross-site tracking, personalisation engines or session replay. Those need consent, full stop.

It also does not cover A/B testing tools that assign persistent identifiers for experimentation, because that is not analytics for service improvement in the ICO's sense.

The exemption is not a blanket permission for your whole stack; it applies tool by tool, configuration by configuration. Document why each tool qualifies, or default to consent.

Designing a CRO measurement plan that survives an ICO review

An ICO review is easier when your measurement plan reads like a record of decisions rather than a list of tools. Write it down and keep it current.

Start with a data map: every tag, what it collects, where it sends data, the lawful basis, the retention period and the consent state that gates it.

Then define your consent architecture. The banner, the tag manager triggers, the withdrawal path and the re-consent rules should be described in one place.

Set out your experiment policy: which tools run only on consented traffic, how you check for consent-rate differences between variants, and how you handle non-consented orders in analysis.

Document your attribution approach, including any modelling, and state its limits. Note the consented-only view and the modelled view, and who reviews divergences.

Record your sample-size rules and stopping rules before each test. This protects you from accusations of fishing and from your own worst instincts.

Finally, review the plan quarterly. Consent rates, vendor terms and ICO guidance all move, and a stale plan is worse than none. Common conversion measurement mistakes, from mixed identities to peeking at experiments, are exactly what a documented plan prevents.

Common questions