A/B testing without cookies: what GDPR actually requires

This is a plain-language explanation of how the rules fit together, written by someone who builds testing software, not a lawyer. It should help you ask your adviser the right questions. It is not legal advice, and national practice varies.

Two European laws get blended into "cookie consent", and keeping them apart is the whole trick to understanding what a testing tool does and does not need from your visitors.

GDPR is about personal data, not about cookies

The General Data Protection Regulation applies when you process personal data: information relating to an identified or identifiable person. It says nothing specific about cookies. What it does say, in Recital 30, is that online identifiers such as cookie identifiers can be personal data when they can be used to single someone out, even without knowing their name.

That matters for A/B testing because most tools need one thing: a way to show the same visitor the same variant on their next visit. The usual mechanism is a random identifier stored in the browser. Whether that identifier is personal data in GDPR's sense depends on what happens to it.

• If the identifier is sent to a vendor's server and stored against events, that vendor holds a record that singles out a device across visits. Most regulators treat that as personal data, pseudonymous but still in scope. You need a lawful basis, a privacy-policy entry, retention rules, and a processing agreement with the vendor.
• If the identifier is sent only to your own server and stored with nothing else, it is still a pseudonymous record, so the GDPR questions apply, but they are the light ones: a lawful basis (legitimate interest is the usual one), a line in your privacy policy, and a retention period. There is no processor and no transfer.
• If the identifier never leaves the browser and the server receives only "one more impression for variant B", the operator holds no record about any individual and the GDPR questions largely fall away. Few tools work this way, because counting each visitor once requires the server to recognise a repeat.

So "cookieless" on its own tells you nothing about GDPR. A tool can avoid cookies and still ship a device identifier to its cloud with every page view. The question to ask a vendor is not "do you use cookies" but "what leaves the visitor's browser, and where does it go".

The ePrivacy rules are about the device, and they are the ones behind the banners

The consent banners you see everywhere come from a different law: the ePrivacy Directive, Article 5(3), transposed into each member state's national law (PECR in the UK). It says that storing information on a user's device, or accessing information already stored there, needs the user's consent, with one exemption: when it is strictly necessary to provide a service the user explicitly asked for.

Two things follow that surprise people.

First, the rule is not about cookies. It covers any storage on the device. The European Data Protection Board's guidelines on the scope of Article 5(3) make explicit that browser local storage, session storage and similar mechanisms are covered exactly as cookies are. A tool that swaps a cookie for local storage has changed the technology, not the legal question.

Second, the rule is not about personal data. It applies whether or not what is stored identifies anyone. That is why it can apply to a tool that is genuinely clean under GDPR.

So the honest position on cookieless A/B testing is this: switching from cookies to local storage, and keeping the identifier in the browser, removes the GDPR exposure and removes the cross-site tracking that regulators care most about. It does not by itself remove the ePrivacy question. That question is whether variant assignment counts as "strictly necessary".

Is A/B test assignment "strictly necessary"?

This is where the law is genuinely unsettled, and anyone who tells you otherwise is selling something.

The exemption was written for things like a shopping-cart session or a login token: without the stored data, the thing the user asked for does not work. A/B testing does not fit that description comfortably; the user did not ask to be in an experiment, and the page works without it. On a strict reading, regulators in several countries have treated testing and analytics storage as needing consent, and the UK's ICO has long said that analytics cookies are not strictly necessary.

Against that, some regulators have carved out room for first-party measurement that cannot follow individuals across sites, does not build profiles and is limited to what the site itself needs to operate. France's CNIL published conditions under which audience measurement can be exempt from consent, and a variant-assignment flag that stays in the browser, never touches a third party and produces only aggregate counts is a much stronger candidate for that reasoning than a third-party analytics identifier is. Whether it qualifies in your country is a question for your adviser or your data protection authority's published guidance, not for a plugin's marketing page.

What can be said with confidence: the less a tool stores, the less it sends, and the fewer parties it involves, the stronger your position under every reading. Design decisions move you along that scale, and the rest of this article is about which ones.

What "cookieless" buys you, precisely

Set the storage-consent question aside for a moment and look at what a browser-side, no-transfer design removes from your obligations compared with a cloud testing tool.

• No processor. If no vendor receives visitor data, there is no data-processing agreement to sign, no sub-processor list to monitor, no vendor breach to worry about.
• No international transfer. Data that never leaves your server never crosses a border. The transfer rules that made US-hosted analytics tools contentious in several EU decisions do not arise.
• No third-party tracking. A first-party identifier in local storage on your domain cannot be read by anyone else, and nothing shares it with an advertising or analytics network. This is the behaviour regulators have targeted hardest, and it is simply absent. The one exception is a split test you deliberately run across two of your own sites: there the id travels to the second site in the redirect URL so the conversion can be credited back.
• Little to disclose about individuals. Your privacy policy describes a random identifier, a variant, a device class, the page path where a conversion happened, the order total when the WooCommerce purchase goal is used, and a timestamp, held in your own database and rolled up into totals after a set period once the test has stopped. Nothing in it can be tied to a name, and a subject access request would need the visitor's own browser id to find anything at all.
• No dependence on consent for the data to be usable. Cloud tools that gate their script behind a banner lose every visitor who declines, which is a large and non-random slice. Results from the remainder describe a self-selected audience.

