Is A/B Testing GDPR Compliant? A Privacy Guide for Website Experimenters

Quick answer

A/B testing can be fully GDPR compliant. Whether you need explicit consent depends on what data your testing tool collects and when it collects it. Tools that assign a persistent cookie tied to a user ID and immediately send data to a server are processing personal data under GDPR, requiring either legitimate interest or consent. The more nuanced approach — used by tools like Mida — is to separate variant delivery from data collection entirely: show the test variant to every visitor immediately, but only set cookies and record data for visitors who consent. This "experience-first" model means no visitor's experience is degraded by a consent banner, while personal data is only processed for those who opt in.

Key takeaways

• A/B testing that sets a persistent cookie and sends data to a server is processing personal data under GDPR, because a cookie ID can be linked back to an individual.
• Legitimate interest is a valid legal basis for A/B testing under GDPR Article 6 in many jurisdictions, but Germany's TDDDG and France's national cookie rules require consent regardless — making consent the only basis that works EU-wide.
• The experience-first approach — rendering the variant before any cookie is set, then collecting data only after consent is granted — is the most privacy-compliant way to run A/B tests without sacrificing test coverage or user experience.
• Your privacy policy must disclose that you run A/B tests, what data is collected (and when), how long it is retained, and how users can opt out.

If you run A/B tests on a website with European visitors, you have probably wondered whether your testing setup needs to be part of your GDPR compliance work. The honest answer is: it depends on your tool, but most mainstream A/B testing platforms do fall under GDPR's reach, and getting this wrong is not a technicality — regulators have issued fines for non-compliant analytics and tracking setups, and A/B testing tools share many of the same mechanisms.

This guide walks through exactly what GDPR requires, where A/B testing intersects with it, what your legal basis options are, and the practical steps to run a compliant experimentation program.

What data does A/B testing actually collect?

Before asking whether A/B testing is GDPR compliant, it helps to understand what data is actually collected. Most client-side A/B testing tools do some version of this when a visitor lands on your page:

1. Generate a random visitor ID and store it in a browser cookie (e.g. _mida_vid=abc123)
2. Assign that visitor to a variant (control or treatment) based on the ID
3. Record which variant the visitor saw, alongside the visitor ID
4. When a goal fires (button click, purchase, form submit), record the conversion alongside the same visitor ID

The visitor ID itself is pseudonymous — it does not contain a name or email address. But under GDPR, pseudonymous data is still personal data if it can be linked back to an identifiable individual, directly or indirectly (GDPR Recital 26). A cookie ID combined with an IP address, or matched against a logged-in user ID, can do exactly that.

So the core question is: does your A/B testing tool set a persistent cookie, and does that cookie ID get stored on a server you control or your vendor controls? If yes, you are processing personal data and GDPR applies.

Is A/B testing "processing personal data" under GDPR?

GDPR's definition of processing is broad: it covers any operation performed on personal data, including collection, storage, retrieval, use, and transmission. Assigning a visitor ID, storing a variant assignment in a database, and logging a conversion event all qualify as processing.

The key thresholds that bring an A/B testing setup into scope:

• Persistent cookie set in the browser — any cookie with a non-zero max-age or expires attribute that outlives the session is a persistent identifier and personal data
• Visitor ID stored on a server — even if the cookie is session-only, if the ID and variant assignment are sent to a server-side database, that constitutes processing
• Cross-session tracking — if your tool can recognise a returning visitor across separate sessions, it is definitively tracking an individual over time

If your A/B testing tool does none of these — for example, if variant assignment is purely server-side with no persistent identifier — it may not constitute personal data processing at all. A more practical middle ground is to defer cookies and data collection until consent is given: the visitor sees the variant immediately (no personal data is processed at that point), and data is only recorded if and when they accept. This is the approach Mida's consent mode takes, described in detail below.

What legal basis do you need?

GDPR requires a lawful basis for every processing activity. For A/B testing, the two most relevant bases are:

1. Legitimate interest (Article 6(1)(f))

Legitimate interest is the most commonly cited basis for A/B testing. The argument runs: you have a genuine business interest in understanding how users interact with your site and improving it; that interest is not overridden by user rights because the data collected is pseudonymous, limited in scope, and not used for profiling or advertising.

