A large database can still miss the accounts you care about. A fast response can still resolve the wrong company. Evaluate providers on the same work your team needs to do, with explicit definitions of a successful result.
This is a methodology and a blank worksheet, not a published benchmark. It contains no provider scores or measured Vencavo results. Vencavo has 299M+ contact records and 25M+ company records; those totals do not establish coverage or quality for your particular workflow. Discuss an evaluation with our team.
What you’ll take away
- A repeatable comparison using the same inputs and acceptance rules for every provider.
- Separate measures for identity matching, field quality, freshness, latency, and cost.
- A blank observation worksheet, local cost calculator, and decision format that preserves uncertainty.
1. Define success before seeing results
Choose one task, such as enriching known company domains for account planning. Write down required fields, accepted formats, freshness needs, and what a usable result means.
For an example company-enrichment task, you might require the correct company identity, country, industry, and employee band. Treat missing or unverified values differently from demonstrably wrong values. Decide how you will handle subsidiaries and parent entities before testing them.
Set decision thresholds based on the workflow’s tolerance for error, delay, and manual review. An account-planning export and an interactive application may need different latency targets. Do not change the acceptance rule after learning which provider it favors.
Write the acceptance rule in a form a reviewer can apply without guessing. This example defines a review contract, not a measured result:
Task: enrich known company domains for account planning.
Identity: the returned domain must resolve to the intended entity.
Required fields: country, industry, employee band.
Field policy: each required value is present and supported by
the reference evidence; conflicting values require manual review.
Freshness: apply the field-specific limits set before the test.
Unknown freshness: manual review, not an automatic pass.
Usable result: passes identity, required fields, and freshness.2. Build a representative, permitted sample
Select inputs from the markets you actually serve. Include relevant regions, company sizes, industries, and difficult cases such as similarly named companies or subsidiaries. Label these groups so you can inspect performance by segment.
Use the same inputs for every provider. Keep a small development set for fixing your integration and a separate evaluation set for the comparison. Respect the providers’ usage terms and limits; a benchmark should not become a load test.
Record the sampling method and sample size. A handpicked list of recognizable companies does not establish performance across your entire market. If a segment contains only a few examples, report those counts and avoid presenting its percentage as a reliable market-wide estimate.
3. Establish an independent reference
Before comparing responses, create a reference record from sources you are entitled to use. Save the evidence, the field’s observation date when known, and the reviewer’s decision.
For each test input, review whether the result identifies the intended entity. A plausible name is not sufficient when the domain belongs to a different company. Where the reference itself is uncertain, mark the case unverifiable instead of treating a provider’s disagreement as an error.
Record field outcomes as correct, incorrect, missing, or unverifiable. If a provider legitimately uses a different taxonomy, document the mapping you apply consistently to all results. Keep raw values so a reviewer can reproduce that mapping.
4. Measure coverage and correctness separately
Use denominators that expose what happened:
- Response coverage: successful result responses divided by all attempted inputs. This says nothing by itself about identity correctness.
- Verified match rate: verified correct entity matches divided by all attempted inputs. Keep wrong matches, unmatched inputs, and unverifiable cases visible alongside this rate.
- Required-field coverage: nonempty required field values divided by all expected required field slots. Do not count an empty string or placeholder as a supplied value.
- Evaluable field accuracy: correct field values divided by correct plus incorrect field values. Report missing and unverifiable counts separately; otherwise a sparse provider can appear deceptively accurate.
- Usable-result rate: results meeting your predeclared identity, field, and freshness criteria divided by all attempted inputs.
Report both counts and rates for the overall sample and each segment. A high overall score can hide poor coverage in the geography your next customer needs.
5. Treat freshness as evidence
A response received today can contain old information. Distinguish the request time, the provider’s last-observed timestamp, and the underlying source’s date.
Check time-sensitive fields against the reference snapshot. When the provider supplies no evidence of freshness, label freshness unknown. Do not turn a missing timestamp into a zero-day-old record. A claimed refresh schedule and a verified change in a sampled field are different observations.
Choose the freshness requirement by field and use case. Entity identifiers usually need a different review policy from role changes or hiring activity. State that policy in the report so another evaluator can reproduce the decision.
6. Time the complete workflow
Measure from starting the request to receiving a result your workflow can consume. Keep client region, concurrency, payload, batch size, timeout, and retry policy consistent. Log cache mode where known and distinguish first requests from repeated requests.
Report successful-request median and p95 latency alongside timeout, error, and retry counts. Also report end-to-end elapsed time for each input, including retries. Excluding failures from the latency chart without showing the failure rate rewards systems that fail quickly or often.
State the percentile method and observation count. For a simple reproducible p95, sort successful latencies and select rank ceil(0.95 × n), counting ranks from one. Small samples make the tail estimate unstable; show the raw observations rather than implying precision you did not measure.
7. Compare cost per usable result
Record the current quoted pricing model and the units actually billed: requests, records, fields, credits, or another unit. Include charges for retries, misses, or extra fields where applicable, and record discounts or minimum commitments separately.
Calculate variable cost per usable result as attributable metered charges divided by the number of usable results. If there are no usable results, the ratio is undefined—not zero. Show the charges and zero usable count directly.
The local evaluation calculator below works through the usable-result rate and unit-cost arithmetic with your own counts. It does not score providers or store your inputs.
Keep evaluation spend separate from a forecast. For a production estimate, state expected volume, usable-result assumptions, fixed fees, minimum commitments, and manual review effort. Do not allocate a monthly minimum to a tiny test batch and present the result as a universal unit price.
8. Write a decision someone can challenge
Summarize where each provider worked, where it did not, and which limitations matter to the chosen workflow. Preserve raw responses, reference evidence, configuration, and calculations under your organization’s retention and access rules.
Use a short decision record
End the evaluation with the task, sample definition, acceptance rule, observed results, unresolved cases, and the person responsible for the next decision. Put aggregate rates beside their counts. Include the weakest relevant segment and any case that changed the recommendation.
State what would reverse the decision: for example, a failure in a required geography or an unworkable cost at the expected volume. That makes a later re-evaluation specific. It also keeps an attractive overall score from overruling a requirement that was essential at the beginning.
Use the provider evaluation worksheet for per-input observations. The blank rows intentionally contain no benchmark results. Duplicate a row for each provider, input, and repeat; use consistent IDs to compare identical cases. The required_field_outcomes column can use entries such as industry:correct; country:missing so an auditor can trace summary counts to decisions.
Before selecting a provider, examine the contract and operational requirements that the worksheet does not score: permitted uses, deletion handling, access control, support, and integration maintenance. Bring your results back to the original task. The best fit is the provider that supports that task at an acceptable total cost and level of uncertainty.
For a first look at product scope before testing records, use the Vencavo comparison framework. It separates workflow fit from claims about data quality; the worksheet and calculator here are for your own measured results.
What did a usable result cost?
Enter counts and metered charges from a sample you evaluated. Use your own currency. The calculation runs locally in your browser; your inputs are not sent to Vencavo. This is not a benchmark.
Rate = usable results ÷ attempted inputs. Cost = metered charges ÷ usable results; with zero usable results, that cost is undefined.