A music-streaming service in the mould of Spotify sends analytics events to a vendor with the user identified by SHA-256(lowercased email), described in the privacy notice as anonymised. The vendor is also an advertiser's data partner. Review the design. What would you remove, change and leave alone?

What is actually required

The analytics vendor needs to count distinct users and follow one user's events across sessions. It does not need to know who the user is, and it does not need an identifier that can be matched against anything outside this product.

What I would remove

• The word "anonymised." An unsalted hash of a low-entropy, widely known identifier is pseudonymisation at best. The set of plausible email addresses is enumerable: an adversary with a list of 100 million emails can hash all of them in seconds on a single GPU (SHA-256 runs at billions of hashes per second) and look up each event's identifier in a table. Anyone who holds an email list, including an advertiser partner, can re-identify every user.
• The shared, stable identifier. The same hash across vendors lets any two of them join their datasets on it.

The one change that matters

Replace the hash with an identifier the vendor cannot invert or match externally: a random per-user ID generated by the service, or a keyed hash (HMAC-SHA-256 with a secret key held only by the service, rotated on a schedule). The key never leaves, so the vendor cannot recompute identifiers from emails. A random mapping table is stronger still because it contains no derivable relationship, at the cost of storing the table.

Pair it with purpose separation: a different pseudonym per vendor or purpose, so datasets cannot be joined across them.

What I would leave alone

Sending events to an analytics vendor at all is reasonable, as is a stable pseudonym per user inside the vendor (needed for retention analysis). Hashing as a mechanism is fine when the input has high entropy and a secret key; the flaw is in the input and the missing key.

What it costs

A mapping or key-management component to run, rotation that resets longitudinal analytics unless the mapping is versioned, and a support path to find a user's pseudonym for deletion requests. Under GDPR, pseudonymised data is still personal data, so deletion, access and processor agreements still apply; the change reduces risk and does not remove obligations.

How I would argue it in the review

Frame it as a test: "if the vendor combined this with a public breach list, could it name a user?" For the current design the answer is yes. For an HMAC with a service-held key, no.

When the simple design is acceptable

For an internal-only dataset in a restricted warehouse with no external parties, a hash of the email used as a join key is a convenience, not a disclosure, though a random surrogate id is still cleaner.

Common weak answers

• "Add a salt." A single global salt held by anyone with the data does not stop dictionary attacks; a secret key held separately does.
• "SHA-512 instead." Speed is the problem, not output length.