To rely on legitimate interest legally, you must complete a Legitimate Interest Assessment (LIA) — a documented three-part test covering purpose, necessity, and balancing. The balancing test specifically asks whether the processing could reasonably be expected by the user and whether it overrides their interests. For basic, pseudonymous A/B testing with no third-party data sharing, many DPOs conclude this test is passable.

The risk: legitimate interest is not a blanket pass, and two major EU jurisdictions have made this explicit.

Germany: Germany's TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, formerly TTDSG), Section 25, implements the ePrivacy Directive and requires consent before storing or accessing information on a user's device. Legitimate interest is not a valid basis under this law — the German DSK (Datenschutzkonferenz), the joint conference of Germany's 17 federal and state data protection authorities, and the BfDI have confirmed this repeatedly. Consent is mandatory for all non-essential cookies in Germany.

France: CNIL's developer guide does list A/B testing as one of the potentially exempt purposes — alongside audience measurement — but the exemption comes with strict conditions that most real-world testing setups cannot meet. The tool must produce only anonymised output, must not track individual conversions across sessions, must not share data with third parties, and must not create user profiles. Furthermore, CNIL's 2025 self-evaluation criteria specifically exclude any setup that involves "creation of user cohorts to present them with differentiated content, whether membership is defined randomly or based on previously collected information" — which covers most A/B testing implementations, since tracking whether an individual in variant B converted is precisely what makes the test measurable. In practice, unless you are running a purely session-scoped, aggregated test with no individual-level conversion tracking, French traffic requires consent.

If you have significant German or French traffic — or want a single defensible approach across all EU markets — consent is the right basis.

2. Consent (Article 6(1)(a))

Consent means the user actively opts in before any A/B testing cookie is set. This requires a compliant consent management platform (CMP) that gates non-essential cookies, a clear description of what A/B testing cookies do, and genuine choice (no dark patterns, no pre-ticked boxes).

The downside of consent-first A/B testing is traffic reduction. Depending on your accept rate, you may only be running experiments on 50–70% of your visitors — which affects statistical power and increases the time needed to reach significance. See our guide on statistical power for how to account for this.

The upside: consent is the most defensible legal basis in every EU jurisdiction, and it is the only basis that satisfies the ePrivacy Directive's specific rules on cookies, which apply in addition to GDPR in most EU member states.

CCPA and US privacy laws

If you have California visitors, the California Consumer Privacy Act (CCPA) and its amendment CPRA also apply. CCPA treats any data that can identify a California consumer as personal information. A visitor ID cookie associated with browsing behaviour meets this definition.

CCPA does not require opt-in consent for data collection (unlike GDPR), but it does require:

• Disclosure in your privacy policy that you collect visitor identifiers for website optimisation
• A "Do Not Sell or Share My Personal Information" mechanism if you share that data with third parties (your A/B testing vendor is a third party)
• Honouring opt-out requests, including Global Privacy Control (GPC) signals

In practice, most A/B testing platforms process data as a service provider (processor under GDPR terminology), which limits CCPA's "sale" framing. But you still need a data processing agreement (DPA) with your vendor and need to disclose the relationship in your privacy policy.

Cookieless A/B testing: the server-side option

The traditional way to sidestep the consent debate entirely is to avoid persistent identifiers through server-side assignment.

Server-side variant assignment

The server assigns a variant before the page is rendered and delivers the correct version directly. No JavaScript runs on the client to assign a variant; no cookie is needed for the split. The only data processed is the server request itself (IP address, user agent), which you are already processing to serve the page.

This approach also eliminates anti-flicker scripts and delivers better Core Web Vitals scores. The tradeoff is engineering effort — you need to integrate the A/B testing logic into your server or edge layer.

A related client-side variant — storing assignment in sessionStorage instead of a cookie — avoids persistent identifiers but breaks cross-session consistency: a returning visitor may land in a different variant on their next visit, introducing noise into longer experiments. Neither server-side nor session-scoped approaches are how most commercial A/B testing platforms work. For client-side tools that do use cookies, the experience-first approach below is the more practical compliance path.

How Mida handles consent: experience first

Mida is not a cookieless platform — it uses cookies to track variant assignment and conversions. What makes it different is when those cookies are set and when data is sent to the server. Mida separates two things that most tools bundle together: serving the experience and collecting data about it.

The problem with standard consent-gated loading

