The Package That Came Back
You cleaned up your address data. The carrier stopped rejecting your files. Shipping labels printed without complaint. For about nine days, everything looked better.
Then the returns started. One of them was an order for 742 Evergreen Terrace Apt 3B. The standardization step had turned it into 742 Evergreen Ter and quietly dropped the apartment. The driver stood in a lobby with 40 mailboxes and no way to pick one. That package went back to the warehouse, got reshipped, and the customer emailed support twice before it arrived.
This is the thing nobody tells you about address standardization. The same process that makes your data consistent can also make it wrong. Done carefully, it collapses a dozen spellings into one record and saves you real money. Done carelessly, it generates returns.
This guide covers both halves: how to get addresses consistent, and how to do it without breaking deliveries.
Why the Same Address Has a Dozen Valid Spellings
An address looks like a string of text. It's actually a structured record with six or so components, each of which has multiple correct forms. Nobody agrees on which form to use, and most forms are entered by hand.
Start with the street line. "123 Main Street", "123 Main St", "123 Main St.", and "123 MAIN ST" are the same place and four different values in your database. Street types are the biggest offender, but directionals are worse because they carry meaning. "123 N Main St" and "123 S Main St" are a mile apart. Strip the directional to tidy things up and you've invented a new address.
City names drift too. "NYC", "New York", and "New York City" are one city. So are "LA" and "Los Angeles". Then someone writes "Brooklyn", which is also correct, and now you have two city values for one ZIP. State fields hold "CA", "Calif", "California", and one brave "Cali". Country fields hold "US", "USA", "U.S.A.", and nothing at all, because domestic customers don't think to fill it in.
Postal codes vary by whether someone bothered with the ZIP+4, whether the Canadian code has a space in the middle, and whether a leading zero survived a trip through a spreadsheet. Capitalization and punctuation add the last layer. "McDonald Ave" breaks naive title casing. "O'Brien St" breaks it again.
None of these variations are errors. That's the part that makes address standardization harder than it looks. You aren't fixing mistakes. You're picking one correct form out of several and applying it everywhere.
- Street type: Street, St, St., ST
- Directional: North, N, N., or trailing ("Main Street North")
- City: NYC, New York, New York City, Brooklyn
- State: CA, Calif, California
- Postal: 94110, 94110-1234, 941101234
- Country: US, USA, U.S.A., blank
What USPS and CASS Conventions Actually Cover
In the US, there is an official answer to the formatting question. USPS Publication 28 defines the standard abbreviations, the preferred uppercase format, the order of lines, and where the secondary unit goes. CASS (Coding Accuracy Support System) certification means a tool has been tested against USPS data and can correct and complete addresses to that standard, including appending the ZIP+4.
Adopting USPS conventions as your internal standard is a good default if you ship mostly domestic. It gives you a tiebreaker. When someone asks whether to store "Street" or "ST", you have an answer instead of an argument, and your records match what the carrier expects to see.
The limits matter just as much. CASS validates to the delivery point, which usually means the building. Apartment-level confirmation is inconsistent. Most services can tell you 123 Main St is a real address with multiple units. Fewer can tell you that Apt 3B exists inside it. New construction often isn't in the database yet. Rural addresses that work perfectly for the local carrier can fail validation outright.
And all of it stops at the border. USPS conventions describe US addresses. Apply them to a German street name or a Japanese block number and you will produce something confident and undeliverable.
International Formats: Where US Assumptions Break
The American mental model is number, street, city, state, ZIP. It feels universal. It isn't. Plenty of countries put the street name before the number, put the postal code before the city, or skip street names entirely.
A few that will break rules written for US data:
- Japan: addresses run largest to smallest, from prefecture down to building. Street names are rare. "1-2-3" means district 1, block 2, building 3.
- UK: postcodes are alphanumeric ("SW1A 1AA") and encode real geographic detail. The spacing and pattern are strict, and automated sorting depends on them.
- Germany: house numbers can include letters or ranges ("23a", "23/25"), and compound street names look like typos to systems built for English.
- Brazil: the neighborhood (bairro) is effectively required. Drop it and delivery gets unreliable.
- Rural addresses anywhere: "the blue house past the church" can't be standardized and may be the only address that works.
Handling International Data Without Making It Worse
The practical approach is not a universal standardizer. It's country detection first, then country-specific rules, then restraint for everything else.
Detect the country before you touch anything. Use the explicit country field if it exists. If it doesn't, postal code pattern and state or province values are usually enough to infer it. Record what you inferred, because a guessed country is worth flagging.
For the three or four countries you ship to most, learn the format and write rules for each. For the long tail, do the minimum. Trim extra whitespace. Fix obvious encoding damage. Leave the field order alone. Don't abbreviate words you don't recognize.
A slightly inconsistent but complete international address beats a tidy one that lost its bairro. The goal is packages arriving, not uniform-looking rows.
Secondary Units: The Apartment Number That Gets Dropped
Secondary units cause an outsized share of both matching failures and delivery failures, which is a rare combination. They deserve their own rules.
One apartment can arrive in your system in at least seven shapes: "Apt 3B", "Apartment 3B", "#3B", "Unit 3B", ", 3B", plain "3B", or "Floor 3, Unit B". Some systems store it in a separate field. Others append it to the street line. A few split it across two fields with different labels. Business addresses add Suite, Ste, Fl, Bldg, Room, and mail stop codes.
Order of operations matters here. Split the address into fields first, then standardize each field. If you standardize the raw string before you know which part is the unit, the unit is the part that disappears. That is exactly how 742 Evergreen Terrace Apt 3B became 742 Evergreen Ter.
Four rules keep units intact:
- Preserve Address Line 2. If the unit arrived in its own field, leave it there. Carriers expect it there.
- Recognize designators broadly. Apt, Apartment, Unit, Ste, Suite, #, Fl, Floor, Bldg, Building, Room, Rm. Standardize the label if you want, but never drop it.
- Flag ambiguity instead of guessing. "123 Main St 3B" with no designator goes to a human. A two-minute check costs less than a reshipment.
- Never delete what you can't identify. If something trails the address and you don't recognize it, keep it. A driver can work out "Apt 3B Rear". Your rules can't.
Normalize, Verify, Geocode: Three Different Jobs
These three words get used interchangeably, and that confusion is why teams buy the wrong thing.
Standardization makes format consistent. "123 Main Street" and "123 Main St" become one value so they match each other inside your database. It runs on rules, costs nothing per record, and tells you nothing about whether the address exists.
Verification checks whether the address is real and deliverable. It compares your record against postal authority data (USPS in the States, Royal Mail's PAF in the UK, varying quality elsewhere) and can correct typos or append the ZIP+4. It requires an external lookup, usually with a per-record fee.
Geocoding turns the address into coordinates. That's what you need for territory maps, delivery zones, and regional analysis. It's a different bar than deliverability. An address can geocode to the right block and still fail to reach a specific apartment.
Sequence them by what you need. Standardize first, always, because deduplication depends on matching and matching depends on consistent format. Verify where failed delivery costs real money, which usually means new shipping addresses and high-value orders. Geocode only if you're actually mapping something. Verification is a filter, not a guarantee: addresses that fail definitely need attention, addresses that pass are probably fine.
What Bad Address Data Actually Costs
Address problems feel like a formatting annoyance until you price them out.
A failed delivery rarely costs one thing. Carriers charge an address correction fee on packages they have to fix. Undeliverable parcels come back, which is a return shipping charge. Then you pay to ship it again. Support answers two or three tickets about where the order is. Some of those customers ask for a refund instead of a reshipment, and a few file a chargeback for an item they never received, which costs you the dispute fee on top of the goods.
Call that somewhere between 20 and 60 dollars of real cost on a single order, depending on size and destination. Now apply it to the percentage of your addresses missing a unit number. On a 50,000-record list, even one percent is 500 orders waiting to go wrong.
The quieter cost is duplicates. When "123 Main St Apt 4B" and "123 Main Street, Unit 4B" don't match, you have two customer records for one person. Your customer count is inflated, your repeat purchase rate is understated, your email list pays for the same subscriber twice, and your regional sales analysis splits one household across two rows.
None of this shows up on a dashboard labeled "address problems". It shows up as shipping spend, support volume, and analytics you don't quite trust.
An Intake Ruleset You Can Apply This Week
Most teams treat address cleanup as a project. It works better as a standing rule set that runs on everything coming in, plus a periodic full pass over the back catalog.
Here is a ruleset that holds up in practice:
- Keep the raw original. Store what the customer typed in an untouched field. Every change should be reversible.
- Detect country first. Standardize nothing until you know which rules apply.
- Split into fields, then standardize fields. Never apply formatting rules to an unsplit string.
- Pick one domestic standard and write it down. USPS Publication 28 is a reasonable default. Consistency beats preference.
- Preserve directionals and units exactly. These carry meaning. Changing their label is fine, removing them is not.
- Set a confidence threshold. Below it, flag instead of changing.
- Flag these patterns every time: anything the standardizer modified but couldn't fully identify, unit information that moved between fields, international addresses you can't check against an authority, unusually short or long addresses, and identical addresses that differ only by unit number.
- Route flags to a review queue that shows original, proposed, and reason. Approving, reverting, and correcting should each take one click.
- Re-run the whole rule set in batch after any rule change. Entry-time checks catch the easy cases; the batch pass catches what slipped through.
Standardize Your Address Data in One Pass
Manual address cleanup doesn't scale past a few hundred records, and spreadsheet find-and-replace is how apartment numbers die. This is the problem CleanSmart was built for.
The flow is import, clean, review, export. DataBridge reads your records straight out of Shopify, Klaviyo, HubSpot, Salesforce, or Mailchimp, or you upload a CSV. AutoFormat handles the predictable work: street types, directionals, capitalization that respects names like McDonald, punctuation, state and country values. SmartFill closes gaps where the missing component can be inferred from the rest of the record. LogicGuard flags the ones that need a person, including units that look like they moved and international addresses outside your rule set. SmartMatch then finds the records that are the same customer at the same address even though the strings never matched.
You review the flagged changes before anything is final. When you're happy, you export a CSV or JSON file along with a change log showing exactly what was modified and why, and you import that back into your platform yourself. CleanSmart never writes into your connected systems, so nothing changes in Shopify or Salesforce without you deciding it should.
After the run finishes (a few minutes, not hours), your Clarity Score is recalculated across Completeness, Consistency, Uniqueness, and Validity. Completeness tells you how many addresses are still missing a unit. Uniqueness tells you how many customers you actually have.
Start small. Pull a few hundred addresses, run them through the self-serve product demo, and read the change log line by line. Check the apartments. Check the international ones. Once you trust what it does to a sample, run the whole dataset and get your addresses standardized in one pass.
Frequently Asked Questions
Should I standardize addresses before or after deduplication?
Before, every time. Deduplication works by matching similar records, and "123 Main St" won't match "123 Main Street" until the formatting is consistent. Clean the format first, then find the duplicates.
Do I need to pay for address verification, or is standardization enough?
For deduplication, reporting, and internal consistency, standardization alone usually does the job and costs nothing per record. Add paid verification where a failed delivery costs real money, which typically means new shipping addresses and high-value orders rather than your entire back catalog.
What should I do with addresses that verification services can't confirm?
Don't assume unverifiable means undeliverable. New construction, rural addresses, and many international locations legitimately fail lookup while receiving mail just fine. Keep the original exactly as entered, flag it for review, and maintain an internal list of addresses that failed verification but have successfully received deliveries before.