FIELD NOTE · Database Marketing
Review duplicate candidates without merging the wrong customers
Similarity is a reason to investigate, not an instruction to combine records.
Start with the business entity
Decide what one row represents: a person, a household, a business location, or a parent organization. Two locations can legitimately share a company name or email. One person can have several roles. If the entity definition is unclear, even a technically perfect matching algorithm can produce the wrong business result.
Make candidate rules explainable
Use a sequence of rules rather than one mysterious score. Examples include exact normalized email, exact business identifier, or name plus postal code. A rule should identify why two records were flagged. Normalization may remove harmless differences in spacing or case, but it should preserve original values for review. Never overwrite the source just to simplify matching.
Keep evidence and decisions separate
For each candidate pair, show identifiers, compared values, the rule, and a reviewer decision. Options can include same entity, distinct entity, or insufficient information. A shared address alone may reflect a building, franchise, or household. A blank field should not count as positive evidence that two records match.
Prepare for a reversible change
Before any merge, establish a backup, confirm relationships that could be affected, and test a small reviewed sample in an appropriate environment. Some system merges are difficult to reverse; an export is not always a complete rollback. This guide does not authorize live changes. Useful output from an initial review can simply be a candidate report with decisions awaiting approval.
Prepared with AI assistance. Examples are constructed for explanation, not reported customer results. Corrections are welcome through the contact page.
← All guides