What Is B2B Data Enrichment? Fields, Sources and Match Rates

What is data enrichment? It is the process of taking a record you already hold, such as an email address, a phone number or a company domain, and adding the facts you do not have yet: who the person is, where they work, what they do there, how to reach them. The share of inputs that come back with something useful is the match rate. This guide explains both, and how to test them on your own list, over REST or MCP.

The short version

• —The answer: enrichment starts from one identifier you hold and returns the fields you are missing. It adds information; it does not clean or verify what is already there.
• —The number that matters: match rate, the share of your records that come back usable. We do not quote one, because it depends on your list. The section on match rate shows how to measure it in an afternoon.
• —Who it is for: anyone with thin records, such as a signup form with only an email, a scanned badge or an inherited spreadsheet. For the wider map of person, company, email and phone lookups, read the B2B data API guide.
• —What it costs: on NeuralVerge, email enrichment is 10 points per result ($10 per 1,000) and a request that finds nothing is not billed. The full table is below.

What is data enrichment?

Data enrichment means appending missing attributes to an existing record by matching it against other data. The matching key is whatever you already know. Start from an email address and you can ask who it belongs to. Start from a company domain and you can ask who works there. Start from a phone number and you can ask whose it is.

In B2B work the starting records are usually sparse. A signup form collects an email and nothing else. A trade-show scan collects a name and a company. A spreadsheet inherited from another team has a column of addresses and no context. Enrichment turns those thin rows into records someone can act on: route to the right sales rep, score against your ideal customer profile, or decide the contact is not worth a call.

Two ideas are worth fixing in your head from the start. First, enrichment is not creation. It does not invent fields. A good lookup returns what is publicly knowable about the person or company and leaves the rest empty. An empty field is a correct answer, and a tool that never returns empties is guessing. Second, enrichment is not one thing. The input decides the lookup, and the lookup decides the output. "Enrich my CRM" is really several different questions, each with a different starting point.

Enrichment vs. data cleansing

Cleansing works on what is already in the record. It fixes casing, removes duplicates, standardises phone formats and deletes addresses that bounce. Enrichment adds information that was not there. Teams usually enrich first and deduplicate afterwards, because enrichment often reveals that two rows are the same person.

Enrichment vs. validation

Validation answers a yes-or-no question about one value: is this address deliverable, is this number live. It does not tell you anything new about the person. It tells you whether the thing you hold works.

The two pair well. If you find or enrich an address, validate it before it touches your sending domain. Validation is cheap compared with the cost of a damaged sender reputation, and it is a separate lookup with its own billing.

Person-level vs. company-level enrichment

Person-level enrichment resolves an individual from an email address, a phone number or a name plus a company, and returns names, employer, title, location and contact points. Company-level enrichment resolves an organisation from a domain, a name or a registry number, and returns legal name, address, industry, size and filings. This article leans on person-level examples because that is where match rate gets argued about most; the test method later works for both.

How a lookup works

Strip away the marketing and every enrichment lookup follows the same path. Knowing it makes it much easier to judge a vendor's claims.

1. Pick the input key

Send the most specific identifier you hold. An email address identifies a person far better than a first name; a company domain beats a trading name.

2. Normalise the key

Trim whitespace, lower-case addresses and convert phone numbers to international format. A surprising share of misses in a first test are formatting problems on your side.

3. Resolve the entity

The provider tries to find the one person or company the key refers to. This is the matching step where match rate comes from. It can succeed, fail cleanly or, worst of all, succeed against the wrong entity. Good providers return nothing before they return a bad match.

4. Gather the attributes

Some providers answer from a stored database they refresh on their own schedule; others read from their sources at request time. That affects freshness. We deliberately do not list which sites any source draws on, because the useful questions are what the data is about and how current it is.

5. Return structured output

You get the fields back as JSON, with empties left empty. Good output separates "we looked and found nothing" from "we could not look".

6. Write it back and decide

Map the fields into your CRM, and fill empty fields rather than overwriting values your team already verified. Decide in advance what happens to rows that did not match: a second lookup with a different key, a manual review, or leaving them alone.

Which fields come back

The fields depend on the lookup. For a person resolved from an email address, NeuralVerge's Email enrichment source documents this set:

• —Full names, including variants the person is known by
• —Current company and job title
• —Location, split into country, state and city
• —Other known email addresses, not only the one you sent
• —Phone numbers, for a subset of matches
• —Professional profile link and the company and title held on that profile
• —Other social handles where they are linked
• —Gender and date of birth where known, though date of birth is often empty

Treat every field as independently optional. A record can resolve cleanly on name and employer and still come back without a phone number. If your downstream logic assumes a complete record, it will break on the first partial one.

