MDM Best Practices: Address Match Keys

Ask five people at your company how many customer records “Acme Corp” has across your systems, and you’ll get five different answers — because the honest answer is nobody knows. One’s in Salesforce as “Acme Corp, 500 5th Ave.” Another’s in the billing system as “ACME CORPORATION, 500 Fifth Avenue Ste 2100.” A third came in through a support ticket as “Acme, 500 5th Ave NYC.”

Same company. Three records. Zero systems that agree.

This is the problem master data management (MDM) exists to solve — and it’s also where most MDM projects quietly stall.

What Master Data Management Actually Means

Master data management is the discipline of creating one authoritative, trusted version of a core business entity — a customer, vendor, or location — that every system references instead of maintaining its own copy. The end goal usually has a name: a golden record, or a single customer view. One row that’s the truth, everywhere.

MDM platforms are good at the orchestration: pulling data from CRM, ERP, billing, and support systems, running match rules, and merging survivors into a golden record. What they’re not good at is deciding, on their own, that “500 5th Ave” and “500 Fifth Avenue Ste 2100” are the same address. That’s a data quality problem sitting upstream of MDM, and if you don’t solve it first, your match rules either miss obvious duplicates or — worse — fuzzy-match their way into merging two different companies.

Standardization Is the Prerequisite, Not a Nice-to-Have

Every data matching engine, whether it’s built into an MDM suite or hand-rolled in Python, ultimately needs to answer one question: are these two records the same real-world thing? Addresses are one of the strongest signals available for answering that — but only if they’re in a comparable form first.

“500 5th Ave” and “500 Fifth Avenue” are the same street. A naive matching rule using exact string comparison sees two different strings. Standardization is what closes that gap: parsing free-form address text into structured components (house number, street, unit, city, state, postcode, country) and resolving abbreviations into canonical expansions — “5th” → “Fifth”, “Ave” → “Avenue” — so that two representations of the same real-world address collapse to identical strings.

Once addresses are standardized, matching stops being probabilistic guesswork and becomes deterministic: hash the canonical string, or join on it directly. No fuzzy-matching thresholds to tune, no false-positive merges to explain to a customer whose account got fused with a stranger’s.

curl -X POST "https://api.goodvat.com/v1/address/normalize" \
  -H "Authorization: Bearer $GOODVAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "500 5th Ave Ste 2100, New York NY 10110" }'

{
  "houseNumber": "500",
  "road": "5th avenue",
  "unit": "ste 2100",
  "city": "new york",
  "state": "ny",
  "postcode": "10110",
  "country": "USA",
  "expansions": [
    "500 fifth avenue suite 2100 new york ny 10110 usa"
  ]
}

Run “500 Fifth Avenue, Suite 2100, NYC” through the same call and you’d get an identical expansions string — which is exactly the match key your MDM or data matching layer needs.

Where This Fits in Your Stack

GoodVat’s Address Standardization API sits upstream of matching, not in place of it. The workflow most teams land on looks like this:

1. Standardize every address on the way into any system — CRM, ERP, billing, support — so every record stores the same canonical form.
2. Match records on that canonical key inside your MDM platform, dedup tool, or a simple SQL join — deterministically, not fuzzily.
3. Merge matched records into a golden record, with survivorship rules deciding which other fields win.

One honest caveat: standardization tells you two strings represent the same postal address — it doesn’t verify that the address exists or is deliverable. If your MDM process also needs deliverability verification (confirming a location is real and mail can reach it), that’s a separate, complementary step, typically run through a postal carrier’s own validation service after standardization, not instead of it.

Get the standardization layer right, and the rest of MDM — matching, merging, governance — finally has something solid to stand on.

Read the docs and see the full field reference for building your own match keys.