Anonymize email open tracking: what is allowed... or not!

Since CNIL recommendation on email tracking pixels, one phrase comes up in almost every discussion with routers and CRM managers: «anyway, if it's anonymized, we're in the clear.» But since the recommendation was published in April, some have backtracked, others are still asking themselves the question... whatever happens, it remains far from clear.

A partner recently asked us the following question: their solution anonymizes open data «throughout the entire processing chain, without ex-post processing», is that enough to do without consent? The DPO of one of their clients answered no, on the grounds that the anonymization takes place downstream of the collection, and that’upstream, there is necessarily a processing, which, for its part, presupposes a processing basis.

The DPO is right. But her conclusion deserves to be clarified. Let's break it down.

⚠️ Badsender Operational Analysis. We are neither legal experts nor lawyers: we simply follow the topic very closely. Nothing that follows is legal advice, have your case validated by your own DPO.

The initial misunderstanding: anonymization is not a legal basis

To understand, we must separate two moments that anonymization does not place on the same level at all: the collection on the one hand, reuse on the other hand.

Collection is the triggering of the pixel. When the email client loads the invisible image, it performs a read/write operation on the recipient's device. This operation is governed by Article 82 of the Data Protection Act (transposition of Article 5.3 of the ePrivacy Directive). And the CNIL could not be clearer in its July 22 FAQ (question 18): «Article 82 of the Data Protection Act applies whether the data concerned is personal or not»and «prior anonymization of data on the device is not a sufficient condition to exempt their collection from consent».

What makes a pixel lawful is not the nature of the data that comes out of it, it is what justifies the reading operation. In other words, we need a foundation, and that foundation is either the consent, let's say exemption (deliverability or security). The fact that a platform anonymizes «throughout the entire chain» changes nothing at this level: data anonymity does not create a processing basis where one does not exist.

That is precisely the DPO's reasoning: anonymization comes downstream, while upstream there is indeed a processing operation (reading) that must be based on a legal basis for processing. Where her formulation «that requires specific consent» is a bit too absolute is that in reality it requires a legal basis: consent OR exemption. And for deliverability, the CNIL specifically provides an exemption.

Anonymization of statistics, what the CNIL really authorizes: question 6 of the FAQ

Here is the good news. In the same FAQ, in the Question 6, the CNIL responds directly to our question:

«Is it possible to use data collected using exempted pixels to establish overall open rate statistics for a campaign without consent?»
«Yes. When data is collected using a pixel, whether this collection is subject to consent or benefits from an exemption, its reuse does not require consent if it has been effectively anonymized beforehand, for example through an aggregation process. Data collected by an exempt pixel can thus [...] be used to establish overall statistics on a campaign's open rate.»

This is the pivot of the entire reasoning that valid the pattern that many sending platforms will adopt: a deliverability pixel (exempt, therefore placed without consent), whose data is used, after aggregation, to display a overall open rate per campaign. It is legal, but with conditions.

The rule to remember can be summed up in a few words: You have the right to count, not to attach.

«What does »effective anonymisation" mean exactly?

In the vocabulary of the CNIL and the European Data Protection Board, data is only «anonymous» if it can no longer, in any irreversible :

• isolate an individual in the dataset (singling out) ;
• correlate two records relating to the same person (correlation); ;
• infer information about a person (inference).

As long as these three risks are not eliminated, we do not have anonymity. A hashed contact identifier associated with an opening history is not anonymous: it is completely re-identifiable. «It is hashed» or «our platform manages it» are not acceptable answers.

The pitfalls to avoid in this story of window anonymization

1. Confusing pseudonymity and anonymity. Trap number one. As soon as open data remains traceable to a contact, even via a technical identifier, it is considered individual tracking, and therefore requires consent.

2. Forget the audience size. A «rate» calculated on a handful of recipients can, in fact, identify a person (if three people received the email and only one opened it, the aggregate does not anonymize anything). An aggregate is only anonymous if the audience is large enough. This applies to small domains, but also to small campaigns and small segments.

