Candidate data normalization: the complete method for recruiters
Normalize your candidate data to get a unified, deduplicated database, ready for matching and multichannel engagement.
Normalizing your candidate data means producing a unified, deduplicated and formatted database (E.164, ISO 8601, RFC) ready for matching and multichannel engagement. In practice, it takes five steps: audit, deduplication, validation, normalization and enrichment, followed by a quality check before export. A sourcing platform like Kalent shows clearly what an already cleaned database looks like at scale.
In short:
- Deduplicating before normalizing avoids processing the same candidate twice under different formats, reducing errors and inefficiencies.
- Strict validation of critical fields such as email and phone guarantees a reliable database before any enrichment or normalization.
- An initial audit on a sample shows whether the cleanup is a simple adjustment or a complex project requiring several weeks.
- Automation must include a human review of duplicates with a confidence score, to avoid wrong merges and preserve data quality.
Table of contents
- Why normalize candidate data and what concrete gains to expect
- Recommended flow: audit, deduplication, validation, normalization, enrichment, QA
- Normalizing phones, emails and dates: technical rules and recommended tools
- Business mapping: harmonizing job titles, skills and pipeline stages
- KPIs, QA checklist and targets to hit before integration or a campaign
- Scaling up with tools and field evidence
- When to keep normalization in-house and when to rely on a platform
- How Kalent puts this normalization into practice and speeds up sourcing
- Frequently asked questions
- Sources
Why normalize candidate data and what concrete gains to expect
A badly formatted candidate database breaks matching before it even starts: a number without a country code, an unreadable date or a job title written ten different ways mechanically reduce the relevance of results. The quality of input data directly determines the reliability of the models used for matching, a principle formalized by the ISO/IEC 5259-3 standard, dedicated to data quality management for AI and machine learning.
A data quality management framework, such as the one described by ISO/IEC 5259-3, helps structure validation thresholds and the traceability of corrections made to a candidate database.
The expected gains show up at several levels:
- Fewer routing errors in email or SMS campaigns.
- Engagement sequences that actually reach the right contacts, on the right channels.
- Less processing time for sourcing teams, who no longer fix each record by hand before sending.
- A database a matching tool can use directly, with no downstream fixes.
These benefits are not about comfort: they determine whether an outreach campaign reaches its target or wears itself out in bounces and technical rejections.
Recommended flow: audit, deduplication, validation, normalization, enrichment, QA
The order of operations is not arbitrary. Deduplicating before normalizing avoids processing the same record twice under two different formats, and validating before enriching keeps you from spending enrichment time on data that will be rejected anyway. A practical guide to data migration and cleaning details this logic: deduplication, then email validation, then phone and date normalization, then enrichment, then a final quality check.
Here are the steps for a team starting this project:
- Run an audit on a sample of 100 to 200 records to identify the types of duplicates present: re-applications, name variants, test or demo data.
- Rank duplicates by confidence level: an exact email match allows an auto-merge, everything else goes into a human review queue.
- Validate critical fields (email, phone) before any enrichment step, so you do not enrich invalid contacts.
- Normalize formats (phone, date, titles) once the database is deduplicated and validated.
- Document every rule applied so you can audit and recalibrate it later.
This approach, which separates audit, human review queue and progressive automation, matches recommended practices for detecting duplicates in a candidate pipeline. An initial audit on a sample quickly reveals whether the cleanup is a few hours of adjustment or a project of several weeks, which lets you size resources accordingly.
Pro tip: ask your AI tool to generate a list of likely duplicates with a confidence score and the IDs of the records involved, rather than letting it merge automatically: merging remains a human decision as long as the match is not exact.
Normalizing phones, emails and dates: technical rules and recommended tools
Three fields account for most normalization errors: phone, email and date. For numbers, the target is the international E.164 format, which caps each number at 15 digits and structures the data into country code, national destination code and subscriber number, according to the ITU-T E.164 recommendation.
The E.164 standard sets a maximum length of 15 digits for an international number, which makes it a reliable format for SMS routing and automated calls.
To make this parsing reliable, the libphonenumber library provides per-country metadata and documents common pitfalls, such as a leading zero to remove or an extension like "x102" to isolate before storage.
For emails, following the format described in the SMTP specification RFC 5321 requires an address structured as a local part and a fully qualified domain, the basic condition before any deeper check (existence of an MX record, for example).
A few common pitfalls to handle systematically:
- A local number entered without a country code, which becomes unusable for an international campaign.
- A landline extension stuck to the main number with no separator.
- A date in free text format, impossible to sort or compare without conversion.
- A misspelled email domain that passes syntax validation but fails at delivery.
Finally, dates are stored in ISO 8601 (YYYY-MM-DD), the only format that removes the ambiguity between American and European notations and makes chronological sorting of applications easy.
Business mapping: harmonizing job titles, skills and pipeline stages
Job titles and skills rarely arrive in a consistent form: "Dev Full Stack", "Développeur Full-Stack" and "FS Developer" describe the same thing without being recognized as identical by a standard search engine. The method is to build a target taxonomy, then map each variant you encounter to it.
- Export all distinct values in the database for a given field (titles, skills, status).
- Prioritize by frequency to handle first the variants that affect the largest number of records.
- Build a mapping table that groups synonyms under a single target value, with a fallback rule for unrecognized cases.
- Validate by sampling by checking that a batch of mapped records matches the original intent.
An application cycle often has nine different statuses depending on the ATS (application received, under review, interview scheduled, interview done, technical test, offer made, offer accepted, rejected, withdrawn), which usefully boil down to four target stages: new, in progress, offer, closed.
KPIs, QA checklist and targets to hit before integration or a campaign
Before exporting a database to an ATS or launching an engagement campaign, a few indicators let you check objectively that the cleanup reached its goal, rather than relying on a feeling.
The final checklist before going live comes down to three steps: a small-scale test send to check the real bounce rate, a last human review of the sample flagged as uncertain, and an import into a sandbox environment before the final switch to the production ATS.
Scaling up with tools and field evidence
Once the method is set, the challenge becomes repetition: rerunning the cleanup at every import, not just once. Native integrations between a sourcing tool and the ATS avoid re-entering or reformatting data at every export to the HR pipeline.
- Schedule periodic quality control jobs rather than a one-off cleanup that degrades over time.
- Keep a backup before each automated normalization run, so you can roll back.
- Track the same indicators over time (valid email rate, E.164 rate) to detect drift.
On this front, our talent search engine relies on an enriched database with a high share of usable mobile numbers and personal emails across more than 200 million profiles available in Europe and the United States, which spares our clients from rebuilding this normalization layer in-house. Outreach automation via LinkedIn, email and WhatsApp runs directly on this normalized data to cut sourcing time in half.
Pro tip: before handing a batch of data to an external AI tool, check what information is actually transmitted: an article on using AI tools without sharing personal data details the precautions to take.
When to keep normalization in-house and when to rely on a platform
Keeping it in-house makes sense when volumes stay modest and the team has the technical skills to maintain parsing scripts. As soon as the database exceeds a few thousand records or multichannel enrichment (mobile phone, personal email) becomes necessary, maintaining in-house normalization rules becomes out of proportion with the gain.
Before investing, three questions settle the decision: what volume of applications do we process each month, how often does the database need refreshing, and do we have the skills to maintain these rules over time.
Jules
How Kalent puts this normalization into practice and speeds up sourcing
Rather than rebuilding a cleaning and enrichment pipeline in-house, we offer a database that is already normalized and ready to use. Our data enrichment gives access to directly usable contacts (80% mobile numbers, 60% personal emails) across more than 200 million profiles in Europe and the United States.
- Search and filtering of qualified profiles without Boolean search.
- Multichannel outreach automation (LinkedIn, email, WhatsApp) on data that is already correctly formatted.
- Significant reduction in sourcing time thanks to this automation.
- Direct integration with ATSs to export qualified profiles without re-entry.
To compare plans in detail, see our pricing page or book a demo.
Frequently asked questions
What exactly is candidate data normalization?
The end goal is a unified database where every field follows a single convention.
In what order should you deduplicate, validate and normalize?
The recommended order is deduplication, then email and phone validation, then format normalization, then enrichment, then a final quality check, as described in this guide on data cleaning and deduplication. Deduplicating first avoids normalizing the same record twice under two different formats.
Should duplicate merging be fully automated?
No: only an exact email match justifies an automated auto-merge, while other cases must go through a human review queue before merging, according to the practices described for detecting duplicates in a candidate pipeline. This caution avoids mistakenly merging two distinct profiles that share a similar name.
Which phone format should you use for international campaigns?
The E.164 format remains the reference, with a maximum length of 15 digits and a country code plus national number structure, according to the ITU-T E.164 recommendation. This format guarantees reliable routing whatever the contact's country of origin.
How do you check that a candidate database is ready for a campaign?
A small-scale test send, a last human review of uncertain records and an import into a sandbox environment before switching to production let you validate the database.
Sources
- Recommendation ITU-T E.164 (02/2026) The international public telecommunication numbering plan
- ISO/IEC 5259-3:2024 - Data quality management requirements and guidelines
- How to use AI to detect duplicate candidates pipeline (SHRM)
- RFC 5321 - Simple Mail Transfer Protocol
- PhoneNumberMetadata (libphonenumber)
