Sign in

Blog · 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.

The short answerAnonymised data cannot be linked back to a person or a company by anyone; pseudonymised data has had its names replaced with identifiers, and the lookup from identifier to name exists somewhere, held by the company. Sales analytics needs the second: coverage, share of wallet and dormancy are computed per account and reported back per account, and an anonymised file has no account to report back to. Pseudonymise at export, replacing every name and contact detail with the identifier the source already has, keep the lookup at home, and the file that leaves is codes and numbers. It is still in scope for data protection, at much lower risk, and it is the right design.

The words are used interchangeably and they mean different things, and for sales analytics the difference decides whether the analysis can produce anything. This guide sets out both, why the analysis needs pseudonymisation and cannot use anonymisation, what pseudonymising an export looks like, and the mistakes that undo it.

The two definitions

Pseudonymised Anonymised
Names replaced with identifiers Yes Yes
Lookup from identifier to name exists Yes, held by the company No, destroyed or never made
Can the company re-identify? Yes, with the lookup No
Can anyone else? No, without the lookup No
Still in scope for data protection? Yes, at lower risk No
Usable for account-level analysis? Yes No

Why the analysis needs pseudonymisation

Every measure on this site produces a list per account: untouched, below norm, dormant, slipped. The list is only useful if the company can act on it, which means knowing which account row 1 is. Pseudonymised, the company reads 4471 and looks it up. Anonymised, row 1 is nobody, and the list is a statistic.

Pseudonymising at export

Field in the source In the export
Customer name Customer ID, as the source already holds it
Contact name, email, phone Dropped, or a contact ID if contact-level analysis is needed
Rep name Rep ID
Opportunity name Opportunity ID
Free-text notes Dropped
Address Dropped, or a region code
Amounts, dates, product codes, stages Unchanged

The identifiers are the ones the source system uses. No new coding scheme; no mapping to maintain. The lookup is the source system.

What stays in the building

  • The lookup: identifier to name.
  • Every field in the dropped column above.

Three mistakes that undo it

The lookup sent with the file. Then the file is named, and the export is not pseudonymised whatever the columns say.

A free-text field left in. Notes name people. One column undoes the rest.

An identifier that is a name. A customer ID of "ACME-LTD" or a rep ID that is an email address. The identifier has to be opaque, or it is the name with extra steps.

A worked check

Check Result
Any column with names? No: CustomerName, RepName, ContactEmail, Notes dropped
Any identifier that reads as a name? No: numeric customer IDs; rep IDs R-01 to R-24
Lookup in the file or the upload? No
Free text? No
Fields present CustomerID, RepID, TeamID, RegionID, ProductCode, InvoiceDate, InvoiceValue

Seven columns, all codes and numbers. The analysis needs nothing else.

Where it goes wrong

Anonymised because it sounded safer. The output disappeared with the names.

Pseudonymised in name only. Identifiers that are names; notes left in.

Treated as out of scope. It is in scope, at lower risk; the record says so.

Lookup rebuilt at the vendor. Then the vendor holds names, and the design is broken.

Identifiers out, lookup at home

Covirage computes on identifiers, never needs the lookup, and returns every table keyed on the same identifiers the export used. The pseudonymisation how-to covers the export step by step, and the GDPR guide covers the six questions a data protection officer should ask.

Questions people ask

Why not anonymise?

Because an anonymised file cannot say which account is untouched. The whole output of coverage intelligence is a list of accounts to act on, and the account has to be identifiable to the company that receives the list. Anonymisation removes the output along with the risk.

Is pseudonymised data still personal data?

For individuals, yes, where the company can re-identify them with its lookup. For company customers, an account code is not personal data at all. The rep identifier is an employee's, and it is processed under the employment relationship. Pseudonymisation lowers the risk and the obligations; it does not remove them, and the record of processing says so.

What is the lookup?

The table from identifier to name that the source system already holds. It never leaves. The report comes back with identifiers, and the reader with access to the lookup sees the names. No lookup, no names, anywhere outside the building.