Quick answer
Pseudonymization is the processing of personal data so that it can no longer be attributed to a specific person without additional information, which is kept separately and protected (GDPR Art. 4(5)). Pseudonymized data is still personal data, unlike anonymized data.
What is pseudonymization?
Pseudonymization replaces data that directly identifies a person, such as a name, email address or customer number, with a substitute value (a pseudonym), and keeps the information needed to link the pseudonym back to the person separately and under protection.
The GDPR defines it in Article 4(5) as processing personal data so that it "can no longer be attributed to a specific data subject without the use of additional information", provided that additional information is kept separately and protected by technical and organizational measures.
Pseudonymization vs anonymization
| Pseudonymized data | Anonymized data | |
|---|---|---|
| Can it be linked back to a person? | Yes, with the separately held key or table | No, by any reasonably likely means |
| Still personal data under the GDPR? | Yes (Recital 26) | No |
| GDPR obligations apply? | Yes, with lower risk | No |
| Useful for | Analytics per user, debugging, joining datasets safely | Published statistics, open datasets, aggregate reports |
| Example | user_7f3a9c instead of maria@example.com | "4,210 sign-ups from Germany in October" |
The most common mistake is calling hashed or tokenized data "anonymous". If you, or anyone with access to the key or a list of candidate values, can reverse it, it is pseudonymous.
Common pseudonymization techniques
| Technique | How it works | Strength and caveats |
|---|---|---|
| Random ID with lookup table | Assign a random ID; store the mapping separately | Strong if the table is protected; easy to delete the link |
| Keyed hash (HMAC) | HMAC-SHA256(secret_key, email) | Same input gives same output for joins; strong if the key stays secret |
| Plain hash | SHA256(email) | Weak: anyone can hash a list of known emails and match them |
| Encryption | Encrypt the identifier with a key | Reversible by design; key management is everything |
| Tokenization | Replace with a token from a vault service | Common for payment data |
| Generalization | Truncate or coarsen: IP 203.0.113.0, birth year instead of date | Reduces precision; often combined with the above |
Worked example: why plain hashes are not enough
An analytics table stores SHA256(lowercase(email)) as the user key. A marketing partner has a list of 50,000 customer emails. By hashing their list the same way, they match every user who appears on both lists, no key required. The "hashed" column was a lookup key all along.
Using a keyed hash instead, HMAC-SHA256(k, email) with a secret k held only by your data team, the partner cannot reproduce the values. If k is rotated or destroyed, past pseudonyms can no longer be linked to new data, which is a practical way to limit how long linkage is possible.
Why pseudonymize?
- Lower risk if data leaks. A breached table of pseudonyms reveals far less than names and emails.
- Data minimization in practice. Analysts can count, segment and join by user without seeing who the user is.
- Regulatory credit. The GDPR names pseudonymization as an appropriate safeguard for security (Art. 32), data protection by design (Art. 25) and research or statistics (Art. 89).
- Safer sharing and testing. Development and test environments can use pseudonymized copies instead of production identities.
Limits
- Re-identification through other fields. Rare combinations of location, device and timestamps can single someone out even without direct identifiers.
- Key management. Whoever holds the key can reverse the pseudonyms; store it apart from the data, restrict access, log use.
- Still in scope. Access requests, deletion requests and retention limits still apply to pseudonymized data.
In TapCub
TapCub applies several of these techniques by default. Anonymous web visitors are counted with a visitor ID that the collector derives by hashing a site salt with address and browser data; the website script writes no cookie. The strict privacy preset rotates that salt every day, so the same browser cannot be linked across days. Both presets truncate the IP address before storage. When a project identifies users and a login uses an email as the ID, the email is lowercased and hashed. You still decide what goes into event properties; see keep personal data out of analytics, IP truncation and retention and hashing.
See also: What is PII? Personally identifiable information, with examples.
Sources
- GDPR. Article 4: definitions (5) pseudonymisation and Recital 26.
- ENISA. Pseudonymisation techniques and best practices (2019).
- NIST. Glossary: pseudonymization.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Solutions Engineer
Covers SDKs, API integrations, and data implementation, with an emphasis on validation, system interoperability, and troubleshooting.