Data normalization

How data normalization works

Normalization works field by field. For each field, a team picks one standard form, writes a rule that maps every variant to it, and runs the rule wherever the field is written.

Common B2B fields each have a usual target form.

• Phone numbers. One international format with a country code, such as E.164 1.
• Company names. Legal suffixes and punctuation removed for the match key, with consistent case.
• Websites. A root domain with no scheme, www prefix, path or query string.
• Emails. Lowercase, with surrounding spaces trimmed.
• Countries and states. One code list instead of free text.
• Job titles. The raw title kept, plus mapped seniority and function values.

Each rule should keep the raw value next to the normalized one. If a rule turns out to be wrong, the team can recompute from the original instead of guessing what it was.

Normalization comes before deduplication and identity resolution. Two rows that hold the same company under different spellings only match once both spellings map to one form. HubSpot, for example, deduplicates contacts by email address and companies by company domain name 3, so the domain field has to hold a clean domain for that check to find matches.

Normalization also affects match rate. An enrichment lookup keyed on a malformed domain or an unparsed phone number can miss a record that a source holds.

Three meanings share the word. Database normalization organizes tables into normal forms to remove redundancy and inconsistent dependency 2. Statistical normalization rescales numbers to a common range for analysis. B2B data normalization standardizes field values inside whatever table design a CRM already has, and it is the meaning this page covers.

Normalization rules for common B2B fields

Each field needs its own rule, because each one fails in its own way. The rules below cover the fields that matching and outreach read.

**Phone numbers.** Store one international form for matching and keep the national form for display. A number written without a country code cannot be normalized safely, so pass a country hint from the record's country field. RichAPI's normalize_phone accepts an ISO country code hint and returns an E.164 value along with national and international display formats 4.

**Company names.** Strip legal suffixes such as Inc. and stray punctuation for the match key, and keep the legal name in its own field for contracts and invoices. RichAPI's normalize_company returns the normalized name and lists the suffixes it removed 4.

**Websites and domains.** Reduce every URL to a root domain before joining or deduplicating. RichAPI's clean_domain turns a messy URL, such as one with a www prefix, a path and a query string, into a clean root domain for 0.5 credits per call 4.

**Emails.** Lowercase the address and trim spaces. Leave the rest of the address as written, because rules about dots and plus signs differ by mail provider.

**Lists in one cell.** Split delimited values into separate items before loading. RichAPI's normalize_list splits a delimited string into a clean list and can remove empty values 4.

**Titles.** Keep the raw title and map it to a seniority and a function. The raw value preserves detail, and the mapped values make filters and lead scoring work.

**Countries.** Map free text such as United States, USA and U.S. to one code before any report or territory rule reads the field.

Example of data normalization before a list import

A marketing team imports a conference attendee list into a CRM that already holds many of the same accounts. Without normalization, the import creates second copies of companies the CRM already has.

Field     Event list                          CRM record
company   ACME TECHNOLOGIES, INC.             Acme Technologies
website   https://www.acme.example/events     acme.example
country   USA                                 United States

Both columns describe one company, and every field still differs as a string.

The team runs three passes before the import. normalize_company maps both company spellings to one name and records the removed suffix 4. clean_domain reduces the event list's full URL to the root domain the CRM already stores 4. A country lookup maps USA and United States to one code.

The import then matches on the root domain. HubSpot deduplicates companies by company domain name, so the attendee rows attach to existing companies instead of creating new ones 3. Contacts match on email address after lowercasing, which is the key HubSpot uses for contacts 3.

The company and domain passes cost 0.5 credits per call each 4. The team runs them once per unique value rather than once per row, which cuts the call count when many attendees share an employer.

The raw event values stay in separate fields. If a later review finds a wrong merge, the original spelling and URL are still there to compare.

The same rules then move to the point of entry. The team adds them to the form handler and the import template, so the next event list arrives already in the CRM's format and the batch job only has to catch what slipped through.

Data normalization vs deduplication

Normalization changes values. Deduplication changes records. Deduplication depends on normalization, because a duplicate check compares keys, and keys only compare correctly once they share a format.