Articles / Privacy Law

897 words

  • uk-law
  • pecr
  • email-marketing
  • tracking-pixels
  • uk-gdpr
  • ico

Does PECR Cover the Tracking Pixel in Your Marketing Email?

Short answer: the ICO says yes, it can, and that surprises people because an email is not a website. There is no cookie banner in a newsletter, so the pixel at the bottom tends to get treated as a purely technical detail. The legal position is less relaxed than that.

This is general information, not legal advice. Where I am giving my own reading rather than the law or the regulator's view, I will say so.

What the pixel actually does

A tracking pixel is an image, usually 1x1 and transparent, whose URL is unique to the recipient. When the mail client loads it, your server gets a request. That request is the whole trick.

Here is a minimal Go handler for one, to show how little it takes:

package main

import (
	"encoding/base64"
	"log/slog"
	"net/http"
)

// 1x1 transparent GIF
var gif, _ = base64.StdEncoding.DecodeString(
	"R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7")

func pixel(w http.ResponseWriter, r *http.Request) {
	slog.Info("email opened",
		"recipient", r.PathValue("id"),
		"ip", r.RemoteAddr,
		"ua", r.UserAgent(),
	)
	w.Header().Set("Content-Type", "image/gif")
	w.Header().Set("Cache-Control", "no-store")
	w.Write(gif)
}

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("GET /p/{id}.gif", pixel)
	http.ListenAndServe(":8080", mux)
}

That log line holds a recipient identifier, an IP address, a user agent and a timestamp. Hold that thought, because it matters for the second half of the answer.

Which rule is which

Two different regimes are in play, and mixing them up is the usual mistake:

  • PECR regulation 22 governs sending the marketing email at all (consent, or the "soft opt-in" for existing customers, plus an opt-out in every message).
  • PECR regulation 6 governs storing information on, or gaining access to information stored on, a user's device.
  • UK GDPR governs the personal data you collect and what you do with it.

Regulation 22 is not about the pixel. You can have a perfectly lawful soft opt-in and still have a separate problem with how you measure opens.

Is a remote image really "access to the device"?

Regulation 6 is the one people doubt. The text of regulation 6 is about storing information, or gaining access to information already stored, in a subscriber's or user's terminal equipment. A plain image fetch looks like an ordinary request that the user's client chose to make.

The ICO takes a broader view. Its guidance on storage and access technologies names tracking pixels as in scope, and its reasoning is that the technique is used to collect information about the device and its user, such as when a message was opened, from where, and on what. That is regulator guidance, not a court ruling, and I am not aware of a decision settling exactly how far it stretches.

My own reading: the ICO position is defensible where the pixel is designed to learn things about the recipient's device or behaviour. It is weaker where a mail client simply fetches an image and you log nothing beyond the request. Do not build a compliance plan on that weaker reading.

The exemptions changed in 2025

The Data (Use and Access) Act 2025 added new exceptions to the consent requirement in regulation 6, covering things like strictly necessary purposes and some statistical and appearance-related uses. Check the current wording and its commencement status rather than relying on a blog post, including this one.

Here is the catch for pixels. The statistical-purposes exception is framed around improving a service. Open-rate tracking tied to an individual recipient, so that you can retarget or score them, is hard to squeeze into that. Aggregate counts with no per-person identifier sit more comfortably, though that is my interpretation, not guidance.

Quick detour: opens are barely measurable anyway

Here is the bit that made me laugh. Apple Mail Privacy Protection fetches remote images through proxies, often ahead of time, whether or not the person ever reads the message. Some other clients and security scanners do the same.

So a lot of your "opens" are a machine fetching the pixel. The data is noisy, it inflates the numbers, and you are carrying legal risk to collect something that is partly fiction.

UK GDPR still applies either way

Even if you decided regulation 6 did not bite, the log line above is personal data. A per-recipient ID tied to an email address is plainly identifying, and an IP address usually is too. So you need a lawful basis, transparency and a retention period.

PECR consent also feeds into the GDPR side. Where regulation 6 requires consent, the standard is the UK GDPR consent standard: specific, informed, unambiguous, and not bundled into a general "you agreed to our emails". Legitimate interests will not rescue something PECR says needs consent.

What I would do in practice

  1. Decide whether you need per-person open data at all. Click tracking is a more deliberate signal, and clicks are a real user action.
  2. If you do track opens, say so in the privacy notice and the email footer, and get consent where the ICO guidance points to it.
  3. Prefer aggregate counts, with no recipient ID in the pixel URL, when you only want campaign-level numbers.
  4. Set a short retention period for the raw pixel logs, and do not keep IP addresses you do not need.
  5. Honour an opt-out for tracking, not just for the emails.
  6. Treat Apple-style prefetch as noise: do not trigger decisions, such as "inactive subscriber, delete", from open data alone.

The penalties are not trivial. The 2025 Act aligned PECR enforcement with the UK GDPR's higher fine levels; again, verify the commencement date for your situation.

The uncomfortable conclusion is that the pixel is both legally awkward and technically unreliable. When the data is that poor, the cheapest compliance fix may be to stop collecting it.

← All articles