This is general information, not legal advice. Replacing values with stand-ins reduces what a file reveals; it does not by itself make a dataset free of personal data. See our terms of service.

Replacing real names with consistent stand-ins so your analysis still works

How to replace names, customer numbers and other identifiers with stand-ins that stay the same wherever the real value appears, and the mistakes that break the count or reveal more than you meant.

Published October 19, 2026 · Updated October 28, 2026

If you delete a name column, you lose the ability to ask "how many orders did each customer place?" If you replace every name with the same word, such as [NAME], you lose it too. A consistent stand-in keeps the structure: the same real customer always becomes the same stand-in, so counts, groups, and joins still work. The real name is gone from the file.

Key terms

Stand-in: a value that replaces a real one. Also called a pseudonym when it is used so that the real value can be linked back by someone who holds the link.
Consistent (deterministic) replacement: the same real value always receives the same stand-in, within a file and, if you choose, across files.
Mapping: the table that says which stand-in replaced which real value. Whoever holds it can reverse the replacement.
Normalization: making variants of the same value look identical before replacing them, for example Ann Smith, ann smith, and SMITH, Ann.
Referential integrity: the property that a value used in two tables, such as a customer number in both an orders file and a returns file, still matches after replacement.

Why does consistency matter?

Because most useful questions are about the same person appearing more than once. Orders per customer, time between purchases, which staff members handled which cases, which suppliers are late. Each question counts or groups by an identifier. If the identifier changes from row to row, the question has no answer.

Example: Counting orders per customer

Here are six rows of a small, invented orders file, before and after.

Order	Customer (before)	Customer (after)
1001	Brenna Talvik	PERSON_001
1002	Oren Mallis	PERSON_002
1003	Brenna Talvik	PERSON_001
1004	Corvale Ltd	PERSON_003
1005	Oren Mallis	PERSON_002
1006	Brenna Talvik	PERSON_001

Orders per customer is 3, 2, and 1 in both versions. An assistant can tell you that PERSON_001 is your most frequent customer without ever seeing her name.

How do you make replacements consistent?

There are three common ways.

Method	How it works	Strengths	Weaknesses
Lookup table	Give each new value the next number the first time you meet it, and store the pair	Simple; the stand-ins look tidy; easy to restore	The table is the secret. Numbers in order of appearance reveal the order of the file
Keyed hash	Calculate a code from the value and a secret key	No table to keep; works across files that share the key	Cannot be reversed; the key must stay secret
Encryption	Encrypt each value with a key	Reversible by the key holder; no table	The result is not a tidy name; its length may reveal something

A fourth option is synthetic replacement: replace each value with an invented value of the same kind, such as another plausible name. The result reads naturally for an assistant, but a plausible name may belong to a real person, so a reader may take it for a real one.

What goes wrong?

Variants of the same value

People write the same name in many ways: Ann Smith, Ann Smith (two spaces), ANN SMITH, Smith, Ann, A. Smith. A lookup that compares exact text gives each variant a different stand-in, and your counts split. The fix is normalization: decide what counts as the same value (ignore case, trim spaces, remove accents if appropriate) before replacing.

Replacing inside other values

A short name replaced by plain search-and-replace also changes longer words. Ann inside Hannah and Annual is the classic case. Match whole values or whole words, not pieces of words.

Stand-ins that reveal something

Order of appearance. If stand-ins are numbered in the order values first appear, PERSON_001 is the first person in the file. If the file is sorted by date, that tells the reader something. Random or keyed stand-ins avoid this.
Frequency. The most common stand-in is the most common customer. If your largest customer is famous, a reader can guess who it is. Replacing the value does not hide how often it occurs.
Format. A stand-in that keeps the length or the first letter of the original gives away part of it.

The same person in different files

If you protect two files separately with a lookup table, PERSON_001 in the first file is not the same person as PERSON_001 in the second. Either use a keyed hash or encryption with the same key for both files, or share one mapping across both. Decide this before you start, not after the first file is sent.

Names inside text

A stand-in for a name column does not touch the same name when it appears inside a comment. Replace the whole set of values in the free-text columns too, or remove those columns.

Why is a plain hash not enough?

Keyed hashes against plain hashes

A plain hash (for example SHA-256) of a value is the same for everyone who calculates it. Anyone with a list of likely values can hash the list and match the results. For names, emails, and phone numbers the list is easy to produce, so the hash can be reversed by guessing.

A keyed hash mixes a secret key into the calculation. Without the key, the outsider cannot repeat it. Equal values still give equal codes, so counts and joins work. The method fails if the key is stored in the same place as the file, if it is short or guessable, or if it is reused for purposes where its disclosure would matter. Choose a long random key, keep it away from the data you share, and replace it when you no longer need old files to match new ones.

Where should the mapping live?

If you can restore, someone holds the mapping or the key. Treat it as a secret of the same sensitivity as the original file, because it recovers the original. Keep it away from the folder, mailbox, or service where the protected file goes. Back it up, because without it the restoration is impossible. See putting the original values back after an AI answers.

What does DataAttendant do?

DataAttendant offers a stable pseudonym (a numbered name for each distinct value, the same wherever the value appears, restorable by you), a keyed hash (the same code for equal values, not reversible), synthetic replacement, and reversible encryption. You can choose how far the sameness extends: within one export, across exports to the same recipient, or across all your exports. Before it compares two values it removes spaces at the start and end and puts accented letters in one standard form. Capital and lower-case letters count as different, so SMITH and Smith get different stand-ins. It does not treat Smith, Ann and Ann Smith, or a value with a double space inside, as the same value, so those variants get different stand-ins. It runs in your browser, and the mapping stays with you. It will not catch every spelling variant or every name inside free text, so check a sample of what it did before you share the file.

Try DataAttendant

Sources

NIST, Format-Preserving Encryption (SP 800-38G) and related guidance on keyed cryptographic functions, for background on keys and deterministic encryption.
Narayanan, A. and Shmatikov, V. (2008). Robust De-anonymization of Large Sparse Datasets. On why consistent identifiers and linkable behavior can still identify people.
Regulation (EU) 2016/679 (GDPR), Article 4(5) (pseudonymization: the additional information is kept separately and protected).