The EDPB’s new data anonymization guidelines: what they mean for your analytics data

On 7 July 2026 the European Data Protection Board (EDPB) adopted Guidelines 02/2026 on anonymization for public consultation. They replace the thinking behind the 2014 Article 29 Working Party opinion and reset the bar for when data leaves the scope of the GDPR. If you run analytics and lean on words like “anonymous” or “cookieless” in your compliance story, this is the document that now defines whether those words hold up.

This article breaks down the framework for anonymous data collection: the legal test, the three criteria you assess against, the questions the EDPB left open, and a practical mapping of analytics controls to each criterion. We flag what is settled and what still needs your own judgment. If your job is to report on marketing performance, the practical takeaway is this: the right setup lets you stay compliant and still see the full picture of your traffic.

Disclaimer: This article summarises EDPB Guidelines 02/2026 on data anonymization (version 1.0, adopted 7 July 2026, currently under public consultation). It’s general information, not legal advice. Assess your own configuration against the guidelines and consult your data protection counsel where needed.

What changed in the EDPB’s 2026 data anonymization guidelines?

The EDPB’s 2014 guidance framed data anonymization around techniques you apply. The 2026 guidelines for anonymizing data shift the question to outcomes and context. Under the GDPR, data is anonymous when it no longer relates to an identified or identifiable person, and the EDPB is clear that whether this holds true can vary from one entity to another.

Two ideas do most of the work. First, identification is judged by “means reasonably likely to be used” and the risk only needs to be very low, not completely impossible. Second, anonymity is relative. The same dataset can be anonymous for a recipient with limited means while staying personal data for a party that holds extra information or has the technical capability to re-identify.

Why isn’t removing IP addresses and cookies enough anymore?

The guidelines describe identification through direct identifiers and through combinations of ordinary attributes that together become unique and a way to recognize the same person across pages and visits, even without a cookie or an IP address.

Some examples:

• Device fingerprints built from browser
• Operating system
• Screen resolution
• Time zone

So a dataset with no names and masked IPs can still fail the test if its records are detailed enough to isolate one person, match a second source, or support a specific and meaningful inference about them. The assessment looks at the whole shape of the data, not the presence or absence of a single field.

What are the three criteria for anonymous data?

The EDPB tests anonymity against three criteria: No Record Isolation, No Linkage and No Inference. Pass all three, under either assessment approach, and the data can be treated as anonymous.

1.  No record isolation: can you single out one person?

Met when the data holds no unique combination of attribute values that maps to a single individual. The more attributes a record carries, the more likely it becomes unique, and the easier it is to isolate someone within the set.

2.  No linkage: can you connect records to another source?

Met when the data can’t be matched to similar information about the same person held elsewhere. Linkage risk rises when records overlap with data recorded in other contexts, including sources a third party could obtain.

3.  No inference: can you deduce something specific about a person?

Met when no specific and meaningful inference can be drawn about an identified or identifiable person. An inference is meaningful only when it relies on that person’s data, not on general facts about the population.

If one criterion fails, the data isn’t automatically personal. The guidelines call for further analysis of whether the isolated or linked records actually let you single out and act on an individual. Record-level data with high dimensionality and high resolution is the most exposed; aggregated statistics are generally harder to attack, though not immune.

What’s the difference between the contextual and simplified approach?

There are two ways to run the same three criteria above. The contextual approach weighs each entity’s real means of re-identification, so data can be anonymous for some parties and not others. The simplified approach ignores those differences and treats any theoretical re-identification as disqualifying.

How the two anonymization assessment approaches compare

	Contextual approach	Simplified approach
What it weighs	Each entity’s actual means and the likelihood they use them	Ignores differences between entities
Result	Data can be anonymous for some parties, non anonymous for others	One verdict for everyone
Main risk	False positives, if you miss an entity’s capabilities	False negatives, treating anonymous data as personal
Best for	A full, defensible assessment of a specific analytics setup	A quick, cautious first pass

The EDPB suggests combining them. Start simplified: is re-identification even possible in theory? If not, you’re done. If it is, move to the contextual approach and test whether the relevant parties could realistically pull it off with the means available to them.

What did the guidelines leave unclear?

There are no numerical risk thresholds, no approved universal configurations, and no automatic “anonymous analytics” certification. Every implementation still needs a contextual assessment, and the document is under public consultation.

• How realistic re-identification risks must be. It remains unclear how much weight should be given to hypothetical future transfers, accidental identification, cybercriminals, rogue employees or unlawfully obtained data. 
• Whether record isolation equals identification. The guidelines suggest that singling out one session may make a person identifiable, but they do not clearly explain when distinguishing a record becomes identifying the human behind it. 
• How mixed datasets should be handled. The phrase “not treated separately” is undefined. It’s unclear whether logical separation is enough and whether one identifiable record should bring into question an entire dataset under the GDPR. 
• No blessed setup. No specific tool configuration is certified anonymous. A configuration that clears the bar for one dataset and audience may not for another.
• Anonymity can expire. Re-identification risk tends to rise over time as techniques improve and more auxiliary data appears. The EDPB recommends periodic reassessment, and a security incident can force one.
• Still a draft. The guidelines are open for public consultation, so specifics may change before the final version.

