Waterfall enrichment: why one data provider is never enough

Here is a number most teams never measure: what percentage of your enriched records come back complete?

Almost nobody knows. The enrichment runs, records get written, outreach goes out. Nothing announces a failure, because a missing field is not an error. It is just an empty column, and empty columns do not page anyone.

The typical single-source coverage rate is somewhere between 60 and 80%. That means one in four of your target accounts is being worked with incomplete data, and you are not being told which one.

Why no provider has complete coverage

Every enrichment vendor builds its dataset differently. Some scrape, some license, some rely on user contribution, some infer. Each method has systematic blind spots rather than random ones.

The predictable gaps:

• Company size. Sub-50-employee companies are poorly covered almost everywhere. There is less public surface to build from.
• Geography. Coverage outside North America drops sharply, and vendors rarely volunteer this. European and APAC records are frequently thinner in ways aggregate match rates hide.
• Field type. A provider strong on firmographics is often weak on tech stack. One strong on contacts may be weak on funding.
• Recency. Contact data decays at roughly 25 to 30% a year through job changes. A provider's refresh cadence matters more than its raw record count.

These gaps do not overlap neatly. That is the entire argument for a waterfall: provider B is often strong exactly where provider A is weak, because they built their data differently.

How a waterfall works

Query providers in sequence. Each one fills only the fields the previous ones left empty.

Domain in
   ↓
Provider A (primary)  → 72% of fields filled
   ↓  (only the gaps)
Provider B (secondary) → +14%
   ↓  (only the gaps)
Provider C (specialist) → +6%
   ↓
92% complete

Two things make this work, and both get skipped.

Only query for missing fields. The naive implementation queries every provider for every record and merges the results. That triples your cost and creates a conflict problem you then have to resolve. Query provider B only for the fields A returned empty.

Order by cost and hit rate, not by contract size. Your cheapest provider with acceptable coverage goes first. Expensive specialists go last, where they run against the small remainder. Teams routinely put their largest contract first because it feels like getting value from it, which is exactly backwards: the biggest contract should be doing the hardest work, not the easy work.

The rule that matters more than provider choice: degrade, do not fail

Every provider will be unavailable at some point. Rate limits, expired credits, an outage, an API change.

If your enrichment stops entirely when one source is down, you have built something brittle that will fail on a Tuesday for reasons nobody understands.

The pattern:

• Wrap each provider independently. Catch timeouts, 429s, auth failures and schema changes per source.
• Mark it unavailable and continue. Never let one failure abort the run.
• Only fail if every source is down.
• Record which sources contributed to each record, on the record itself.

That last one is what makes the whole thing debuggable. When outreach based on a record goes wrong, "this account was enriched web-only because the primary was rate-limited" is a diagnosis. Without it, you have a mystery.

This is the highest-value engineering decision in the enrichment layer and the one most commonly skipped, because it only pays off on the day something breaks. It is worth more than any provider comparison. We cover where this sits in the wider system in GTM engineering.

The second pass most teams skip

Structured APIs give you a skeleton. Headcount, revenue band, tech stack, open roles, funding.

They do not tell you how the company describes its own category, what its product language suggests about direction, or what changed recently in how it positions itself. That reading is what separates outreach that is merely *accurate* from outreach that feels *informed*, and it used to be too slow to run per account.

Call it unstructured enrichment. It is now cheap enough to run on every target rather than only on the top twenty, which is a genuine change in what is possible. What to actually look for, in what order, is covered in account research for B2B.

Conflict resolution

When two providers disagree, you need a rule decided in advance rather than argued about later.

The general principle: prefer recency over confidence scores. Confidence scores describe how sure a vendor is about data that may be two years old. Recency is a fact.

Instrument coverage, monthly

The metric nobody tracks and everybody needs:

Coverage rate = the percentage of enriched records where every field you actually use came back populated.

Two rules for measuring it honestly:

Measure only the fields you use. If you never use SIC codes, their absence is not a gap. Padding the denominator with fields nobody reads flatters the number.

Segment it. Aggregate coverage of 85% can hide 95% in North America and 55% in Europe. If a meaningful share of your pipeline is European, the aggregate is actively misleading you.

Below 70% on the fields you use, fix enrichment before touching anything downstream. Every layer above inherits the gap, and a beautifully orchestrated sequence built on incomplete data just produces well-timed irrelevance at scale.

Frequently asked questions

What is waterfall enrichment?

Querying multiple data providers in sequence, where each one fills only the fields the previous providers left empty. It exists because no single provider has complete coverage, and providers tend to be strong in different places because they build their datasets differently.

Why is single-source enrichment a problem?

A single provider typically returns complete records for 60 to 80% of queries. The remaining records are incomplete, and nothing flags them, so incomplete data flows into outreach silently. Teams usually discover the gap only when they measure coverage rate directly.

How do you order providers in a waterfall?

Cheapest provider with acceptable coverage first, specialists last. Each subsequent provider runs only against the shrinking remainder, so the expensive ones do the hard work rather than duplicating the easy work. Order by cost and hit rate, never by contract size.

What happens when an enrichment provider is down?

It should be wrapped independently so a failure marks that source unavailable and the run continues with what the other sources returned. Record which sources contributed to each record. Only fail the whole run when every source is unavailable.

What is a good enrichment coverage rate?

Above 90% on the fields you actually use is healthy for a waterfall. Below 70% means fixing enrichment before investing in anything downstream, since every later layer inherits the gap. Always segment by geography, because aggregate numbers routinely hide poor non-US coverage.

---

*NomiOS is RZLT's GTM and ABM engine. Point it at a target and get back finished, branded work built on a real read of that company.*

[See how NomiOS works →](https://nomios.rzlt.io)