3. Believing that over-collection is being caught up. The FAQ (question 7) is clear: «the only data necessary for this purpose is the date the email was last opened». Embedding the IP address, user-agent, or keeping an open log per contact per campaign «to calculate stats,» done lose the exemption the fact that this data «are anonymized or deleted shortly after their collection does not call into question the fact that they were collected beyond what is necessary». Over-collection cannot be made up for by anonymization. a posteriori.

This is the most subtle technical point. To manage statistics by campaign, the server must know, at the time the pixel is called, which campaign it is. Is this prohibited? No: the campaign identifier at the time of the request is not the «additional data» targeted by Q7 (which targets what enriches the individual profile : IP, user-agent…). What matters is that the Exit let it be an anonymous aggregate and that we do not keep of individualized and linkable open history. It is therefore possible to count the opens of a campaign without keeping «who opened what».

And what about the destination domain? (the core of deliverability monitoring)

There is one case that neither the recommendation nor the FAQ addresses, and it is precisely the one that interests deliverability teams the most: tracking open rates by destination domain (Gmail, Orange, Outlook, Yahoo...). This is the basic building block of deliverability monitoring: this is how you spot a placement in the spam folder at a specific email provider.

Yet the raw material is «clean»: the statistic can be built, at the moment the pixel is called, from the same deliverability pixel (the one that updates the last-opened date), in the form of simple aggregated counters, without storing «who opened what.» The problem is not the source, it is the level of detail. The FAQ explicitly validates the anonymous statistic at the campaign level (Q6). At the level of destination domain, however, she says nothing.

Our reading: nothing prohibits it in principle (it's yet another aggregate, and deliverability monitoring is a perfectly legitimate purpose), but since the CNIL hasn't explicitly validated it, we are in deliberate gray area. The rule of caution is simple: try, but maintain strict anonymization criteria. Everything comes down to the mesh size. On a large domain (Gmail, Orange, etc.), an open rate per domain remains an anonymous aggregate. On a small domain (that of an SME with three addresses) or a small sending volume, the domain × campaign intersection can effectively identify a person, and at that point, we fall back under consent requirements.

In practice: set a minimum audience threshold per grid cell (domain × campaign) below which the statistic is simply not displayed. This is your best defense the day you are asked to prove that your «domain stats» are truly anonymous.

How routers go about it (and what to ask them)

Two major philosophies emerge in the’implementation of tracking pixels on sending platforms, and the choice is not neutral for your metrics (and some will undoubtedly change their approach again in the future).

The «anonymization-first» approach. We place an anonymous pixel (for everyone, or only for non-consenting users) and we only expose aggregates. We thus maintain an overall open rate without consent, following the logic of Q6.

The «consent-first» approach. We are focusing on collecting tracking consent, contact by contact, and without consent we limit ourselves to the deliverability exemption.

The right questions to ask your router: In the "anonymization first" approach, what is the legal basis that justifies the presence of a tracking pixel? Is anonymization effective (irreversible and without the possibility of re-identification) or is it just a masked identifier? Is the deliverability pixel minimized (date of last opening, without IP or user-agent)? Does it keep an opening history per contact? Are the exposed statistics true aggregates Can we document all this in case of an audit?

Our recommendation: the «clean anonymization» checklist»

If you want to keep driving your global openings without consent, hold the line to the very end:

1. A minimized deliverability pixel only the date of the last opening is kept (by day, without the time), overwritten with each new opening. No IP, no user-agent.
2. Exclusively on «expressly requested» emails» : transactional or emails for which there is consent to receive them. Unsolicited prospecting (B2B, similar products/services) does not fall under the deliverability exemption.
3. Truly aggregated and anonymous outputs : no statistics on audiences that are too small — including when broken down by destination domain.
4. No individualized and traceable opening history preserved.
5. A watertight border with marketing as soon as it comes to optimizing, personalizing, targeting, or adapting frequency at the individual level? Consent.
6. Some documentation to be able to explain how The data is anonymized. That's the first thing you will be asked.

In summary

Anonymization is not a magic wand that would make the need for consent disappear. It secures the reuse data, not theirs collection. Properly understood, however, it is a genuine path to survival: one can continue to measure overall open rates per campaign without consent, provided one relies on a pixel genuinely restricted to deliverability.