Sign in

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

The short answerCoverage, share of wallet, gaps, dormancy and concentration are computed on identifiers, dates and amounts. They do not need customer names, contact names, email addresses or phone numbers, and a tool that asks for them is asking for personal data it does not use. Pseudonymise at export: replace names with the identifiers the source system already has, keep the lookup at home, and the data that leaves is a table of codes and numbers. The DPO's six questions are what leaves, why, where it is stored, who can see it, how long, and how it comes back.

A sales leader wants coverage analytics. The DPO wants to know why a vendor needs the customer list. The honest answer is that it does not, and a tool designed for the analysis does not ask. This guide sets out what the measures need, what they never need, what pseudonymising at export means, and the six questions a DPO should ask.

What the measures need

Measure Needs Does not need
Coverage Account ID, rep ID, activity dates and types Names, contacts, notes
Share of wallet Account ID, revenue, size band, segment Names, addresses
Gap at norm The same The same
Dormancy Account ID, order dates Names
Concentration Account ID, revenue Names
Pipeline Opportunity ID, stage, value, dates Deal names, contact names

Every measure on this site is computed from the left column. Nothing on the right improves any of them.

Pseudonymise at export

At home In the export
Acme Ltd 4471
Jane Smith, jane@acme.com C-2207, or nothing
Rep: Sam Jones R-04
Opportunity: Acme renewal 2026 O-88213

The identifiers already exist in the source system. The export uses them. The lookup from identifier to name never leaves. The report comes back with identifiers, and the reader who needs the name has the lookup.

The lawful basis question

Processing on identifiers, amounts and dates for a company's own commercial analysis is ordinarily legitimate interest for customer data and the employment relationship for rep data, and both are easier to document when the data leaving the building is a table of codes. The record of processing describes what left, why, and where, and the answers are short.

What stays in the building

  • Names of customers, contacts and employees.
  • Email addresses, phone numbers, postal addresses.
  • Free-text notes from the CRM.
  • The lookup table from identifier to name.

None of it is needed for a coverage number, and none of it should be in the export.

Six questions for the DPO to ask

# Question The answer to expect
1 What leaves the building? Identifiers, amounts, dates, categories; no names or contact details
2 Why each field? A measure that needs it, per field
3 Where is it stored, and in which jurisdiction? Named region; stated
4 Who can see it? The account's users; the vendor's named roles for support only, logged
5 How long is it kept? A stated retention, deletable on request, including trial uploads
6 How does it come back, and can it all be deleted? Exports of every computed table; deletion confirmed

A vendor who answers all six in a paragraph has thought about it. One who answers with a certificate has answered a different question.

Where it goes wrong

Names exported because they were in the file. The default CRM export has them. Remove the columns.

Free-text notes included. The highest-risk field in any CRM, and useless for the arithmetic.

Lookup sent with the data. Then the export is not pseudonymised.

Trial uploads exempted. The least governed export is the first one.

Identifiers in, identifiers out

Covirage computes on identifiers, runs its free validation on a file without names, and returns every table with the same identifiers the export used. The pseudonymisation guide covers the export step by step, and the help centre covers storage, access and deletion.

Questions people ask

Is a customer ID personal data?

For a company customer, no. For a sole trader or a named individual contact, an identifier that can be linked back to a person through the lookup is pseudonymised personal data, which is still in scope but at much lower risk, and the lookup staying in the building is what makes it pseudonymised rather than merely coded.

What about rep identifiers?

Reps are employees, and a rep ID linked to attainment and activity is their personal data. It is processed under the employment relationship, it stays pseudonymised in the tool, and the report about a rep is seen by the rep and their manager. The same principle: identifier out, name at home.

Does the free upload change any of this?

A trial upload should follow the same rule harder, because no contract is in place: identifiers only, no names, and a validation report that comes back without the file being retained. If a trial asks for names, the tool has not been designed with this in mind.