If you block your A/B testing script entirely until the user clicks "Accept", two things happen. First, visitors who decline never enter your experiments, so your results represent only a consenting subset of your audience. Second: if your test changes a headline or background colour, visitors who accept see a flicker — the page renders in its default state, the consent banner appears, the user accepts, and then the variant is applied. That degraded experience can itself distort conversion rates.

Mida's experience-first model

Mida's consent mode loads the script and renders the correct variant on every page load — before the consent banner is even displayed. No cookie is set at this point. No data is sent to the server. The visitor simply sees the intended version of the page, with no flicker and no UX disruption.

Then, when the visitor acts on the consent banner:

• Accept: Mida sets its cookie, records the visit and variant, and begins tracking conversions.
• Decline: Nothing is stored and nothing is sent. That visitor never appears in your experiment reports.

The result: 100% of visitors get a proper test experience, but personal data is only processed for the fraction who consent. The experiment does not harm anyone's experience, and Mida's data collection is consent-gated throughout.

To enable this, add the cookie=1 parameter to your Mida script URL:

https://cdn.mida.so/js/optimize.js?key=YOUR_PROJECT_KEY&cookie=1

Then call the appropriate method from your CMP (OneTrust, Usercentrics, Cookiebot, or GTM) once the visitor acts on the banner. See the full Mida consent setup guide for step-by-step instructions.

// Visitor accepts cookies
mida.grantConsent(true)

// Visitor declines cookies
mida.grantConsent(false)

Critically, the Mida script must be placed before your CMP script in the <head> — as high as possible — so the variant renders before the consent banner is shown. The CMP loads after; Mida holds all data collection until the consent signal arrives.

What data Mida does (and does not) collect

Mida's billing and reporting model is built around Monthly Tested Users (MTUs) — a count of distinct visitors who entered an experiment. It does not collect names, email addresses, device fingerprints, or browsing history. The data points recorded per visitor are: a pseudonymous visitor ID, the experiment and variant they saw, and whether a defined goal was met.

For compliance documentation, Mida provides a standard Data Processing Agreement (DPA) at mida.so/data-processing-agreement-dpa.

Practical GDPR compliance checklist for A/B testing

Use this checklist as a starting point. It is not legal advice — consult a qualified DPO or privacy lawyer for your specific situation.

Documentation

• Add A/B testing to your Record of Processing Activities (RoPA) with legal basis, data categories, retention periods, and processor details
• Complete a Legitimate Interest Assessment if you are relying on LI as your basis
• Sign a Data Processing Agreement with your A/B testing vendor

Consent management

• If your tool sets a persistent cookie: gate it behind your CMP under an "Analytics" or "Website optimisation" consent category
• If using Mida: enable consent mode with the cookie=1 parameter and call mida.grantConsent(true/false) from your CMP callback — this lets you serve variants without flicker while holding data collection until consent is given
• Place your A/B testing script before your CMP script in <head> when using deferred consent mode, so variants render immediately without waiting for the banner
• If using server-side variant assignment with no persistent identifier: document this in your RoPA as a distinct processing activity with a narrower scope

Privacy policy

• Disclose that you run A/B tests and why
• Name your A/B testing vendor as a data processor
• State what data is collected (visitor ID, variant seen, conversion events), retention period, and legal basis
• Explain how users can opt out (withdraw consent, or submit a data deletion request)

Technical

• Confirm your A/B testing vendor is either EU-based or has a valid Standard Contractual Clauses (SCCs) or EU-US Data Privacy Framework (DPF) mechanism for data transfers to non-EU countries
• Set appropriate cookie expiry dates — CNIL's published guidance recommends a maximum of 13 months; collected data should be retained no longer than 25 months. No EU regulator specifies a universal limit, but durations beyond 13 months will attract scrutiny
• Test that your A/B testing script does not fire before consent on pages where consent is required

Does GDPR compliance affect your test results?

Yes, in a few ways worth knowing:

Reduced measurement sample: If data collection is consent-gated, your results reflect only consenting visitors — typically a more engaged, tech-comfortable subset. Variant exposure is not affected (all visitors see the test), but conversions are only attributed for consenting visitors. Extrapolating wins to your full audience requires some care, especially for tests involving price, first impressions, or trust signals.

Reduced statistical power: If your CMP accept rate is 40%, only 40% of exposed visitors contribute to your significance calculations. You effectively need 2.5× the traffic to reach the same sample size. Use the A/B test duration calculator to account for your actual consent rate when planning experiment length.

