How to Evaluate B2B Data Providers
By Kooperativa Engineering
Every comparison of B2B data providers converges on the same table: coverage, freshness, price, integrations, a row of checkmarks. The problem is that all four are self-reported by the vendor, none of them are measured against your data, and the two that actually determine whether the integration works are usually not in the table at all.
What follows is the evaluation we would run if we were buying rather than selling, structured as four things you can test during a trial instead of four things you have to take on faith.
1. Match rate, measured on your list and nobody else's
Every provider quotes a match rate, and every quoted match rate is true for the list it was measured on. That list is almost never shaped like yours. A provider tested against a sample of large-company US profiles will report a number that has no bearing on a list of European SMB contacts, and the gap between those two cases is routinely 30 percentage points or more.
The test is straightforward and worth doing before any commercial conversation: take 200 real records from your own database, stratified so they reflect the actual mix you care about, and run them through each provider being considered. Not the sample list the vendor offers, which is selected precisely because it performs well.
- Stratify by company size, since coverage falls off sharply below a certain headcount for most providers.
- Stratify by geography, since a dataset built from mostly-US sources will underperform on EU or APAC records regardless of headline coverage claims.
- Include records you already know the right answer for, so you can measure correctness and not just whether something came back.
2. Distinguishing "not found" from "failed"
This one is invisible on a features page and it determines whether a scheduled sync degrades over time. When a bulk request comes back with fewer records than went in, there are two entirely different reasons, and a provider that collapses them into one number is handing you a metric you cannot act on.
A record that was checked against the dataset and genuinely is not there should never be retried, it will return the same answer forever. A record that failed on a timeout or a transient error should be retried, and if it is not, your coverage is quietly worse than the dataset actually supports.
{
"profiles": [ /* ... */ ],
"requested": 100,
"matched": 71,
"not_found": 24,
"failed": 5
}The check during a trial: send a batch, then ask what the difference between those two fields is. If the answer is vague, or if the API only returns a matched count and leaves you to infer the rest by subtraction, that is a real operational cost you will pay every time a sync job runs.
3. Freshness per record, not per dataset
A dataset-level freshness claim ("refreshed every 30 days") describes an average across records, and averages hide exactly the thing that matters. What you need to know is how stale the specific record in front of you is, which requires the provider to expose a per-record timestamp rather than a marketing statistic.
Without that field, there is no way to write conditional logic around staleness: no way to decide whether to trust a title, no way to prioritise which records to refresh first, no way to tell a sales team how much confidence to place in what they are looking at. With it, all three become ordinary engineering decisions.
const profile = await enrich(identifier);
const ageInDays = (Date.now() - new Date(profile.fetched_at)) / 86400000;
// Now staleness is a decision you control, not one the vendor made for you.
if (ageInDays > 90) {
await queueRefresh(profile.id);
}4. Pricing shape, not price
The headline figure matters less than what the meter counts, because the meter determines which engineering decisions you can afford to make. Under credit-based pricing, every design choice that improves data quality also increases spend, which means the correct refresh interval and the affordable refresh interval are different numbers, and teams reliably pick the affordable one.
Three questions surface this faster than a pricing page does. Does a request that returns no match still consume a credit? Are retries after a transient failure billed? Does a periodic full-database refresh fit in the plan, or does it consume a month of allowance in one afternoon?
The scoring question nobody asks
One more test, worth running because almost nobody does: ask what a given field actually measures rather than what it is called. An employee count is not an audited figure filed with a regulator, it is a count of profiles a dataset has indexed at that company. Those two numbers track closely for a large, well-documented business and diverge meaningfully for a small or less digitally visible one.
A provider that explains this unprompted is describing its data honestly. A provider that presents an indexed count as an exact headcount is overstating what the underlying data supports, and that same overstatement is probably present in fields you have less ability to spot-check.
Where we fit, stated plainly
Kooperativa is a data-layer provider, not a platform: profile and firmographic records, change monitoring, and search, exposed as an API. Pricing is flat at $499/mo, or $449/mo billed annually, per workspace rather than per seat, with every endpoint included and unlimited requests inside a shared 500 requests per minute limit, which is specifically what makes the refresh-frequency question in point four an engineering decision rather than a budget one.
The tradeoff is narrower scope than a full platform. No email addresses or phone numbers, no intent data, no sequencing or dialing layer. If the gap you are filling is contact details, we are not the right answer or not the only one. If it is current, structured profile and company data behind an API, that is the whole product.
Get started
Try Kooperativa
One API key. Person and company enrichment, structured search, and monitors under one flat license.