Articles / Privacy Law

857 words

  • uk-law
  • pecr
  • cookies
  • ab-testing
  • data-protection
  • ico

Is Your Server-Side A/B Test Cookie Exempt Under PECR?

Moving your A/B test to the server doesn't take it outside PECR. The rule bites on storing something on the visitor's device, and a Set-Cookie header does exactly that, whether a JavaScript snippet or your Go handler produced it.

What can save you is an exception, not the architecture. Since the Data (Use and Access) Act 2025 amended PECR, there is a statistical purposes exception that might cover a plain experiment cookie. Whether yours qualifies depends on a few details that are easy to get wrong.

The cookie is the trigger, not the client-side script

PECR regulation 6 asks whether you store information on, or gain access to information stored on, a user's terminal equipment. Consent is required unless an exception applies. Where the code runs is irrelevant.

A typical server-side test looks like this:

func variant(w http.ResponseWriter, r *http.Request) string {
	if c, err := r.Cookie("exp_checkout"); err == nil && (c.Value == "a" || c.Value == "b") {
		return c.Value
	}
	v := "a"
	if rand.IntN(2) == 1 {
		v = "b"
	}
	http.SetCookie(w, &http.Cookie{
		Name:     "exp_checkout",
		Value:    v,
		Path:     "/",
		MaxAge:   14 * 24 * 3600,
		Secure:   true,
		HttpOnly: true,
		SameSite: http.SameSiteLaxMode,
	})
	return v
}

Both halves are regulated: writing the cookie, and reading it back on the next request. The server-side part only means the browser never runs your experiment code.

Why "strictly necessary" is the wrong exception

The older exception covers storage that is strictly necessary to provide a service the user asked for. An experiment cookie isn't that. The user asked for a checkout page; they didn't ask for variant B, and the page works without the test.

This is the argument that always gets tried and always fails. Useful to you is not the same as necessary for them.

The newer statistical purposes exception

The 2025 Act added exceptions to PECR, including one for collecting information about how a service is used, with a view to improving it. The ICO's storage and access technologies guidance (finalised in April 2026, according to its own page) covers it. There is also a related exception for adapting how a site appears or functions.

An A/B test aimed at improving your own service is a plausible fit. Two conditions come attached:

  • Users get clear and comprehensive information about the use.
  • Users get a simple, free way to object.

Note the second one. If someone objects, your code needs to stop setting the cookie and serve a default experience. A cookie banner you've not wired to anything doesn't count.

The word "solely" is where tests go wrong

The ICO reads the exceptions as applying only where the storage or access is for that purpose and not for any other purpose at the same time. If one purpose fits an exception and another doesn't, you need consent for the storage.

So ask what else the experiment cookie touches:

  • Is the same ID sent to an ad platform, or used to measure ad performance?
  • Does it follow the user across sites, or feed a profile?
  • Is the "test" really a personalised-pricing or targeting mechanism?
  • Does a third-party experimentation vendor reuse the ID for its own purposes?

The ICO lists advertising-related purposes, ad measurement among them, as things that sit outside the statistical exception. If any answer is yes, the cookie probably needs consent.

Quick detour: can you avoid the cookie entirely?

Yes, sometimes. If you don't need a stable assignment across visits, you can bucket per request or per session and store nothing. You can also pick a variant by hashing something that is already in the request.

Be careful about that second idea. It removes the cookie question only if you're not gaining access to information stored on the device, and I wouldn't lean on a clever reading of that. Meanwhile, a hash of an IP address or user agent is still likely to be personal data, so UK GDPR doesn't go away. Per-request assignment is the cleanest, though it makes for noisy tests, since one person may see both variants.

PECR is only half of it

If the experiment ID is linked to a person, or can single one out, UK GDPR applies too. You need a lawful basis, a retention period and a place for it in your privacy notice. The PECR exception removes the consent requirement for the storage; it doesn't remove the data protection duties for what you then do with the data.

A decent practice is to keep the experiment ID separate from account IDs and delete results data once the test is decided.

A practical checklist

  1. Write down the single purpose of the cookie. If you can't state it in one sentence, that's a warning.
  2. Check that no vendor or internal pipeline reuses the ID for ads, profiling or cross-site matching.
  3. Tell users about it in plain words, and offer an objection route that really switches the cookie off.
  4. Give it a short expiry matching the test, rather than a year.
  5. Where you can't tick all of the above, ask for consent before setting it.

This is general information, not legal advice. The ICO guidance is the place to check precise wording, and I haven't found it giving an A/B-testing-specific ruling, so the reasoning above is my reading of how the statistical exception applies. Treat it as a starting point for your own assessment. The primary sources are the ICO's page on the exceptions and the government factsheet on the PEC Regulations changes.

← All articles