Single Customer View

More than the storage. Duplicates cause four distinct problems, and the first is a compliance issue, not an efficiency one:

• Hidden risk — screening one record and missing its duplicate means a flagged customer can still pass through the other
• Service quality — staff working from the wrong record give wrong answers to the right customer
• Marketing waste — duplicates receive the same campaign twice, skew response rates and inflate audience counts
• Reporting accuracy — customer counts, exposure figures and regulatory reports are only as accurate as the deduplication underneath them

Every duplicate is a customer you only half know, and the half you are not looking at is the one carrying the exposure.

Matching runs on multiple keys and, crucially, on external reference data, not on the contents of your own file alone.

That external element is what makes the difference. Address history and name variants can prove that two records describe one person (that the Katherine at the old address and the Kate at the new one are the same customer) in a way that comparing two internal records never can, because neither record contains the information that links them.

Merges only happen above a confidence threshold. Borderline pairs are routed for review instead of resolved automatically, on the principle that an unmerged duplicate is a nuisance while an incorrect merge is a genuine problem.

Yes. Every merge is logged and can be reversed.

This matters more than it might appear. Identity resolution is probabilistic, and any threshold set tightly enough to be useful will occasionally be wrong. A system that merges irreversibly forces you to choose between a conservative threshold that leaves most duplicates in place and an aggressive one you cannot recover from.

Because merges are reversible and the losing values are retained in history, not discarded, you can run resolution at a genuinely useful threshold and correct the occasional error.

Survivorship rules that you define: most recent, most verified, or source-priority applied per field.

Per field is the important part. The rule that should govern a postal address is rarely the rule that should govern a date of birth: for an address you almost always want the most recent value, while for a date of birth you want the most verified one, since a recent value is just as likely to be a recent typo.

Losing values are kept in history, not deleted, so a superseded address remains available for tracing or for auditing how the master profile was assembled.

New records resolve against the master view as they arrive, through the API or scheduled runs, so duplicates are caught at the point of creation.

That is a different model from periodic deduplication, and a considerably cheaper one. Batch cleansing removes duplicates that have already spread into downstream systems, reports and campaigns; resolving at capture stops them forming in the first place.

Most organisations run an initial full-file resolution to clear the accumulated backlog, then keep the view current at the point of entry from then on.

You can, up to a point, and that point arrives sooner than most teams expect.

Internal deduplication catches records that already look alike, such as the same name at the same address or the same email twice. What it cannot catch is the same person recorded differently: married name against maiden name, a move between states, an abbreviated first name, a corrected date of birth.

Those cases need external evidence, because the link between the two records is information that exists outside your systems entirely. Address history, name variants and linked contact points are exactly that evidence, drawn from a reference universe of more than 2 billion records.

It runs alongside what you already have. Nothing needs to move platforms.

The master profile returns to your systems in your own layout, keyed to your identifiers, so the output loads back into the CRM or warehouse it came from without a migration project or a new system of record.

That constraint is deliberate. Identity resolution is worth doing on its own merits, and making it contingent on replacing a CRM is how it stops being worth doing.