Self-selection bias: Users who consent to cookies may behave differently from those who decline. If your product skews toward privacy-conscious audiences, this gap can be meaningful. Document it when reporting results to stakeholders.

What's changing in 2026: EU Digital Omnibus

In November 2025, the European Commission proposed the EU Digital Omnibus — a package of amendments to existing EU digital laws, including a proposal to harmonise CNIL's analytics consent exemption across all 27 EU member states. If adopted, a first-party analytics exemption with standardised criteria (anonymised data, no cross-site tracking, no profiling) would apply EU-wide, rather than only in France under CNIL's guidance.

Critically, based on the criteria discussed above — A/B testing involves cohort creation and individual-level variant tracking — A/B testing cookies would almost certainly still fall outside any such exemption. The proposal would help basic, aggregated analytics; it would not remove the consent requirement for experimentation tools. Monitor the progress of the Omnibus if this affects your compliance planning.

The bottom line

A/B testing is not inherently a GDPR problem — the issue is how most tools implement it. If your testing tool sets a persistent cookie and sends visitor data to a third-party server immediately on page load, you are processing personal data and need a lawful basis, a DPA, and privacy policy disclosure.

For most marketing teams, the practical recommendation is: use a CMP, gate your A/B testing cookie under analytics consent, and document the processing in your RoPA. This covers roughly 95% of what regulators expect to see. The tradeoff is that consent-gated scripts introduce flicker and reduce your measurable sample.

The more elegant path — and the approach Mida is built around — is to separate the user experience from data collection. Render the variant for everyone, consent-gate the data. Visitors get a consistent, flicker-free experience regardless of their consent choice; your compliance obligations only apply to the visitors who opt in. You can run compliant experiments without sacrificing test coverage or user experience.

Ready to run privacy-first A/B tests? Try Mida for free — no credit card required, 100K monthly tested users on the free plan.

Frequently asked questions

Q: Do I need a cookie banner before running A/B tests?

A: If your A/B testing tool sets a persistent cookie, yes — under the ePrivacy Directive (which applies in most EU countries alongside GDPR), non-essential cookies require prior consent before they are set. With Mida's consent mode, the variant is rendered before the banner appears, but no cookie is set until the visitor accepts. So you still need a banner — Mida's model simply ensures the visitor's experience isn't held hostage by their consent decision.

Q: Is legitimate interest a valid basis for A/B testing cookies?

A: For GDPR Article 6 purposes, legitimate interest is theoretically available with a documented LIA. However, for the cookie-placement act itself, Germany's TDDDG Section 25 and France's ePrivacy implementation both require consent regardless of any GDPR lawful basis — legitimate interest does not satisfy those national cookie laws. In practice, consent is the only basis that works across all EU member states for non-essential cookies including A/B testing trackers.

Q: Does GDPR apply to A/B testing on logged-in users?

A: Yes, and more strictly. Logged-in users have a known identity, which means the visitor ID is more easily linkable to an individual. You should ensure your privacy policy covers experimentation on authenticated users and that your consent or legitimate interest documentation addresses this specifically.

Q: What is the difference between a data controller and data processor for A/B testing?

A: Your business is the data controller — you decide the purpose and means of processing. Your A/B testing vendor (e.g. Mida) is the data processor — they process data on your behalf. You must have a signed Data Processing Agreement (DPA) with your vendor, and you remain liable for how they process data on your instructions.

Q: Can I show A/B test variants without waiting for cookie consent?

A: Yes, if your A/B testing tool supports deferred consent mode. Mida's cookie=1 implementation serves the variant immediately on page load — before the consent banner appears — but does not set any cookies or send data to the server until the visitor accepts. This eliminates the flicker problem that occurs when you block the testing script entirely until consent is granted. Place the Mida script above your CMP script in <head> and call mida.grantConsent(true) or mida.grantConsent(false) from your CMP's acceptance/rejection callback.

Q: Can I run A/B tests on email campaigns under GDPR?

A: Email A/B testing (subject line tests, send time tests) operates differently — you are processing data you already have a legal basis to process for email marketing. The consent you obtained for email marketing typically covers basic analytics on that email, including open rates and click-through rates needed to measure an A/B test. Consult your DPO if you are merging email test results with on-site behaviour data.