Because of issues such as those identified above, data and tech law experts are questioning if “the EDPB’s attempt to rewrite key data protection concepts creates more issues than it solves.”

How does Piwik PRO help you meet these criteria?

For a marketing team, this is what lets you report numbers you can defend. With Piwik PRO, your analytics data is collected first-party and stays yours, in a cloud environment you choose, with EU-based options. Because the data isn’t handed to an outside platform, your assessment stays simple, and you keep a complete view of your traffic instead of the partial picture consent gaps leave behind. Here’s how the specific controls line up with the three criteria:

Collect only the data you need, by default

By default, Piwik PRO’s anonymous mode collects only what you need to measure performance, and leaves custom dimensions, events and goals switched off until you deliberately turn them on. That keeps session records lean, which lowers the chance that a combination of attributes could isolate a visitor, link to other data or support an inference. You can add more detail whenever a campaign or report calls for it, so you start from a clean, defensible baseline and scale up on your terms. 

Keep location insight without storing full IP addresses

You can mask a chosen number of bytes from every IP address before it’s written to the database, so the full address is never stored. Location can be resolved from the unmasked address first and then held only at country or continent level. This trims high-resolution attributes that feed record isolation and linkage, since a masked IP and a country are far weaker matching keys than a full address.

For your reports, you still see where visitors come from at country level, enough to judge which markets and campaigns are working.

Measure sessions accurately without a permanent ID

For non-consenting visitors you can recognize a session using a session hash rather than a persistent identifier. The hash is derived from client characteristics, salted, and kept only in memory for up to 30 minutes after the last action, then discarded. Salting means identical inputs don’t produce a reusable identifier, which directly limits cross-session linkage.

Because the link between visitor and session is dropped once the session ends, re-identification across visits is designed out rather than merely discouraged.

You keep reliable session and source data for attribution, without carrying an identifier that would tie visits back to a person.

Use fewer cookies, and still count what matters

The session identifier cookie carries no personal data and the browser deletes it after 30 minutes.

You can run with the cookie, with the session hash alone, or with neither, in which case every event is treated as a new session and returning visitors aren’t recognized. Turning identifiers off removes the mechanism that would let you single out a returning individual, which speaks to record isolation.

You decide the trade-off: keep returning-visitor insight, or go lighter for stricter cases, without switching platforms.

Control who can see visitor-level detail

A dedicated setting hides the session log report and the tracker debugger and warns on API key creation, so raw visitor-level detail isn’t exposed across your team. Your analysts still get the reports and dashboards they work from every day. The guidelines are clear that access controls alone don’t make data anonymous, but they’re a documented part of the contextual assessment, showing you’ve limited who can reach the underlying data. In Piwik PRO, this is a single setting aligned with CNIL’s guidance for consent-exempt analytics:

With the CNIL setting on, the session log report is hidden, so visitor-level detail stays out of reach, even across connected meta sites and apps.

Choose how much data you collect, and keep the insight you need

Rather than one fixed mode, there are three anonymous tracking methods. You choose how strict to be, and you can tighten it where a dataset or audience needs it.

Method	Identifier	What you keep	Trade-off
Cookies + session data	30-min session cookie	Sessions, goals, funnels, most metrics	Most robust to browser or IP changes
Session hash, no cookies	30-min salted hash	Similar session-level analytics	– Sessions of different visitors can occasionally merge – No record isolation – No linkage with other information – No meaningful inference about an individual
No cookies, no hash	None	Event counts: page views, downloads, searches	No sessions, funnels or returning-visitor detection

The point isn’t that any one of these is automatically “anonymous” in the EDPB’s sense. It’s that you can dial resolution and persistence down to the level your own assessment calls for, and switch mechanisms off entirely for the strictest cases, without losing the platform.

Own your data, and decide where it goes

Your raw session- and event-level data stays in your account, and you decide sees it and where it goes, so the No Linkage and No Inference criteria stay in your hands. Exporting detailed records or combining them with a CRM or data warehouse is exactly the kind of change  the contextual approach asks you to reassess. Keeping your analysis first-party, aggregated and access-controlled is what keeps that assessment manageable, and lets you activate audiences without handing data to an outside platform.

Nordic analytics agency Hopkins put this into practice for a B2B client, running anonymous Piwik PRO alongside their consent-based analytics. The result:

Where does data anonymization fit in your privacy setup?

Anonymous data collection handles non-consenting traffic; consent management, EU hosting and first-party ownership handle the rest. Together they give you a story you can document, which is what the guidelines ultimately ask for.

The EDPB stresses documentation and transparency: state that personal data is processed to produce anonymous data, avoid calling data anonymous when people are still identifiable, and keep records of your assessment. 

Pairing configurable anonymous analytics with a consent management platform, EU-based hosting options and full first-party ownership gives you the raw material for that documentation, and keeps the contextual assessment centered on an environment you actually control. 

The direction of EU law points the same way: the proposed Digital Omnibus would let organizations run first-party analytics without a consent banner when set criteria are met.

Frequently asked questions

Related reading:

• Anonymous website visitor tracking: how to do useful analytics without personal data 
• Data anonymization in analytics: the ultimate guide 
• 6 ways analytics software collects data online 
• First-party analytics without consent: your Digital Omnibus compliance guide 
• EDPB’s guidelines 02/2026 on anonymization adopted on 7 July 2026 (Full text version)