Under GDPR and the EU ePrivacy rules, most client-side A/B testing tools need the visitor's consent before they store a cookie or identifier in the browser, because testing is rarely "strictly necessary" to deliver the page.
France and the UK now carve out narrow exemptions for first-party testing and analytics, but only if you inform visitors, let them object and keep the data to yourself.
Everywhere else in the EU, plan to gate your tests on consent.
This page explains where the rules come from, how the main testing tools handle consent, what consent gating does to your data, and what real tests in our database show about privacy messaging and cookie banners.
It is a practical guide, not legal advice: check your setup with your own counsel or data protection officer.
Cookie consent and A/B testing
Why A/B testing tools trigger the consent rules
An A/B test has to remember which variant each visitor saw, so a returning visitor gets the same experience and their conversion counts toward the right group.
Most tools do this with a first-party cookie or local storage entry holding a random visitor ID.
Two laws apply to that ID. Article 5(3) of the ePrivacy Directive requires consent before storing or reading information on a user's device, unless it is strictly necessary to provide a service the user explicitly asked for.
GDPR then governs the personal data you process, and its Recital 30 names cookie identifiers as a way people can be identified.
The ePrivacy rule applies even if the cookie holds nothing personal.
In Planet49 (C-673/17), the EU Court of Justice ruled in October 2019 that a pre-ticked checkbox is not valid cookie consent, and that this "is unaffected by whether or not the information stored or accessed on the user's equipment is personal data."
Moving to local storage, pixels or fingerprinting does not get you out of it.
The EDPB's Guidelines 2/2023, adopted in final form on 7 October 2024, confirm that Article 5(3) covers tracking pixels, tracking links and device fingerprinting, not only cookies.
Where you can test without consent
The rules are set at EU level but enforced country by country, and two regulators have gone further than the rest.
| Jurisdiction | Consent needed for A/B testing cookies? | Conditions for the exemption |
|---|---|---|
| Most EU countries | Yes, by default | Only strictly necessary storage is exempt; testing usually is not |
| France (CNIL) | Not if you meet every condition | Purpose limited to audience measurement and A/B testing; visitors informed and able to object; data not combined with other processing; one publisher only; last byte of IP truncated; tracker lifetime capped at 13 months |
| United Kingdom (PECR, as amended) | Not if you meet every condition | Storage used to collect statistics on how the site or service is used, to improve it; data shared only with those helping make the improvements; clear information; a simple, free way to object |
France's regulator lists A/B testing by name. Its analytics guidance (sheet 16) says exempt trackers must be limited to "audience measurement; A/B testing," with the conditions above.
If the same cookie also feeds ad targeting or a cross-site profile, the exemption is lost.
In the UK, the Data (Use and Access) Act 2025, Schedule 12 added a statistical purposes exception and a separate one for enhancing a website's appearance or functionality.
Both require clear information and "a simple means of objecting, free of charge."
The cookie changes took effect on 5 February 2026.
Neither exemption is a free pass. You still need a privacy notice that mentions testing, an opt-out that works, and a tool configured to keep data first-party and single-site.
How testing tools handle consent
Every major tool offers a way to hold back cookies or tracking until your consent banner says yes.
The difference is what the visitor sees before they decide.
Optimizely's cookie implementation options lay out the trade-offs clearly:
- Disable by default: visitors see the original page until they consent, and testing cannot run on the first page view without a reload or a second page.
- Activate on demand: the snippet runs only after consent, which can cause flicker if the visitor lands in a variant that changes visible elements.
- Hold events: visitors are bucketed and see variants immediately, but events wait in local storage until consent. Optimizely notes the visitor ID cookie is still written before consent, which may not satisfy strict jurisdictions.
- Load through a consent manager: the snippet loads only for visitors who accept.
Convert's documentation describes a similar pattern: a consentRequired command delays cookie writing while experiments still display, and a consentGiven call from your consent platform switches tracking on.
Server-side testing changes where the variant is chosen, not whether you store an identifier.
If your server reads a cookie to keep a visitor in the same group, Article 5(3) still applies.
See server-side vs client-side testing and the flicker effect for the technical side.
What consent gating does to your results
Gating protects you legally, but it changes who is in your test. Three problems show up again and again.
- Smaller samples. Only visitors who accept are counted, so tests take longer to reach the sample you planned. Recalculate duration with your real consent rate, not total traffic. Our guide to testing with low traffic covers what to do when the numbers get thin.
- A different audience. People who click "accept all" may not behave like people who reject. Your result describes consenting visitors, and it may not hold for everyone else.
- Uneven groups. If a variant changes the page in a way that affects whether people consent (moving the banner, slowing the page, shifting the layout), each group will lose a different share of visitors. That shows up as a sample ratio mismatch and makes the result untrustworthy.
A simple check: compare the consent rate in each variant.
If it differs, treat the test as suspect before reading the conversion numbers.
Testing the cookie banner itself
The banner is part of the experience, so it can affect conversion.
One of the clearest cases in our database comes from Blend Commerce, who tested a non-blocking cookie banner instead of a consent wall for a sports nutrition brand.
The control was a consent screen that blocked shopping until the visitor chose.
The A/B/C test ran for two weeks on each of two country sites.
A non-blocking banner at the bottom of the page won in the UK with +32% conversion rate, while a top-of-page banner won in Ireland with +10.51%.
Two caveats. Different variants won on each site, so there is no single "best" banner position.
And a less intrusive banner likely lowers the consent rate, which means fewer visitors in your analytics and future tests.
Weigh the conversion gain against the data you lose, and keep the banner compliant with your regulator's rules on how consent is collected.
Because the banner sits outside most testing tools' consent gate, you may need to test it with your consent platform's own features or a server-side split. See more popup and overlay tests.
Blend CommerceA/B testing privacy beyond cookies
Keep personal data out of the testing tool
Consent covers the cookie. GDPR still covers what you send to the tool afterward, and the safest approach is to send as little as possible.
- Don't pass names, emails, phone numbers or order IDs in custom attributes or goal events. Convert's GDPR page says it strips order IDs from its tracking script for this reason.
- Watch URLs. Form fields or tokens in query strings can end up in your experiment logs.
- Check where the vendor stores data, whether you have a data processing agreement, and how long raw events are kept.
- Honor objections. If a visitor opts out, the tool must stop tracking them, including in server-side tests.
- Be careful when targeting segments. Personalizing on sensitive traits (health, finances, religion) raises the stakes under GDPR's special category rules.
Compare how vendors handle this in our A/B testing tools roundup, or in our Convert review.
Privacy messaging as something to test
Privacy is also a conversion lever. Telling people how their data will be used is a common trust signal, but the tests in our database show it works in some contexts and not others.
Groupama, an insurance group, showed a data-privacy message on its quote form to one visitor segment.
Over two weeks, quote submissions rose 10% and progression to the next form step rose 2 points.
The message was targeted with AB Tasty's EmotionsAI to visitors classed as "intuitive," so the result applies to that segment, not all visitors.
Ferguson Enterprises rebuilt its email signup and preference center as a two-step form with first-person buttons and a privacy notice.
Form submissions rose 120% year over year. That was a bundled, year-over-year comparison with many changes, so the privacy notice cannot be credited on its own.
The reverse also happens. Uncommon Knowledge tested a simpler opt-in page redesign that added privacy and unsubscribe assurances.
The original beat it by 19.55% in sign-ups, at 99.99% statistical significance.
It was a whole-page redesign, so the privacy copy may not be the cause, but it shows reassurance does not guarantee a lift.
The pattern: privacy copy tends to help where people hand over sensitive details, like an insurance quote, and its effect is hard to isolate when it ships inside a redesign.
Test it on its own, at the point where people hesitate.
A short checklist before launch
- Decide your legal basis per market: consent, the CNIL exemption, or the UK statistical exception.
- Configure the tool's consent mode and test it in a private window with consent accepted and rejected.
- Name A/B testing in your cookie and privacy notices, with a working opt-out.
- Plan sample size on consenting traffic only.
- Add consent rate per variant to your QA and analysis checks.
- Keep personal data out of events, attributes and URLs.
For more on running tests well, start at the A/B testing hub, the broader CRO guide, or browse all tests in the database.