B2B Contact Data Accuracy
A Field-Level test (2026).
A B2B contact record can be complete and still be wrong. Microsoft distinguishes accuracy, which concerns whether data represents a real-world entity, from completeness, which concerns missing values. Its documentation explicitly notes that a field can be present without being correct. That distinction is the starting point for evaluating a prospecting database. A vendor's record count or verification label should not be treated as a universal percentage of correct contacts. 1
This is a field-level testing guide, not a leaderboard. The existing provider-ranking article explains why a shared test set is necessary. Here the goal is more operational: specify denominators, collect an independently checked sample, and report accuracy separately for role, company, work email, and phone. There is no single number that captures those fields across every geography and buyer segment.
Seven measures that should not be collapsed
Correctness asks whether a supplied value matches a dated, defensible reference for the intended person. A current title can be correct while the company is wrong, and a phone number can connect to a business but not the named contact. Record each field independently. Microsoft's accuracy dimension is about representing the real-world entity, while its consistency dimension asks whether values conform to a rule without contradiction. Consistency is useful but does not itself prove external truth. 1
Completeness asks whether the required field has a value. Calculate it with all eligible target people in the denominator: records with a usable work-email field divided by eligible records, for example. A nonempty string is not automatically an accurate address. Microsoft's completeness definition explicitly separates presence from correctness. 1
Freshness asks when the value was last observed or verified and whether that date is recent enough for your purpose. It is not identical to accuracy: an old title may still be right, and a recently collected value can be wrong. Microsoft's timeliness dimension and Lusha's documented email update-date field illustrate why a timestamp should travel with a field-level assertion. 14
Coverage asks whether the vendor has a record or field for the target population. It differs from completeness within returned records. A database may return richly populated profiles for a narrow subset while missing much of the actual territory. State whether the denominator is all companies in the target segment, all named people, or only records the vendor returned.
Match rate asks whether an input person or company can be associated with a vendor record under a stated matching rule. It is not automatically field accuracy. Apollo says matching depends on supplied parameters, and a response can succeed technically while enriching no record. It exposes high, medium, and low confidence labels; those labels express its match assessment, not an independent audit of every returned phone or email. 2
Verification status asks what check was applied, to which field, when, and by whom. Lusha documents email confidence tiers and a last-update field, plus phone classifications for direct, mobile, and headquarters numbers. Those attributes can help segment a test, but they are vendor metadata, not proof that an independently sampled contact will answer or that a particular use is permitted. 4
Uniqueness asks whether one real person is represented by multiple records. Microsoft treats it as a distinct quality dimension. HubSpot's duplicate manager compares contact attributes such as name, email, phone, and company and separately uses company fields including domain and location. A duplicate suggestion should be reviewed before merging because similar names and shared switchboards can identify different people. 13
Build a representative test cohort
Begin with the population you actually intend to serve: regions, company sizes, industries, job functions, seniority bands, and account types. Freeze the eligibility rules before asking vendors for results. Draw a sample from that population rather than from a vendor's own search results. If a vendor selects only its known records, missing records disappear from the denominator and coverage looks artificially strong.
Stratify the sample. For example, if half your target accounts are in two countries, preserve those countries as separate strata; if executive contacts matter more than individual contributors, report those groups separately. Do not average a strong US sample with a thin regional sample into a single global claim. Record sample sizes and uncertainty where appropriate. No vendor accuracy percentage from a differently selected sample should be transplanted into this cohort.
Prepare a dated reference record for each sampled person using lawful, reliable sources and human review. The reference should contain a person identifier, employer, current role, region, source date, and permissible contact fields. Allow an unresolved outcome when the reference cannot establish truth. For phone, distinguish direct, mobile, and headquarters numbers; Lusha's schema documents those categories, which demonstrates why one generic phone column loses important context. 4
Use identical inputs across providers. Apollo's documentation says richer identifying input makes a match more likely and warns that name-only input can produce a technically successful response with no enrichment. If one vendor gets name plus company domain while another gets only a name, the resulting match rates do not compare the same task. Preserve the input payload and field mapping for each run. 2
Calculate the measures with explicit denominators
For each field, report returned-field coverage as the number of eligible target people for whom that field was returned divided by all eligible target people. Then report conditional correctness as independently confirmed correct returned values divided by returned values with a resolvable truth check. Finally, report end-to-end usable yield as confirmed correct and permitted values divided by all eligible target people. These are proposed formulas; the important point is that they answer different questions.
Show unresolved checks rather than silently dropping them. Suppose 100 eligible people are tested, 70 phone fields are returned, and 50 can be independently adjudicated. If 40 of those 50 match the intended person, conditional correctness is 80% of adjudicated returns, returned-field coverage is 70% of the full target sample, and the confirmed yield is at least 40% of the full sample. Those values are a hypothetical illustration, not research findings or a provider score. The remaining 20 returned fields need an explicit unresolved label.
Track formatting and contradictions separately. Microsoft's conformity dimension concerns formatting rules, such as whether values follow an expected representation; it does not establish that the value belongs to the right person. Cross-field contradictions can reveal a problem, but a fully consistent profile can still be stale. 1
Make the outcome lawful and auditable
The reference set should contain only data your organization is allowed to collect, retain, and use. Keep access limited, document the purpose, honor suppressions and objections, and avoid using a data test as a pretext for unpermitted outreach. Lusha documents a Do Not Call indicator for phone fields, but a vendor flag is not a substitute for your own jurisdiction-specific legal review and suppression process. 4
Document where the vendor says its data comes from, but treat process statements as assertions. Lusha says it cross-checks multiple sources into a profile; Apollo explains how input parameters affect matching; HubSpot shows duplicate detection rules. These are useful design facts, not comparable independent accuracy tests. 523
Publish a methodology before publishing a number: population, geography, field definition, sampling procedure, source dates, reference standard, adjudication rules, unresolved count, and denominator. If any of those change, label the new run separately. The practical decision is which source gives enough correct, current, lawfully usable data for your exact target segment at an acceptable cost, not which logo wins an unsupported universal ranking.
FAQ
Is complete contact data necessarily accurate?
Does a successful Apollo API response guarantee an enriched record?
What phone categories does Lusha document?
Rather have outbound done for you?
Modern Inbound runs the whole stack: the data, the inboxes, the copy and the replies. You take the meetings.
Have Modern Inbound build the outbound systemSources
- Microsoft, data quality dimensions, verified October 2, 2026.
- Apollo, People Enrichment documentation, verified October 2, 2026.
- HubSpot, duplicate-record management, verified October 2, 2026.
- Lusha, documented contact fields, verified October 2, 2026.
- Lusha, data sources, verified October 2, 2026.