Why do the same customers keep getting created twice at the same address?
Almost always address formatting. "1420 N Main St Apt 3", "1420 North Main Street #3" and "1420 Main St 3" are one place written three ways, and a matcher comparing raw text sees three places. Normalize before you compare: standardize street types and directionals, parse the unit into its own field, and match on the normalized components while treating the unit as a distinguishing value rather than part of the street line.
Three distinct failure shapes
They look the same in a duplicate report but they have different causes and different fixes.
- Formatting variance. Street, St, Street. North, N, N.. Suite, Ste, #. Pure noise, and completely solvable by normalization.
- Unit buried in the street line. The apartment number sits at the end of address line one on one record and in address line two on another. String comparison fails; component comparison succeeds.
- Missing unit. The dangerous one. Two genuinely different customers in the same building, one of whom was entered without a unit number. A matcher that ignores units will merge them, and it will look confident doing it.
Normalize, then match
Normalization means converting an address into a canonical form: uppercase, abbreviations expanded or contracted consistently, punctuation removed, directionals standardized, and the unit designator and value pulled into their own fields. You store the normalized form alongside the original, never instead of it, because the original is what the customer wrote and what the postal label needs.
Once normalized, matching is comparing structured values rather than guessing at strings, and match scores become interpretable. This is the same class of preprocessing that has to happen before any analysis across systems is trustworthy, because two systems will never format an address identically on their own.
Treat a missing unit as unknown, not as blank
The most common serious error is treating an empty unit field as if it means "no unit." In a multi-unit building it means "we do not know which one." A record with a known unit and a record with an unknown unit at the same street address should never auto-merge; they go to review.
If you have the data, flagging addresses that are known to be multi-unit lets the rule behave differently there than on single-family streets, which is where most of your false merges will otherwise come from.
Fix the entry point, not just the database
Address drift is manufactured continuously. Web forms with free-text address fields, technicians typing on a phone in a driveway, imported lists from a marketing vendor, and call center staff transcribing an address over a bad connection all produce different variants. Address autocomplete on the entry forms removes more duplicates than any cleanup job, because it stops the problem at the source. Connecting those entry points properly is ordinary integration work with a very high return.
Topics: address matching · normalization · data hygiene · duplicates
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.