Job titles and phone numbers go stale fastest, names and countries slowest. If your use case depends on the fast-moving fields, freshness at request time matters more than the size of a stored database.

Which lookups exist

Different starting points need different lookups. These are the enrichment sources in the catalog, with figures taken from the source pages at the time of writing. Points come out of your monthly plan allowance, and the per-1,000 figures are the prices stated on each source page. See the pricing page for plans.

Email enrichment, Email finder and Phone enrichment charge only on a match, and Phone enrichment US only for successful lookups; Email validation is 1 point per check.

REST and MCP

Here is what a person-level lookup looks like in practice. It uses the Email enrichment source, which takes one email address and returns the person behind it. This is the request form from the source page, with an illustrative address in the style of our fictional Finnish company Acme Oy:

curl -X POST https://api.neuralverge.ai/functions/v1/run-email-enrichment \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "email": "jane.doe@acme.com" }'

Over MCP, the same lookup is a tool named run_email_enrichment with the same email argument. NeuralVerge hosts the MCP server at https://mcp.neuralverge.ai/mcp, so there is nothing to build or host: add the URL to a client such as Claude, ChatGPT or Cursor, sign in through the browser and approve access. Tool names use underscores over MCP, while REST paths keep hyphens. Setup for each client is covered in our guide to the MCP server for Claude.

REST and MCP reach the same lookup at the same price, so the choice is about where you are calling from. Pick REST when your own code knows when a lookup should happen, such as a signup hook or a nightly CRM refresh. Pick MCP when an agent should decide mid-task whether it needs to know who an address belongs to.

The response below is the real captured sample from the source page. It is a public-figure sample, captured for a publicly known address rather than the Acme address in the request above, which is why the values do not mention Acme. We have not edited the fields:

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "email_enrichment",
  "email": "sam@openai.com",
  "human": "# Email enrichment\n\n- **Input Email:** sam@openai.com\n- **Full names:** Sam Altman\n- **Emails:** sam@openai.com\n- **Phones:** +14155550123\n- **Company:** OpenAI\n- **LinkedIn:** https://www.linkedin.com/in/sam-altman/",
  "machine": {
    "full_names": [
      "Sam Altman"
    ],
    "gender": "male",
    "date_of_birth": null,
    "emails": [
      "sam@openai.com"
    ],
    "phones": [
      "+14155550123"
    ],
    "locations": [
      {
        "country": "US",
        "state": "California",
        "city": "San Francisco"
      }
    ],
    "company": "OpenAI",
    "position": "CEO",
    "linkedin_profile": "https://www.linkedin.com/in/sam-altman/",
    "linkedin": {
      "companyName": "OpenAI",
      "title": "CEO",
      "profileUrl": "https://www.linkedin.com/in/sam-altman/"
    },
    "x_profile": "https://x.com/sama",
    "telegram_username": null
  },
  "total_points": 10
}

Notice that date_of_birth and telegram_username are null: an honest empty, not an error. The human summary is for reading and the machine object is for code. total_points is 10, the cost of this one lookup. For a field-by-field walkthrough of the call, the source page is the reference for exact fields, request shape and prices.

Match rate and how to measure it

Match rate is the share of input records for which a lookup returns a usable result. If you send 200 addresses and 120 come back resolved to a person, your match rate on that file is 60 percent. That arithmetic is the easy part. The hard part is that the number means different things depending on how it was produced, which is why we are not quoting a figure for any source. Nobody can honestly give you one without seeing your list, and we have not measured one that would hold across lists.

What drives match rate

Several things move it, and most of them live in your data, not in the vendor's:

• —Input type. Work email addresses at companies with a public presence tend to resolve far more often than personal mailbox addresses. Shared and role mailboxes such as info@ or support@ belong to a function rather than a person, so they usually do not resolve at all.
• —List age. Addresses that were valid three years ago point to people who have since moved on. Old lists have more dead inputs.
• —Region. Public footprints differ by country and industry, so the same tool can behave differently on two halves of one file.
• —What counts as a match. This is the one vendors rarely define.

The match definition problem

A match can mean three different things:

1. —The lookup returned any record at all.
2. —The lookup returned a record with the specific field you need, such as a phone number.
3. —The lookup returned a record that is actually the right person.

These give very different numbers on the same file. A headline match rate usually uses the first definition. What you care about is the third definition applied to the second: the right person, with the field you need. A tool can look excellent on a vendor's definition and poor on yours.

1. Build a representative sample

Take a random slice of the records you will actually enrich, not a hand-picked set of easy ones. A few hundred rows is enough to see the shape. Keep the mix honest: if 30 percent of your list is personal addresses, 30 percent of the sample should be too.

