Redaction tags, fake names or hashes: which replacement keeps data useful?

What are the options for replacing personal details?#

The options for replacing personal details range from deleting them outright to swapping in realistic substitutes. Each keeps a different amount of the record's meaning, and each fails in a different way.

Most preparation projects mix several methods. A support ticket might use typed tags for people, consistent tokens for order numbers and generalization for street addresses, all in the same paragraph.

• 1Generic redaction: every detail becomes the same marker, such as [REDACTED].
• 2Typed tags: the marker names the kind of detail, such as [NAME], [EMAIL] or [PHONE].
• 3Consistent typed tags: the same person or item keeps the same numbered tag, such as [CUSTOMER_1], within a defined scope.
• 4Partial masking: part of the value stays visible, such as the last few digits of an account number.
• 5Synthetic replacement: a realistic fake value stands in for the real one.
• 6Hashing or encryption: the value becomes a code computed from it, with or without a secret key.
• 7Generalization: a precise value becomes a broader one, such as a street address becoming a city.

Tags, masks, fake names and hashes compared#

Tags, masks, fake names and hashes trade readability against leak risk in different ways. The table compares them on what matters for a dataset someone will license and train on.

Why consistent typed tags are usually the default#

Consistent typed tags are usually the default because operational records are conversations between roles. A ticket where [CUSTOMER_1] reports a fault, [AGENT_2] escalates and [ENGINEER_1] ships a fix still teaches the full workflow, even though nobody is named.

The scope of consistency is a real decision. Tags that stay consistent within one ticket or one case keep the story intact with little linkage risk. Tags that stay consistent across the whole dataset let a buyer follow one customer through years of records, which adds value and also lets clues accumulate into an identity. Most packages scope tags to the case or the account, and counsel signs off on anything broader.

Typed tags also make QA faster. Reviewers can skim for any capitalized name that is not inside brackets, which is the fastest way to spot a miss.

When fake names help and when they backfire#

Fake names help when the buyer needs natural-sounding text, for example to train a model that writes or reads customer messages. Brackets and underscores are not how people write, and some language tasks work better on fluent surface text.

Fake names backfire in review. Once every name in a ticket looks real, a reviewer cannot tell a missed real name from a substitute, so the leak becomes invisible. Substitutes can also collide with real people, break pronoun agreement or replace a name inconsistently across a thread.

There is a counterargument. A missed real name surrounded by substitutes is also harder for an outsider to pick out, an idea some privacy engineers call hiding in plain sight. That cover only helps once QA has already driven misses down, so it complements review rather than replacing it.

If synthetic replacement is used, draw names from a fixed, documented list, keep a findings log from the detection step, run QA on the tagged version before substitution, and state plainly in the dataset documentation that all names are synthetic.

What hashes and encrypted tokens actually protect#

Hashes and encrypted tokens protect values only as well as the key and the input space allow, and they read worst of all. A plain hash of an email address always produces the same output, so anyone with a list of likely emails can hash the list and match it; phone numbers and employee IDs fall faster because the set of possible values is small. Meanwhile a buyer reading a string such as 2cd5f1 cannot tell a driver from a carrier.

Keyed hashes and deterministic encryption resist that attack as long as the key stays secret, and Google's Sensitive Data Protection API, for one, supports deterministic and format-preserving encryption for this purpose. But while a key exists, the data is pseudonymized, not de-identified.

For a delivered package, hashes rarely beat a random consistent token. If a buyer needs to join two tables within a delivery, assign random tokens during preparation and delete the mapping afterward.

Illustrative: one freight ticket, four ways#

Illustrative: a fictional freight brokerage is preparing carrier support tickets from its TMS help desk. One ticket, written by a carrier dispatcher, shows how each method changes the same sentence. All names and numbers below are invented.

What the brokerage chose, field by field#

The brokerage chose consistent typed tags scoped to each shipment, because the value of these tickets lies in how a missed appointment moved from dispatcher to broker to warehouse and back. The carrier name became a tag too, since carrier relationships are commercially confidential even though a business name is not usually personal data.

Dock cities stayed, because lanes and facilities explain delays and a city alone does not identify a person. Phone numbers became a plain [PHONE] tag with no numbering, since no workflow depends on telling two numbers apart.

• 1People: consistent typed tags, scoped to the shipment or case.
• 2Emails and phone numbers: typed tags without numbering.
• 3Shipment, order and account numbers: consistent tokens with no retained mapping.
• 4Street addresses: generalized to city and state.
• 5Customer and carrier company names: tagged where contracts treat them as confidential.

How SourceX approaches replacement choices#

SourceX settles the replacement method field by field during the Preparation step of the SourceX five-step transaction, and the supplier reviews tagged samples before the Approval step. The placeholder vocabulary, the tag scope and any synthetic substitution are written into the dataset documentation and the privacy record of the SourceX Evidence Packet.