Run a list of 500 accounts through one data source and a chunk of it comes back empty. That part everyone expects. What surprises people is that the misses 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 data source, then a third, because each one is blind in a different place.
What waterfall enrichment means
An enrichment waterfall data source is a platform that buys from several data companies and runs them in sequence on your behalf, billing you once and stopping at the first one that returns an answer. The ones worth buying order the chain themselves and charge nothing when nobody answers. Oneprofile works that way.
Waterfall enrichment is a sequential lookup across a ranked list of data sources. You send a record with whatever match key you have, usually a name and a company domain, or an email. The first data source gets asked. If it returns nothing, the record moves down to the next one, and the run stops at the first data source that returns an answer. Everything below that step never gets called at all. Checking whether that answer is any good is a separate step, and it is the part most descriptions get wrong, so we will come back to it.
If you would rather watch a run than read about one, run a waterfall on a few of your own contacts and see which ones come back.
Two things this is not. It is not fanning the same request out to ten data sources at once and picking a winner, which costs ten lookups and needs a tiebreak rule nobody wants to write. It is also not multi-source 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 run works, step by step
There are three moving parts: a ranked data source chain, a stop condition, and a check that runs after the chain is done.
The stop condition is simpler than most descriptions make it sound. The run stops at the first data source that returns an answer. It does not grade that answer first, so whatever the first answering data source sends back is what you get. That is why checking the address is its own step.
The check is the piece most descriptions skip, or fold into the chain as if it happened between the rungs. For a work email, the address gets tested 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. In Oneprofile the check is Verify email, a separate enrichment with its own price. Point it at the column Find work email fills, and a new contact runs both, one after the other.
Here is roughly where answered contacts land in a well-ordered chain. These are the shares we plan with before a chain has a history of its own, which is a more honest source than a coverage stat with no methodology behind it.
Step | What happens to the contact | Share of answered contacts |
|---|---|---|
First data source | Asked first, sees every contact | About 80% |
Second data source | Sees only what step one could not answer | About 10% more |
Third data source | Sees what the first two missed | About 9% more |
Every data source after that | Sees the genuinely hard contacts | About 1% |
No answer anywhere | Nothing resolves, nothing billed | Not in the shares above |
The shape matters more than the exact figures. Most contacts resolve on the first rung, so the bill for the whole operation leans on whichever data source sits there. That one fact drives most of the rest of this article.
Single data source vs a waterfall: how coverage compounds
Take 100 contacts and a data source that answers 70 of them. The 30 left over are the structurally hard ones, not a random remainder.
A second data source 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 contacts are the entire case for a waterfall, and they are usually the accounts you most wanted to reach.
Then it flattens. By the fourth data source each extra rung finds a contact or two, and you pay for them in latency on every hard contact. Length is not the goal. What matters is that the order stays right as data sources change, and that keeping it right is not your job.
Coverage is only half of the story anyway. The other half is deliverability, and an unchecked fill is worse than an empty field, because an empty field 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 keeps the first answer and never checks it will find you more addresses and cost you the domain you send from.
Configured data source 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 data sources into a list, decide who goes first, and then own that decision forever. Tools 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:
Accuracy on contacts like yours. A data source that answers often and wrongly costs you more than one that answers less often and right.
Live hit rate on contacts like yours. Not the tool's published coverage number. What that data source actually answered on your last thousand contacts.
Price per answer. Between two data sources that are equally good, the cheaper one should be asked first.
All three drift. Data sources 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. Ranking data sources on those numbers and stopping at the first 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. For most lookups, the data sources that test most accurate go first, then the ones winning the most of our recent contacts, then the rest cheapest first. The run stops at the first answer, and a lookup that finds nothing costs nothing. Checking the address is its own step beside the finder, so you choose which found addresses get verified before anything is sent. There is no chain to configure and nothing to re-tune when a data source's coverage moves.
One honest exception. If you have negotiated your own contract with a data source and you are paying for that volume whether you use it or not, you want that data source first regardless of what the numbers say. That is a real reason to want manual control, and it is roughly the only one 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 data source, with the buyer building the chain. Every rung has its own credit price, so what a contact costs depends on who answered it, and on a chain you assembled, that is a choice you made. Sources for the same field are priced very differently: in our own work email chain the dearest source costs 25 times the cheapest. The buyer picks, and picking badly costs more than choosing the wrong platform ever would.
The second is per data source too, but the platform builds the chain and shows you the most a lookup can cost before you run it. Ours works that way. A contact is charged the price of the data source that answered it, up to the most the lookup shows, and a lookup that finds nothing costs nothing. Beside that figure, the run shows what a contact usually costs, read from which data sources have been answering.
Here is what that looks like for one work email, with prices from our catalog as repriced on October 15, 2026:
Step | What it does | Price per contact |
|---|---|---|
Find work email | Asks sources in order and keeps the first address | Up to 10 credits |
Verify email | Checks that the address is deliverable | Up to 0.8 credits |
Found and verified | Both steps on one contact | Up to 10.8 credits, or $0.216 at $0.02 a credit |
A contact that falls through to an expensive source costs more than one the first data source found, and you can see how much more before the run starts. What you never get is a bill for the contacts nobody could find.
Anyway, the pricing model is downstream of the mechanism. A platform that picks the data source can tell you the most a lookup will cost before you run it. 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.
Is checking the address a separate, visible step? You should be able to see which addresses were checked, what the check said, and what it cost, rather than take "verified" on trust.
Does it resolve field by field? If a data source returns an email but no phone, the contact should keep going for the phone alone instead of being marked complete.
Can you see what a run cost against what it could have cost? The most a run can cost should be on screen before it starts, and the real spend after it ends. Without both there is nothing to audit.
Are misses billed? They should not be. Ask before you buy: a platform that charges for a null response is telling you something about the rest of its billing.
Who maintains the ordering as hit rates drift? If the answer is you, budget for it. Someone has to notice that the data source sitting first stopped being the best way to resolve a contact, 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 data source chain, however well ordered, knows what an account pays you, what it complained about last week, or whether it quietly stopped logging in. That data comes out of your own billing, support, and product tools, and it belongs alongside the data your data sources find. 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 fills in a field automatically. Add it to a workspace pointed at your CRM, check what the run will spend before you start it, and let the platform order the data sources. The free plan renews 200 credits a month, which covers at least 18 found and verified work emails at the most each can cost, and usually more. Find and verify the first ones on your own list free.