2. Define a hit before you run anything

Write down what counts. For example: "resolved to a person, with a current employer and a job title." Decide this first so you cannot move the goalposts after seeing the results.

3. Run the sample and record outcomes per row

Log three outcomes per row: matched with the needed fields, matched without them, and no match. Also keep the raw response for any row you want to spot-check.

4. Spot-check accuracy by hand

Pick a small set of matched rows and verify them against something you trust, such as your own CRM history, a colleague who knows the account, or the person's published profile. You are looking for wrong-person matches and stale titles. Even twenty or thirty checked rows tell you a lot.

5. Split the results by segment

Report match rate by input type, region and list age, not as one blended number. A blended 55 percent can hide 80 percent on work addresses and 10 percent on personal ones. The split tells you where the tool is worth using and where it is not.

6. Price it per useful record

Divide what you spent by the number of records that met your definition of a hit. A cheap lookup with a low hit rate on your data can cost more per useful record than a pricier one that resolves more of your file. If a provider bills every request, a poor list costs full price; on NeuralVerge's enrichment sources, lookups that find nothing are not billed, so a messy sample costs you only the matches.

Cost and limits

Pricing per result means your bill follows your usage, which suits spiky work and agents. It is not automatically cheaper for the same huge file every week, so run the cost-per-useful-record calculation from the previous section on your own volumes. The rates are in the table above.

• —Not every record resolves. Personal addresses and role mailboxes resolve far less often. Decide in advance what happens to those rows.
• —Fields go stale. Act on an old title or phone number as if it were current and it will cost you.
• —Wrong-person matches exist. Common names cause them. Spot-check, and prefer a provider that returns nothing over a confident wrong answer.
• —Phone numbers come back for a subset of matches only, and Email enrichment does not return carrier or line-type data.
• —Compliance is yours too. Enrichment returns personal data, so you need a lawful basis, an opt-out and a way to honour deletion requests.

How to decide

Use these questions before you commit to a provider, and again before you run a large file:

• —How does the provider define a match, and is a wrong-person result counted as a miss?
• —Does it return nothing when unsure, or a best guess?
• —Which fields come back, and does the documentation say which are often empty?
• —Is the data resolved at request time or served from a stored copy?
• —Are misses billed, and can you run a low-cost sample on your own file first?
• —Are empties distinguishable from errors in the response?
• —Does the provider state its limits honestly, such as weaker results on personal addresses?
• —What do the terms say about your intended use, and what is your own lawful basis?
• —Can your systems and agents reach it through REST, MCP or both?

The use cases that fit best:

• —Inbound lead routing. Turn a bare work email into a named, titled lead before it reaches the queue.
• —CRM clean-up. Fill in the title, employer and profile links the form never asked for, then deduplicate.
• —Outbound list building. Find a work address from a name and domain, validate it, then send.
• —Account research. Resolve a caller by phone number so the rep knows who is on the line.
• —Agent workflows. Let an AI agent resolve a person from one identifier mid-task.

Frequently asked questions

What is data enrichment in one sentence?

Data enrichment is the process of taking a record you already hold, such as an email address, a phone number or a company domain, and adding the fields you do not have, such as the person's name, employer, role, location or contact details.

What is a good match rate for enrichment?

There is no universal number, and anyone quoting one without knowing your list is guessing. Match rate depends on the input type, the region, how old the list is and how many of the records are personal addresses or shared mailboxes. The reliable way to find out is to run a sample of your own records and count how many come back with the fields you need.

Is data enrichment the same as data cleansing?

No. Cleansing fixes or removes what is already in a record, such as typos, duplicates and dead addresses. Enrichment adds information that was never there. Most teams do both, and validation is usually the step that sits between them.

Do I pay for records that do not match?

That depends on the provider, so check the billing terms before you run a large file. On NeuralVerge's enrichment sources a request that finds nothing is not billed, so a test on a messy list only costs you the matches.

Is B2B data enrichment legal?

Enriching records means processing personal data, which needs a lawful basis under rules such as GDPR. Business-to-business outreach is commonly run under legitimate interest with a documented assessment and a working opt-out. That is a decision for your own counsel, and it is not legal advice.

How often should I re-enrich my data?

People change jobs and companies change names, so enriched fields go stale. A sensible pattern is to enrich at the moment a record is created and again before any large campaign, rather than on a fixed calendar schedule.

Can I run data enrichment over MCP instead of REST?

Yes. NeuralVerge hosts an MCP server at https://mcp.neuralverge.ai/mcp, and the enrichment sources are tools on it, for example run_email_enrichment. An agent in Claude, ChatGPT or Cursor can resolve an email address mid-task. The input, the response and the price in points are the same as over REST.