That last point is a statistical argument as much as a legal one. A test that only sees consenting visitors is measuring consenting visitors.

Questions to ask any testing tool

1. What is stored in the browser, and for how long? A variant flag or a random ID? Does it expire?
2. Does that value ever leave the browser? If yes, to whose server, and is it stored against events?
3. What does the server keep? Aggregate counts per variant, or a log of visits with an identifier?
4. Is there a third-party script? If so, the vendor is a processor and you need an agreement with them.
5. Does it read anything else? Some tools fingerprint devices or read existing analytics cookies to stitch sessions together. Both are access to stored information under Article 5(3) and both are much harder to defend.
6. Does it work if the visitor declines? And if it does, what exactly is it doing without consent?

A tool that answers "a random id and a variant flag, yes but only to your own server, event rows with that random id that roll up into totals once the test stops, no, no, and it runs identically for everyone" has about the smallest footprint the technology allows while still counting each visitor once. That is how AB Test WP is built: a random identifier kept in local storage so returning visitors see the same variant, sent with each impression or conversion to your own server and stored with the variant, a device class, the page path of the conversion, the order total when the WooCommerce purchase goal is used, and a timestamp, never an IP address or user agent. Once a test is stopped, its raw rows older than the retention window (90 days by default) are rolled up into daily totals and deleted; a running test keeps every raw row. Nothing goes to us or to any third party. The plugin data page lists every item it stores. The one deliberate exception is the optional AI features, which are admin-side: when the site owner triggers one, the server sends the selected text and the page title to the AI provider the owner configured with their own key. Visitor data is never part of that.

Outside the EU

The picture is simpler and mostly moves the same direction.

• UK: UK GDPR and PECR mirror the EU rules described above, and the ICO's guidance on storage and analytics is among the stricter readings.
• United States: there is no general consent requirement for browser storage. State privacy laws such as California's CPRA give residents opt-outs from the sale or sharing of personal information and from certain profiling. A first-party test that shares nothing with anyone and holds no per-person record has little to opt out of.
• Elsewhere: Brazil's LGPD, Canada's PIPEDA and similar laws follow GDPR's logic on personal data. The "does it leave the browser" question decides most of it.

A practical posture for a WordPress site

1. Prefer tools where visitor data never leaves your server. That single choice removes processors, transfers and cross-site tracking from your compliance list.
2. Describe the test storage in your privacy policy in one honest sentence: what is stored in the browser, that it identifies no one, what your own server keeps and for how long, and that nothing goes to a third party. That sentence is most of the compliance work.
3. If you already run a consent banner for analytics or ads, decide with your adviser whether test assignment sits inside the "necessary" category or alongside analytics. Either way the tool should behave identically for consenting and non-consenting visitors, which only a design that stores nothing personal can do.
4. Do not test on pages that collect special-category data without specific advice: health, finances, anything about children.
5. Keep the retention short. An assignment that expires when the test ends is easier to defend than one that lives for a year.

Frequently asked

Does GDPR require a cookie banner?

No. Banners come from the ePrivacy rules on device storage. GDPR governs what you do with personal data once you have it, and can apply with no cookies at all.

Is local storage treated like a cookie?

For the ePrivacy storage rule, yes; the EDPB's guidance on Article 5(3) covers local storage explicitly. For GDPR, what matters is whether the stored value is used to single out or track an individual.

Is a random ID stored against test events personal data?

Usually treated as pseudonymous personal data, because it singles out a device across visits even though nobody can tie it to a name. Held only by you, on your own server, with no IP address or user agent alongside it, the obligations are light: a lawful basis, a line in your privacy policy and a retention period. AB Test WP stores the id with a variant, a device class, the page path of the conversion, the order total on a signed WooCommerce purchase conversion (one revenue credit per order per test, so a replay of the same order is recorded with its value zeroed) and a timestamp, and once a test is stopped it rolls that test's raw rows older than 90 days (by default) up into daily totals and deletes them; a running test keeps every raw row.

Can I A/B test in the EU without a consent banner?

It depends on your country's reading of "strictly necessary" and on what the tool stores and sends. A first-party design that stores no personal attributes and shares nothing is the best case for doing so; it is not a guarantee, and anyone claiming one for every jurisdiction is overreaching.

Sources worth reading directly: the GDPR text (Article 4 and Recital 30), the ePrivacy Directive Article 5(3), the EDPB Guidelines 2/2023 on the technical scope of Article 5(3), your national regulator's cookie guidance, and, for the UK, the ICO's guidance on PECR and analytics.

Sources

• Directive 2002/58/EC (ePrivacy), Article 5(3), EUR-Lex, checked September 2026
• Guidelines 2/2023 on the technical scope of Article 5(3), European Data Protection Board, checked September 2026
• Cookies and similar technologies, Information Commissioner's Office, checked September 2026