Pseudonymised data

Data in which identifying fields, such as client names, have been replaced with identifiers, and the mapping from identifier to name is kept separately by the data owner.

DefinitionData in which identifying fields, such as client names, have been replaced with identifiers, and the mapping from identifier to name is kept separately by the data owner.

Why it matters for analytics

Coverage, share of wallet and penetration never need a name. They need an identifier that is stable across rows and periods. Replacing the name column with an ID before a file leaves the firm means the analytics provider holds figures and IDs only, and the compliance question changes from "who holds our client names" to "who holds our numbers".

Still personal data

Under UK and EU data protection law, pseudonymised data remains personal data if the mapping exists somewhere. The safeguards are lighter, not absent: a data processing agreement, access controls and deletion on request still apply.

In practice

One column. The firm keeps the mapping in its own spreadsheet or system. Every screen and every answer works on the ID.

How it is used

Names and other identifying fields are replaced by stable identifiers before upload, and the key that reverses the mapping stays with the customer. Analysis runs on identifiers; names are re-attached on the customer's side.

Example

Client 40017 shows a share of wallet of 22 percent and no contact in 80 days. Only the firm holding the key knows which client that is.

Where it goes wrong

Confused with anonymisation, which cannot be reversed and makes account-level lists impossible. It is also still personal data in law.

Articles that use this term

How-to guides

GDPR and sales analytics: what an analytics tool should never need from you

A plain guide for a sales leader and a data protection officer evaluating an analytics tool under GDPR and UK GDPR: which fields coverage and share-of-wallet analysis actually needs, why customer and contact names are not among them, what pseudonymisation at export means in practice, the lawful basis question, the data that stays in the building, and the six questions a DPO should ask before an export leaves.

16 Sept 20263 min read Data quality and reconciliation

How to replace client names with IDs before uploading sales data

A practical method for pseudonymising a sales export before it leaves the firm: which columns identify a person or a client, how to build a stable ID mapping in a spreadsheet the firm keeps, what stays personal data under UK GDPR anyway, and how to check the file still reconciles afterwards.

16 Sept 20263 min read How-to guides

Pseudonymisation vs anonymisation for sales analytics: which one you need, and why

The difference between pseudonymised and anonymised data as it applies to a sales export, why coverage and share-of-wallet analysis needs the first and cannot use the second, what pseudonymisation at export looks like in practice, the lookup that stays in the building, what is still personal data and what is not, and the three mistakes that turn a pseudonymised file back into a named one.

16 Sept 20263 min read AI and self-service analytics · Compliance

Is it safe to upload customer data to an AI analytics tool? Nine questions to ask first

A checklist for anyone about to put a customer ledger, a CRM export or a contract file into an AI analytics tool. It covers what is actually in a sales export that makes it sensitive, the nine questions to put to any vendor, covering model training, where data is processed, who at the vendor can see it, retention and deletion, tenancy, pseudonymisation, access control, the model provider behind the tool, and what happens at exit, what a good answer sounds like for each, and how to reduce the risk yourself by removing what the analysis does not need.

17 Sept 20265 min read