How to enrich a CSV of leads without making it worse
Bulk enrichment is mostly a data-handling exercise, and the enrichment itself is the easy part. Most of the damage happens before the upload and after the download. Here is a procedure that avoids the usual ways it goes wrong.
Before you upload: fix the source file
Every problem you carry into an enrichment run comes back multiplied, because now you have two copies of it. Spend the time here.
- Add a stable row identifier. If your file has no unique ID per row, add one now — a simple sequential number is fine. Without it you cannot reliably merge results back, and this is the single most common cause of a botched enrichment.
- Deduplicate on the identifier you will actually enrich against, not on the display name. "Jon Smith" and "Jonathan Smith" at the same company are probably one person; two rows with the same profile URL definitely are.
- Strip tracking parameters and trailing content from URLs. A URL with a query string attached may not match one without it, and you will pay twice for the same record.
- Remove rows you already have good data for. Enriching a record that is already complete costs money and risks overwriting something correct with something merely plausible.
- Decide in advance what you will do with partial results, before you see them. Deciding afterwards means deciding under pressure to justify the spend.
Choose the join key deliberately
The join key is the field that links an enriched result back to your original row. Getting this wrong is how enrichment projects produce files that are worse than what went in.
Names are a bad join key: they are not unique, they are inconsistently formatted, and they change. Company names are worse — legal name, trading name and the name on the website are frequently three different strings.
A profile URL or an email address is a much better key. It is unique, stable, and either matches or does not. If your source data has neither, that is worth fixing before enriching rather than after.
Size the run realistically
Most tools cap file size, and there is a reason beyond arbitrary limits: a smaller batch fails smaller. Running a hundred rows tells you what your resolution rate looks like on this list before you commit the other nine hundred.
Run a deliberate pilot. Take a sample that is representative rather than the first hundred rows — those are often your oldest records and will give you a pessimistic read. Look at what came back, then decide whether the rest is worth running.
Interpreting what comes back
A finished run gives you three groups, and the second is the one people mishandle.
- Resolved — a verified address and, usually, the company context alongside it. Use these.
- Unresolved — no result, with a reason. These are not failures of the tool so much as facts about the record: no employer listed, no identifiable mail domain, or a mail server that refuses to answer. Keep the reason; it tells you whether a retry is worth anything.
- Ambiguous — most commonly catch-all domains, where the server accepts mail for any address so the specific person could not be confirmed. Decide as a policy whether you send to these, and apply it consistently rather than case by case.
Retry properly
Some unresolved rows are worth retrying and some are not, and the reason code tells you which.
A row that failed because the mail server did not respond is worth retrying — greylisting is deliberately temporary, and a second attempt some hours later often succeeds. A row that failed because the person has no employer listed will fail again for the same reason, and retrying it is just spending money to be told the same thing.
Retry only the rows that failed. If your tool re-runs the whole file and charges for it, that is worth knowing before you use the retry button.
Merging back
The merge is where a good run gets ruined. A few rules that prevent most of the damage:
- Never overwrite a verified existing value with an enriched one. Enrichment fills gaps; it should not adjudicate conflicts. Where both exist and differ, keep both and flag it.
- Record the enrichment date on every row you touch. Six months later this is the only way to know which records are stale, and it costs one column.
- Keep the unresolved rows in your file rather than dropping them. A record that could not be enriched is still a record, and silently losing it makes your coverage numbers look better than they are.
- Import into a staging area first and inspect it before it touches your production system. Enrichment errors are much cheaper to fix before they are merged than after.
Make it recurring, not heroic
Contact data decays continuously — people change roles, companies are acquired, domains move. A one-off clean-up fixes a snapshot and then starts decaying the same afternoon.
A modest job that runs weekly beats a large one that runs when someone remembers. If your tool supports scheduled runs with a spending ceiling, that is the feature to use: it converts data hygiene from a project that needs a champion into a background process that does not.
ReachNow supports this pattern directly — files up to 100 rows, per-row status with reasons, retry limited to the rows that did not resolve, and scheduled runs with a credit ceiling so an unattended job cannot overspend.