Sign in

Blog · How-to guides

Pseudonymization vs anonymization for sales analytics: which one you need, and why

The difference between pseudonymized and anonymized data as it applies to a sales export, why coverage and share-of-wallet analysis needs the first and cannot use the second, what pseudonymization 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 pseudonymized file back into a named one.

The short answerAnonymized data cannot be linked back to a person or a company by anyone; pseudonymized 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 anonymized file has no account to report back to. Pseudonymize 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 pseudonymization and cannot use anonymization, what pseudonymizing an export looks like, and the mistakes that undo it.

The two definitions

Pseudonymized Anonymized
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 pseudonymization

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. Pseudonymized, the company reads 4471 and looks it up. Anonymized, row 1 is nobody, and the list is a statistic.

Pseudonymizing 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 pseudonymized 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

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

Pseudonymized 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 pseudonymization 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 anonymize?

Because an anonymized 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. Anonymization removes the output along with the risk.

Is pseudonymized 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. Pseudonymization 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.