Consistent pseudonyms: keeping one person one placeholder across a dataset

Why does consistency matter in conversation data?#

Consistency matters in conversation data because the value of a support thread or project discussion lies in who responded to whom, who escalated and who resolved the problem. If every mention of a person gets a fresh random tag, a thread with a customer, two agents and an engineer turns into a crowd of strangers, and a model cannot learn the handoffs.

Consistency also keeps records joinable. When the same customer placeholder appears in a Zendesk ticket, the linked Jira issue and the Slack channel where engineers discussed the fix, a buyer can follow the path from complaint to code change. That linkage often separates a useful operational dataset from a pile of disconnected messages.

Four ways to replace a name, compared#

The replacement style decides whether the conversation survives de-identification. The comparison below uses one sentence from a support thread to show the trade-offs.

The five-step method for consistent placeholders#

The five-step method for consistent placeholders works the same for tickets, email, chat and project tools. What changes between systems is where identifiers hide, not the logic.

Treat the steps as one run across every source in scope. Pseudonymizing Zendesk this month and Slack next quarter with a different setup is an easy way to lose consistency.

• 1Inventory: list every identifier type that refers to a person across sources, including names, email addresses, phone numbers, usernames, chat handles, account IDs and signature blocks.
• 2Resolve: group the variants that belong to one person into a single entity with a stable internal ID.
• 3Generate: derive each placeholder from that internal ID with a keyed hash (an HMAC) or a lookup table. The secret key, sometimes called a global salt or pepper, stays the same for the whole run and is stored apart from the data; a random salt per record would break consistency.
• 4Apply: replace every variant in one pass across all sources, including subject lines, headers, metadata fields, quoted replies and free text.
• 5Verify and retire: check that threads and joins survive and that no two people share a placeholder, then destroy the key and mapping or place them in escrow under the supplier's control.

Entity resolution: the step pipelines often skip#

Entity resolution decides whether Robert Kim, Bob, rkim at the company domain, the handle bobk and R. Kim are one person. A pipeline that hashes each string separately gives each variant its own placeholder, which breaks the thread as surely as random tags.

Start from structured sources: the user directory, the help desk agent list and the CRM contact table, which already tie names to emails and handles. Then handle free text: first-name-only mentions, nicknames, misspellings and pronouns that refer back to a named person, which is the coreference problem. Where two people share a first name, such as two agents named Maria, use the surrounding record, such as the assignee or message author, to choose, and fall back to a generic tag when the text cannot decide.

Some cases need a rule written in advance: a person who is both an employee and a customer, someone who changed surnames, and shared mailboxes that several people answer from. Decide each rule once and apply it everywhere.

Keyed hashes, lookup tables and a key per recipient#

A keyed hash or a lookup table is what keeps placeholders stable without exposing the original. An unkeyed hash of an email address is not enough, because anyone can hash a list of likely addresses and compare. The same logic applies to the key itself: whoever holds it can recompute placeholders for a list of real people, so it is a re-identification key and needs the same protection as a mapping table.

Cloud tooling supports the same idea. Google's Sensitive Data Protection API includes deterministic encryption among its de-identification transforms, and its API definition recommends it over format-preserving encryption wherever the original character set need not be preserved, because format-preserving encryption carries significant latency costs.

Use a different key for each recipient. The same customer then becomes Customer_0412 in one licensee's copy and Customer_7730 in another, so two licensees cannot join their copies. The per-recipient key also gives each copy a fingerprint, which is the basis of the recipient markers covered in the guide to canary records.

Illustrative: a support thread that stays readable#

Illustrative: a fictional vertical software company prepared support tickets from Zendesk, linked issues from Jira and the Slack threads where engineers discussed fixes. Its first pass hashed each name string, so one customer administrator appeared under four placeholders: full name, first name, email address and Slack handle.

The CTO's team rebuilt the run around entity resolution from the agent list, the CRM contact table and the Slack user directory. They generated role-typed placeholders with a keyed hash and replaced variants in subject lines, signatures and quoted replies as well as message bodies. A reviewer then read complete threads end to end. Each person had one placeholder across all three systems, the escalation path was clear, and the key went into escrow with the security lead.

What consistent placeholders do not fix#

Consistent placeholders do not make a dataset anonymous. GDPR Recital 26 says pseudonymised data that could be attributed to a person with additional information should be considered information on an identifiable person. California's definition of deidentified data asks for more than technique: the business must also publicly commit not to reidentify the data and contractually bind recipients to the same terms. Whether a pseudonymized dataset may qualify as deidentified under a given law is a question for counsel.

Free text can still identify someone through a job title, a location, an unusual event or a signature, and a consistent tag gathers all of one person's activity in one place. Pair placeholders with the rest of the de-identification work: generalize quasi-identifiers, strip signatures and attachments with personal details, and review samples by hand.

Where long-term linkage is not needed, scope placeholders to a project or period so they cannot build a multi-year profile. Employee performance data is the clearest case: a stable tag on a warehouse picker turns months of scan events into a profile of one worker, so rotate it or drop the worker key altogether.

Who holds the key in a SourceX delivery#

The supplier holds the key and the mapping in a SourceX delivery; neither travels with the data. Placeholder rules, entity resolution decisions and the per-recipient key choice are settled in the Preparation step of the SourceX five-step transaction, and the privacy record in the SourceX Evidence Packet states whether the mapping was destroyed or escrowed. The supplier approves that record before Delivery.

Declaring the method also helps the buyer's own records. The Data & Trust Alliance's Data Provenance Standards include a privacy-enhancing tools code list that names pseudonymization, tokenization and masking, so a dataset card can state which technique was applied and to which fields, without revealing the key.