ON THIS PAGE
By Efe Berke Colaker, Founder at GetleadReviewed by the Getlead editorial team for accuracy. Last updated August 2026.
Every enrichment provider misses records. Their coverage overlaps heavily in the obvious segments and diverges at the edges, which is exactly where the accounts you care about tend to sit.
The waterfall exists because of that divergence. Ask one provider, take the answer if it is usable, and only pay the next one for the records still missing.
How a waterfall actually runs
The mechanism is a loop with an exit condition, and the exit condition is where most implementations go wrong.
- Send the record to provider one with the fields you already hold.
- If the response meets your acceptance rule, stop and write it.
- If not, send the same record to provider two, and so on down the list.
- After the last provider, mark the record as unenriched rather than guessing.
- Verify every address the waterfall produced, regardless of which provider supplied it.
An acceptance rule is the test a response has to pass before the waterfall stops, and accepting any non empty answer is the most expensive mistake available here.
For example, a provider returning info@example.com technically answered the query. Accepting it stops the waterfall, skips the provider who would have returned a named contact, and puts a shared inbox into your campaign.
Ordering the providers
Sort by cost per successful match on your own data, which is rarely the same as sorting by list price.
Position one is the one teams skip. Most databases already hold a colleague at a meaningful share of target accounts, and that record answers both the address format and the account context for free.
For example, a 5,000 record list run against an internal check first often resolves several hundred rows before any paid call is made, and those rows come with history the providers do not have.
Verification belongs at the end, not the start
An enriched address is a claim from a vendor. Verification is the only step that turns it into evidence about a mailbox, and it has to run after the waterfall rather than inside it.
Our verification of 383,368 raw B2B addresses returned 43.4% confirmed valid, 23.9% invalid and 16.7% catch-all. Enriched data behaves the same way: some of it is current, some of it describes a person who left, and only a probe distinguishes the two.
Running verification once at the end also avoids paying for the same check repeatedly. If each provider verifies its own output, a record that passes through three providers is checked three times and billed three times.
The accounting that tells you when to stop
A waterfall grows by accretion until somebody measures it. Two numbers per provider settle the question.
- Incremental match rate. The share of records this provider resolved that nobody above it resolved. This is the only match rate that matters in a waterfall.
- Cost per incremental verified record. Provider spend divided by the records it uniquely contributed that later passed verification.
- Time cost. Each additional hop adds latency, which matters when enrichment runs inside a live workflow.
- Acceptance rule violations. How often this provider returns technically valid but useless answers such as role addresses.
For example, a provider with a headline 70% match rate might contribute only 4 points of incremental coverage in position three, because the two above it already resolved almost everything it knows. Its real price is the whole invoice divided by those 4 points.
Cut providers that add under a few points of verified incremental coverage. The saved budget usually buys more value as verification frequency or as fresher sourcing.
The provenance problem a waterfall creates
Sequential enrichment mixes sources inside one record, which is convenient for coverage and awkward for accountability.
Store which provider supplied each enriched field, not just that the record was enriched. Without it, a record with a name from one source, a title from another and an address from a third has no traceable origin at all.
That matters practically as well as legally. When one provider turns out to be returning stale titles, per field provenance lets you fix the affected records instead of re-enriching everything, and where recipients are in the EU, Article 14 of the GDPR expects you to be able to say where personal data came from.
Sources and method
First-party data (Getlead, 2026): the verification split of 43.4% confirmed valid, 23.9% invalid, 16.7% catch-all and 16.0% unknown comes from 383,368 addresses analyzed through live SMTP verification, and the 0.51% bounce rate comes from 34,973 tracked sends, aggregated and anonymized at campaign level. Full method in our cold email benchmark study.
External sources: notice obligations when personal data is obtained from a third party are set out in Article 14 of the GDPR; US commercial email requirements come from the FTC CAN-SPAM compliance guide; contact decay of about 2.1% a month comes from the HubSpot database decay model built on MarketingSherpa research.
Provider match rates vary by segment and geography, so the ordering above should be tested on your own data rather than assumed. Figures were checked in August 2026.
Frequently asked questions
What is a data enrichment waterfall?
A sequence of enrichment providers queried one after another, stopping at the first response that meets your acceptance rule. Because you only pay the next provider for records still missing, coverage rises without paying every provider for every record.
How should I order enrichment providers?
By cost per successful match on your own data. Start with your existing database and CRM history, which is free and highest trust, then your primary provider on your core segment, then a regional or vertical specialist, then a cheap high volume source for the remainder.
What is an acceptance rule?
The test a provider response must pass before the waterfall stops. Accepting any non empty answer is the common mistake, because a role address like info@ technically answers the query while skipping the provider who would have returned a named contact.
Should I verify before or after enrichment?
After. An enriched address is a vendor claim until a mail server confirms it, and running verification once at the end avoids paying for the same check at each hop in the waterfall.
How do I know when to cut a provider?
Measure incremental match rate, meaning the records that provider resolved which nobody above it resolved, then divide its cost by the incremental records that later passed verification. Providers contributing under a few points of verified coverage are usually not worth their invoice.
Why store provenance per field?
Because a waterfall mixes sources inside one record. Per field provenance lets you correct only the records affected when a provider turns out to be returning stale data, and it is what allows you to say where personal data came from if asked.