“Privacy-first” is easy to put on a pricing page. It is much harder to show in a data flow.
A privacy badge is not an architecture diagram.
If you run A/B tests, the useful question is what actually happens when somebody enters an experiment: how they are assigned, what keeps that assignment consistent, what gets measured, what is stored, where it goes and how long it stays.
Privacy-first A/B testing means collecting and retaining only the data needed to run and measure an experiment, keeping the purpose narrow, using proportionate methods for assignment and measurement, and making data flows, processors and user choices clear. It does not automatically mean cookie-free, consent-free or GDPR compliant.
That distinction matters because privacy and useful experimentation are not opposites. You can respect people and still learn what improves a website. You simply need to know what your testing stack is doing rather than relying on a reassuring label.
What privacy-first A/B testing actually means
There is no official “privacy-first” certification for A/B testing software. It is better understood as a design approach.
For an experimentation team, that starts with a few fairly unglamorous questions. What data do we genuinely need? Can we do the job with less? How long do we need it? Does it need to be tied to the same visitor across sessions? Who else receives it?
Those questions line up closely with familiar GDPR principles such as purpose limitation, data minimisation and storage limitation. The European Commission's overview of GDPR principles also emphasises security and accountability, while data protection by design pushes organisations to think about privacy before a system is already collecting data.
For A/B testing, a privacy-first approach usually means:
collecting what the experiment needs rather than everything the technology can collect;
keeping experimentation data focused on measuring the test, rather than quietly turning it into a wider visitor profile;
limiting how long visitor-level information is retained;
understanding which storage methods and identifiers are used for assignment and measurement;
being clear about processors, sub-processors and data locations;
giving people the information and choices required by the rules that apply to the implementation.
None of that is particularly exciting marketing copy. That is rather the point. Privacy is more convincing when you can explain it.
Start with the data flow, not the marketing page
A typical A/B test looks simple from the outside. Show version A to some visitors, version B to others, measure what happens and see which version performs better.
Underneath, the system still needs to make several decisions.
Assign the visitor to a variation. The platform needs to decide which experience this request should receive.
Keep the experience consistent where necessary. If the visitor returns, the experiment may need a way to recognise that they were previously assigned to A or B.
Measure an outcome. A conversion might be a form submission, purchase, button click, registration or another event that matters to the experiment.
Associate the outcome with the variation. Otherwise the platform cannot compare results.
Aggregate the experiment data. Individual events become the results a marketer or CRO practitioner actually uses.
At each point, ask four things: what information is created, where is it stored, how long does it persist and who receives it?
For example, one platform might remember an assignment with a browser cookie. Another might use local storage. Another could make the decision on a server and use request information to create an identifier. Those are different architectures, and the privacy implications depend on what each implementation actually does.
Cookies are only one part of the privacy question
Cookies get most of the attention because they are familiar. Removing them can be meaningful, but “no cookies” is not a complete data map.
A testing implementation might still store or access information through other browser mechanisms. It might use unique identifiers, information in URLs, IP addresses, request headers or techniques based on combinations of device information. Whether those methods create the same risks or legal requirements depends on what is actually happening.
The European Data Protection Board's Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directivedeliberately look beyond traditional cookies to a broader range of technologies that can store information on, or gain access to information from, a user's device.
So when a vendor says its A/B testing is cookie-free, the sensible follow-up is: what do you use instead?
Does A/B testing require consent? It depends
This is where simple marketing claims become especially risky.
A/B testing can involve two overlapping areas of privacy law. Rules such as PECR in the UK, and national laws implementing the EU ePrivacy Directive, govern certain storage of or access to information on a user's device. GDPR or UK GDPR can separately apply when personal data is processed.
That means “does A/B testing need consent?” cannot be answered responsibly without looking at the jurisdiction, the purpose of the experiment and the technology being used.
The UK: an important change in 2026
In April 2026, the UK's Information Commissioner's Office published its final guidance on storage and access technologies, incorporating changes introduced by the Data (Use and Access) Act 2025.
One of those changes is a statistical purposes exception under PECR. The ICO's guidance on the exceptions explicitly gives A/B testing as an example of an activity that is likely to fall within the exception when its conditions are met.
That is a meaningful development, but it is not a free pass for every experiment.
Broadly, the exception is aimed at storage or access used solely to produce statistical information about how people use a service, with a view to improving that service. The ICO's conditions include requirements around clear information, a simple way for users to object, limiting the purpose, moving towards aggregated results and avoiding use of the data to identify people or make decisions about them.
If a third-party provider is involved, the purpose matters there too. A provider acting on behalf of a website to produce the relevant statistics is very different from a provider reusing the same visitor information for unrelated advertising or profiling.
And if personal data is being processed, UK GDPR still applies. The statistical purposes exception is a PECR exception covering qualifying storage or access technologies. It is not, by itself, a lawful basis for processing personal data under UK GDPR. The PECR exception does not make the wider data protection framework disappear.
So the accurate takeaway is not “A/B testing no longer needs consent in the UK”. It is this: some A/B testing can qualify for a specific PECR exception when the implementation and purpose meet the conditions.
That is less catchy. It is also much more useful.
The EU: there is no single shortcut
In the EU, Article 5(3) of the ePrivacy Directive establishes the general framework for storing information, or gaining access to information already stored, on a user's terminal equipment. Consent is the general rule, subject to specified exceptions, and Member States implement that framework through national law.
GDPR then applies separately where the experimentation involves personal data.
The practical complication is that national regulators can provide more detailed interpretations of when particular measurement activities qualify for an exemption. France is a good example. CNIL's guidance on audience measurementdescribes conditions under which certain audience-measurement trackers can be exempt from consent and includes A/B testing within the permitted measurement purposes.
That does not create an EU-wide “A/B testing exemption”. If you operate across several European markets, check the rule in each jurisdiction and whether your implementation fits it.
Client-side, server-side and edge testing: what actually changes?
Client-side testing
With client-side testing, code running in the browser commonly handles part of the assignment or visual change after the page starts loading. The implementation may use browser storage, identifiers or network requests to keep assignments consistent and report results.
The privacy implications depend on that browser-side behaviour.
Server-side testing
With server-side testing, the application or server can decide which variation to deliver before the final response reaches the visitor. This can reduce reliance on some browser-side scripts and storage mechanisms and can give a team more control over the data flow.
It still leaves the usual questions about which data is processed, for what purpose, how long it is retained and who receives it.
Edge testing
Edge experimentation moves some decision-making closer to the visitor, typically before the request travels all the way back to an application's origin infrastructure. That can be useful for delivery performance and can change where assignment logic lives.
From a privacy perspective, the interesting questions are still wonderfully boring: what signals are used to make the decision, what gets retained, what gets sent elsewhere and where the resulting experiment data is processed?
Architecture can give teams more control over privacy. It does not remove the underlying data-handling questions.
A privacy-first checklist for choosing an A/B testing platform
If you are an agency, marketer or CRO team evaluating a testing tool, you do not need to become a privacy engineer. You do need answers that are more specific than “we take privacy seriously”.
Ask the vendor:
How are visitors assigned to experiment variations?
Does the implementation set cookies, use local storage, create persistent IDs or use fingerprinting techniques?
Which of those mechanisms are required, and which are optional?
What visitor-level data is collected when somebody enters an experiment?
Can personal data accidentally enter the platform through URLs, event properties, integrations or custom attributes?
Where is experiment data processed and stored?
Which sub-processors receive the data, what do they do and where are they located?
Is a current data processing agreement available?
How long is visitor-level or event-level data retained by default?
Can retention be shortened?
How can a customer's implementation respect consent or objection choices where required?
Does the vendor use experimentation data for any purpose beyond providing the service to the customer?
What happens to data when an experiment, website or account is deleted?
If there is a server-side or edge option, does it actually change the data flow or merely where the variation is delivered?
Can the vendor show documentation that supports its privacy claims?
A serious vendor should be able to explain the system rather than asking you to treat compliance as a magic property of the software.
Privacy choices can affect experiment quality too
Privacy is not a separate box that legal ticks after the experimentation plan is finished. Choices about data and consent can affect the experiment itself.
If an implementation only starts after a visitor has given a particular form of consent, for example, the people entering the test may be a smaller or meaningfully different group from total site traffic. That does not invalidate the experiment, but it is something the team should understand when interpreting the result.
Likewise, maintaining a persistent identifier can make cross-session assignment easier, but it means maintaining more state about a visitor. A more minimal approach can reduce that state, while potentially changing what the test can reliably recognise across visits.
For agencies, there is another practical benefit to getting this right. A clear data flow is easier to explain to a client's security, procurement or legal team. “Here is what the experiment collects and why” tends to travel better through an approval process than “the website says privacy-first”.
What privacy-first does not mean
A few shortcuts are worth retiring.
Cookie-free does not automatically mean no identifiers or no personal data. Cookies are only one mechanism.
EU hosting does not automatically make an implementation GDPR compliant. Data location matters, but it is only one part of the picture.
Server-side does not automatically remove privacy obligations. It changes where processing happens, not whether the data needs to be understood.
A DPA is important, but it is not the whole privacy architecture. A contract alone does not describe the implementation.
“GDPR compliant” is not a permanent sticker attached to software. Configuration, data and purpose matter too.
How Split Hero thinks about privacy-first experimentation
At Split Hero, we believe experimentation should be easy to run without treating visitor privacy as collateral damage.
We are building towards a broader privacy-first experimentation platform for agencies, marketers and CRO teams. For us, privacy-first means treating data handling and experimentation architecture as product decisions, not adding a compliance slogan after the interesting engineering is finished.
We would rather explain how the product works than hide the important details behind an absolute compliance claim.
Split Hero is a European company, and privacy-conscious technology is part of the direction we are building towards. WordPress remains an important way people use Split Hero today, while the platform is evolving beyond a WordPress-only identity.
The aim is straightforward: make useful experimentation accessible to agencies and marketing teams, while making the privacy questions easier to understand and answer.
The question worth asking
Privacy-first A/B testing is not about collecting nothing. An experiment needs information to assign experiences and measure outcomes. The job is to make those data choices proportionate, intentional and explainable.
So the next time a testing platform calls itself privacy-first, ask something more useful than whether it has a privacy page.
Can the vendor show you what happens to data from experiment assignment to aggregated result?
If the answer is clear, you have something to evaluate. If the answer is another badge, keep asking.
Start your free trial with Split Hero.
Frequently asked questions
What is privacy-first A/B testing?
Privacy-first A/B testing is an approach to experimentation that limits data collection and retention to what is genuinely needed, keeps the purpose of the data clear, considers privacy in the assignment and measurement architecture, and makes processors and user choices understandable. It is not a formal certification.
Does A/B testing require cookie consent?
Sometimes, but not always. The answer depends on the technology used, the purpose and the jurisdiction. In the UK, certain A/B testing can fall within the PECR statistical purposes exception if its conditions are met. EU Member States apply the ePrivacy framework through national law, so implementation and local guidance matter. GDPR or UK GDPR may separately apply when personal data is processed.
Can A/B testing fall under the UK's statistical purposes exception?
Yes. The ICO's 2026 guidance explicitly gives A/B testing as an example that is likely to meet the statistical purposes exception when the required conditions are satisfied. The activity must stay within the exception's purpose and safeguards, including requirements around information, objections and the handling of individual-level data.
Is cookieless A/B testing automatically GDPR compliant?
No. A cookieless implementation may still process identifiers, IP addresses or other information, and GDPR compliance depends on the wider processing activity. Removing cookies can change the privacy picture, but it does not answer every privacy question by itself.
Is server-side A/B testing more private than client-side testing?
It can give teams more control over browser-side storage, scripts and data flows, which may support a more privacy-conscious implementation. It is not automatically more compliant. The data used, purpose, retention, processors and implementation still need to be assessed.
Does EU hosting make an A/B testing tool GDPR compliant?
No. Data location can be an important factor, particularly when considering international transfers and processors, but GDPR obligations also cover areas such as lawful processing, transparency, data minimisation, security, retention and individual rights.