Skip to main content

Duplicate Customer Records: A Free Dataset for Entity-Resolution Testing

Duplicate customer records is a free, downloadable dataset built for entity-resolution testing: 300 full customer records (name, address, email, phone) across 60 groups, each row tagged with a Master ID and Duplicate Type — exact copy, address typo, phone-format variant, email-domain variant, name typo, or a same-name/different-person negative control.

300 rows across 60 groups · free sample, no signup

License: As of 2026-08-02, no public license has been published for this sample dataset. License metadata is omitted until a license is published.

Looking for a live, generatable dataset instead?

This page is a documentation-first sample: a fixed CSV/JSON file with a stated schema and a worked answer key. Generate-Data's product catalog also has a live, generatable Customer (MDM) dataset with source-system attribution (CRM/ERP/Billing/Legacy) and configurable exact/fuzzy duplicate generation — preview it live and export any row count in CSV, JSON, XML, or Parquet. The two are complementary: use this page's fixed file when you need a known, documented answer key; use the live catalog dataset when you need a larger or differently-shaped generated set. Related MDM catalog datasets: Patient, Provider, Organization, Product, and Vendor.

Dataset overview

300 rows across 60 customer groups, averaging 5 rows/group (1 master + 4 variants). Format: CSV (primary), also offered as JSON.

Entity resolution, fuzzy matching, and MDM — how this fits

Entity resolution is the general technique of deciding which records refer to the same real-world entity; this dataset is one applied instance of it, scoped to full customer records. It's distinct from fuzzy matching test data (name-only string similarity) and from MDM test data (the business-process/golden-record framing) — related, not interchangeable.

Sample dataset

Duplicate customer records sample
record_idmaster_idduplicate_typefirst_namelast_nameaddress_line1citystatezip_codeemailphone
1101MASTERPriyaNatarajan48 Elm StreetAustinTX73301[email protected](512) 555-0148
2101EXACTPriyaNatarajan48 Elm StreetAustinTX73301[email protected](512) 555-0148
3101ADDRESS_TYPOPriyaNatarajan84 Elm StreetAustinTX73301[email protected](512) 555-0148
4101PHONE_FORMAT_VARIANTPriyaNatarajan48 Elm StreetAustinTX73301[email protected]512-555-0148
5101EMAIL_DOMAIN_VARIANTPriyaNatarajan48 Elm StreetAustinTX73301[email protected](512) 555-0148
6101NAME_TYPOPriyaNataranjan48 Elm StreetAustinTX73301[email protected](512) 555-0148
7107NO_MATCHPriyaNatarajan220 Cedar AveDenverCO80202[email protected](303) 555-0177

Data dictionary

Data dictionary
ColumnTypeDescription
record_idintegerUnique row identifier.
master_idintegerID of the canonical customer this row belongs to — the basis for a golden record.
duplicate_typeenum (string)MASTER, EXACT, ADDRESS_TYPO, PHONE_FORMAT_VARIANT, EMAIL_DOMAIN_VARIANT, NAME_TYPO, or NO_MATCH.
first_namestringFirst/given name.
last_namestringLast/family name.
address_line1stringStreet address.
citystringCity.
statestringTwo-letter US state code.
zip_codestring5-digit ZIP.
emailstringSynthetic email address (not a real mailbox).
phonestringSynthetic US phone number; formatting varies by row on purpose.

Example test cases

Example test cases
CaseDetail
Exact-dup pairrecord_id 2 vs record_id 1 (master_id 101). Identical across every field.
Address-typo variant"84 Elm Street" (record_id 3) vs "48 Elm Street" (record_id 1). Transposed digits.
Phone-format variant512-555-0148 (record_id 4) vs (512) 555-0148 (record_id 1). Same number, different formatting.
Email-domain/local-part variant[email protected] (record_id 5) vs [email protected]. Different local part, same person.
Name-typo variant"Nataranjan" (record_id 6) vs "Natarajan". One inserted character.
No-match / same-name collisionrecord_id 7 shares the exact name of group 101 but is a different synthetic person — the false-positive trap.

Expected-match answer key

Expected-match answer key
record_idduplicate_typeMatches master_idExpected verdictNote
2EXACT101MATCHDeterministic rule (all fields identical) is sufficient.
3ADDRESS_TYPO101MATCHNeeds fuzzy/probabilistic matching on address_line1; other fields agree exactly.
4PHONE_FORMAT_VARIANT101MATCHNormalize (strip non-digits) before comparing — deterministic once normalized.
5EMAIL_DOMAIN_VARIANT101MATCHLocal-part differs; name/address/phone agreement is the stronger signal.
6NAME_TYPO101MATCHSingle-character insertion; fuzzy matching on last_name, corroborated by exact address/phone.
7NO_MATCH107 (self)NO MATCH to 101Same name, different person — every other field disagrees. Tests the name-only false-positive failure mode.

How it was generated

Generate-Data's schema builder, duplicate-generation mode, extended to a full customer-record schema (name, address, email, phone). This is synthetic data — no real people, no real PII — and no accuracy/validation claim is made about any specific matching tool.

Generate a larger or custom version

Need a bigger file, a different duplicate rate, or additional fields? Open the schema builder → build a customer schema (name, address, email, phone) → switch on duplicate generation mode → choose your Duplicate Type mix → export as CSV, JSON, XML, or Parquet (JSONL/HuggingFace also supported), or pull it programmatically via API access.

Generate a custom duplicate-records dataset →

Frequently asked questions

What dataset can I use to test entity resolution?

This one — 300 full customer records (name, address, email, phone) across 60 groups, each row tagged with a Master ID and Duplicate Type so the ground truth for every match/non-match pair is documented, not inferred.

How do I create duplicate customer records for testing?

Mark the fields that should carry duplicates exact_matching and/or fuzzy_matching in Generate-Data's schema builder — the generator produces a master record per identity plus variant rows tagged back to it with a Master ID, or download this pre-built sample directly.

What's a Master ID / Duplicate Type column?

Master ID links every duplicate of the same synthetic customer back to one canonical record. Duplicate Type labels how that specific row varies from the master (exact copy, address typo, phone-format variant, and so on) — together they make the ground truth explicit instead of something you have to infer.