What Is Waterfall Enrichment? How It Works

Run a list of 500 accounts through one data provider and a chunk of it comes back empty. That part everyone expects. What surprises people is that the empty rows are not a random sample: they pile up on non-US companies, on teams under 50 people, and on anyone who changed jobs last quarter. Waterfall enrichment is the answer the category settled on, and the logic is almost embarrassingly simple. Ask a second provider, then a third, because each one is blind in a different place.

What waterfall enrichment means

Waterfall enrichment is a sequential lookup across a ranked list of data providers. You send a record with whatever match key you have, usually an email, a company domain, or a LinkedIn URL. The first provider gets asked. If it returns nothing usable, the record moves down to the next one, and the run stops at the first result that passes verification. Everything below that step never gets called at all.

Two things this is not. It is not fanning the same request out to ten providers at once and picking a winner, which costs ten lookups and needs a tiebreak rule nobody wants to write. It is also not multi-provider enrichment in the loose sense of holding three subscriptions and checking them by hand.

The name is borrowed and, honestly, it is a bad one. The software industry spent a decade escaping waterfall as a way to build things, and now the word is back describing an unrelated pattern in the same buyer's stack. Data waterfall is the other phrase you will see. Neither tells you anything about the mechanism, which is a shame, because the mechanism is the interesting part.

How a waterfall enrichment run works, step by step

There are three moving parts: a ranked provider chain, a verification step between the rungs, and a stop condition.

The verifier is the piece most descriptions skip. A provider returning a syntactically valid address is not a result. In a waterfall email enrichment run, the candidate gets checked for syntax, for a live mail exchange record on the domain, and for whether the domain accepts everything sent to it. That last case is a catch-all, and it tells you nothing about whether the specific mailbox exists. A candidate that fails verification is treated exactly like an empty response. The row keeps moving.

Here is where rows actually land when the chain is ordered by cost. These are the shares we assume when we price our own operations, which is a more honest source than a coverage stat with no methodology behind it.

The shape matters more than the exact figures. Almost everything resolves on the first rung, so the cost of the entire operation is dominated by whichever provider sits there. That one fact drives most of the rest of this article.

Single provider vs a waterfall: how coverage compounds

Take 100 rows and a provider that answers 70 of them. The 30 left over are the structurally hard ones, not a random remainder.

A second provider that built its database differently, from job-board crawls rather than email-verification networks, might know ten of those 30. Now you are at 80. A third adds four or five more.

Those extra ten or fifteen rows are the entire case for waterfall enrichment, and they are usually the accounts you most wanted to reach.

Then it flattens. By the fourth provider you are paying latency on every hard row to gain one or two, and the marginal cost per row found gets ugly. Long chains are a vanity metric. We would take three well-ordered providers over fifteen in an arbitrary sequence, and we say that as people who read a provider bill every month.

Coverage is only half of the story anyway. The other half is deliverability, and an unverified fill is worse than a blank cell, because a blank cell never bounces. Gmail's bulk sender requirements put a number on the tolerance: keep spam complaints under 0.3% or delivery starts degrading. A chain that stops on any response rather than a verified one will find you more addresses and cost you the domain you send from.

Configured provider chains vs automatic waterfall ordering

Here is the part of the category we think is wrong.

Almost every tool that offers a waterfall hands you a builder. You drag enrichment waterfall providers into a list, decide who goes first, and then own that decision forever. Vendors treat configurable ordering as a feature, and their own beginner content quietly admits it is the step new users struggle with most.

Ordering is not a preference, though. It is an optimization problem with a correct answer, and the answer depends on three variables:

• Price per call. The provider that sees every row sets your cost floor.

• Live hit rate on rows like yours. Not the vendor's published coverage number. What that provider actually resolved on your last thousand rows.

• Verification pass rate. A provider that returns plenty of addresses that fail the verifier is worse than one that returns fewer and cleaner.

All three drift. Providers reprice, refresh their databases on different cadences, and lose ground in segments where they used to be strong. The chain you tuned in March is wrong by September, and no dashboard is going to tell you it went stale. Ordering by expected cost per resolved row and stopping at the first verified answer is a search problem with a known shape, close to optimal stopping in decision theory. Software is better at that than you are, and it never gets bored.

So we built ours to do the ordering itself. Cheapest capable provider first, ranked by live hit rate, verification between every step, stop on the first match, misses free. There is no chain to configure and nothing to re-tune when a provider's coverage moves.

One honest exception. If you have negotiated your own contract with a provider and you are paying for that volume whether you use it or not, you want that provider first regardless of what the numbers say. That is a real reason to want manual control, and it is roughly the only one we have heard that holds up.

What waterfall enrichment costs per match

There are two ways to price this, and they behave very differently.

The first is per provider. Every rung has its own credit price, so what a row costs depends on who answered it. The spread inside a single product can be enormous: the same mobile phone number runs 1 credit or 25 depending on which provider you put in the chain, and the same work email 0.2 or 6. That swing is wider than the gap between any two vendors in the category. The buyer picks, and picking badly costs more than choosing the wrong platform ever would.

Then there is one flat price per operation, whichever rung answers. Ours works that way. Finding a work email is 2.5 credits and verifying one is 0.3. A company enrichment from a domain is 0.8, a person enrichment from an email is 0.8, a mobile phone is 9.2. At $0.02 a credit that comes to $0.05 for a work email and $0.184 for a phone number. A row that falls all the way to an expensive specialist bills the same as one that resolved on the first try, and we absorb the difference, which works out because under 1% of rows get that far.

Where that leaves us depends entirely on which operation you run, so here is the honest version rather than the comparison-page one. Person enrichment and company-from-domain at $0.016 are the cheap end of this category, and verification at $0.006 sits on the floor. Work email at $0.05 is above the published range, and it happens to be the lookup most teams run by the thousand. What the flat price buys either way is one number that does not move based on routing you never did, a free miss, and the cost of a run shown before it starts.

Anyway, the pricing model is downstream of the mechanism. A platform that picks the provider can charge a flat rate. A platform where you pick cannot.

How to evaluate waterfall enrichment: five questions

Four of these are the standard checklist and the industry mostly agrees on them. The fifth is the one nobody asks.

1. Does verification sit between the steps, or only at the end? A run should advance on a failed verification exactly as it advances on an empty response.

2. Does it resolve field by field? If a provider returns an email but no phone, the row should keep going for the phone alone instead of being marked complete.

3. Can you see which provider answered? Per row, with what it cost and how long it took. Without that log there is nothing to audit and nothing to optimize.

4. Are misses billed? They should not be. Free failed lookups are table stakes in this category now, and a platform that charges for a null response is telling you something about the rest of its billing.

5. Who maintains the ordering as hit rates drift? If the answer is you, budget for it. Someone has to notice that the provider sitting first stopped being the cheapest way to resolve a row, pull the numbers, and re-rank the chain. If the answer is the platform, ask how often the ranking updates and on whose data.

That last question is what separates these tools once you have been running lists for six months. Coverage claims converge. Everyone lands in roughly the same place on a normal US list. The operational cost of keeping a chain correct is what you actually live with.

One more thing worth remembering while you shop. A waterfall only ever sees the outside of a company. No provider chain, however well ordered, knows what an account pays you, what it complained about last week, or whether it quietly stopped logging in. Those columns come out of your own billing, support, and product tools, and they belong in the same table as the provider columns. The full definition of data enrichment covers both source classes, and the categories of enrichment tools sorts out which kind of product does which.

In Oneprofile, a waterfall is just a column type. Add it to a table pointed at your CRM, check what the run will spend before you start it, and let the platform order the providers. Get started free.