Tag: Edpb
All blog posts with this tag.
- 21 Sep, 2026
Anonymous, pseudonymised or aggregated data: what the 2026 EDPB guidelines mean for analytics
In analytics products, the words “anonymous”, “anonymised”, “pseudonymised”, “aggregated” and “hashed” are often used too quickly. They create a sense of safety, but they do not always describe the same legal or technical reality. The topic is back in focus in 2026. The European Data Protection Board adopted guidelines on anonymisation, open for public consultation until 30 October 2026. The text aims to clarify the notion of anonymous data and takes recent Court of Justice of the European Union case law into account. For analytics teams, this is a good moment to review both product claims and architecture. Data is not anonymous merely because it no longer contains a name. A truncated IP address, a hashed identifier or an aggregated statistic can reduce risk, but they do not automatically move data outside the scope of personal data. Why this matters for analytics An analytics tool rarely collects a single signal. Even when it is privacy-first, it may process URLs, referrers, campaign parameters, timestamps, countries, devices, events, journeys and rare page views. Each signal may look harmless in isolation. Combined, they may sometimes make a person or behaviour recognisable, especially at low volumes: a page visited by only one person, a very specific segment, a rare conversion, a query containing personal data, or a campaign link with an identifier. The question is not only: “Do we collect direct identifiers?” The question is: could an actor with means reasonably likely to be used still relate the information to a person, and would that person then be identifiable, directly or indirectly? Anonymous, pseudonymised and aggregated are not the same Pseudonymised data replaces or masks some identifiers, but a link with a person can still exist. A hash, stable identifier or separate key can remain personal data if linkage is possible. Aggregated data groups several observations. It often reduces risk, but it does not automatically guarantee anonymity. A statistic on a very small segment can still reveal information about a person or a small group. Anonymous data no longer relates to an identified or identifiable person. That is a demanding threshold. It is not enough to remove visible names. Teams must consider reasonably available means, linkage possibilities and the context of the actor holding or receiving the data. For a blog post, product page or privacy notice, the cautious approach is to reserve “anonymous” for situations that have actually been tested. In other cases, terms such as “minimal collection”, “aggregation”, “no persistent identifier” or “reduced re-identification risk” are often more accurate. Three risks to test Anonymisation methods are usually assessed through three families of risk. 1. Isolation Can a record or unique behaviour be singled out in the dataset? Analytics example: a low-traffic internal page receives a single visit from one country during a precise time window. Even without a name, that observation may be distinctive. 2. Linkage Can several records be linked together or matched with another source? Analytics example: a hashed identifier is used in several exports, or a combination of country, device, referrer and URL makes it possible to follow the same visitor across tables. 3. Inference Can new information be inferred about a person or a small group? Analytics example: a segment such as “visitors to the enterprise pricing page from a specific prospect domain” can reveal commercial intent if volumes are too low. These risks are contextual. They depend on granularity, access to raw data, other available information and the people who can view the reports. What this changes in an analytics setup The first change is vocabulary. Teams should avoid calling data “anonymous” simply because it is cookieless or because no direct identifier is present. Cookieless does not automatically mean anonymous. The second change is architectural. Anonymisation is not assessed only at collection time. It must be considered across the pipeline: collection, preprocessing, storage, aggregation, dashboard display, exports, APIs and deletion. The third change is documentation. If an organisation claims that some data is anonymous, it should be able to explain why. Which columns remain? Which combinations were tested? What thresholds prevent small segments? Who can access raw data? How long is it kept? Example: URLs and campaign parameters URLs are a good example of underestimated risk. A visited page can reveal business context. A URL parameter can contain an email address, CRM identifier, confirmation token, campaign key or customer number. Even in a cookieless tool, storing the full URL without filtering can create accidental collection of personal data. Anonymisation will not necessarily fix the problem if sensitive data is stored in clear form before processing. The better approach is to act upstream:filter or remove risky parameters; retain useful attribution parameters in a controlled way; document filtering rules; avoid unnecessary raw exports; apply display thresholds to low-volume segments.Example: multi-site reporting Multi-site dashboards add another risk. They often consolidate data from several domains, brands, countries or entities. That is useful for governance, but it can also make some behaviours more recognisable when volumes are low. A global manager does not always need every combination of site, page, country, device and hour. A mature dashboard adapts granularity to the role: summary for leadership, operational detail for the team, restricted access to sensitive data. Anonymisation is therefore not only a technical process. It is also a question of access rights and reporting design. Audit checklist To audit analytics claims and architecture, check:is raw data still accessible? are full URLs stored? are risky URL parameters filtered before storage? are stable identifiers used, even if hashed? are small segments hidden or grouped? do exports contain more detail than dashboards? are retention periods justified? are access rights aligned with real need? does marketing use the right vocabulary? can the team explain why a dataset would be considered anonymous?How to use the consultation window The EDPB consultation is open until 30 October 2026. Not every team will submit feedback, but every team can use the deadline as an audit trigger. A useful exercise is to build a data collection summary: data collected, purposes, transformations, granularity levels, retention, access, exports and public wording. The objective is not to prove that everything is anonymous. The objective is to be accurate. A product can be privacy-first without claiming that every dataset is anonymous at every stage. Conclusion The 2026 EDPB guidelines reinforce a simple idea: anonymisation is not a magic word. It is a result to demonstrate in a specific context. For analytics, this clarification is healthy. It pushes teams to collect less, reduce granularity, filter accidental data, control exports and choose more precise wording. Privacy credibility does not come from maximalist vocabulary. It comes from coherent architecture and honest documentation. FAQ Is hashed data anonymous? Not by default. Hashing can be useful, but it does not automatically remove identifiability if the value can be linked back, guessed or combined with other data. Are aggregated analytics reports always anonymous? No. Aggregation reduces risk, but small segments, rare events or unusual combinations can still reveal information about a person or organisation. The relevant question is whether re-identification remains reasonably possible in context. Why does the consultation matter for web analytics? Because analytics vendors and customers often rely on the words anonymous, pseudonymised and aggregated. The EDPB draft gives teams a better checklist for testing those claims. SourcesEDPB - Guidelines 02/2026 on Anonymisation, public consultation EDPB - EDPB sheds light on anonymisation and web scraping for generative AI EDPB - Public consultations