No single data provider has everyone. Ask one for a work email or a mobile number and it will find some of your list and miss the rest. Buying a second provider and running the whole list through both doubles the bill for a modest gain.
A waterfall fixes that. It asks providers one at a time, in a set order, and stops at the first good answer.
How a waterfall works
For each row and each field you need:
- Ask the cheapest provider with decent coverage for that field.
- If it returns a result, validate it. An email gets checked for deliverability. A phone number gets checked for format and line type.
- If the result passes, stop. Write it to the row with the provider name and the date.
- If it fails or comes back empty, move to the next provider.
- After the last provider, mark the field as not found, so nobody pays to look again next week.
The order matters more than the provider list. Cheap and broad first, expensive and narrow last.
Why it costs less
You only pay the expensive provider for the rows the cheap ones missed. If the first provider finds half the list, the second only sees the other half, and the third sees what is left after that. The cost per found field drops, and coverage goes up, because each provider fills gaps the others leave.
The common mistake is running every provider on every row "to compare". That is a one-off test, not a pipeline.
Where waterfalls go wrong
- No validation step. A provider returns an email, the waterfall stops, and the email bounces. Validate before you stop, or the waterfall stops on bad data.
- No caching. The same contact gets enriched again next month because nobody recorded that it was done. Store the result, the source and the date, and only refresh after a set age.
- No budget per row. A single hard-to-find contact can run through eight paid providers. Cap the spend per row and per field.
- The wrong order for the market. Provider coverage varies by region and company size. A provider that is strong on US mid-market may be weak on UK startups. Order by what your own data shows, not by what the vendor says.
- Paying for fields you never use. If nobody calls mobiles, do not buy mobiles.
Clay or code
Clay is the fastest way to build and test a waterfall. You can try provider orders, see hit rates per column and change things in minutes. For a few thousand rows a month it is often the right answer.
At higher volume, or when the waterfall needs to run on a schedule against your CRM, the same logic moved into code (Python, your own API keys, a database table for the cache) usually costs less per row and is easier to monitor. The cost per row stays flat whether you run 500 rows or 8 million, because you pay providers directly instead of through credits.
The sensible pattern is both. Prove the order in Clay, then move the steady-state pipeline into code.
What to measure
- Coverage per field. Percentage of rows with a validated value.
- Cost per found field. Total spend divided by validated results, per field.
- Hit rate per provider, per position. Tells you when to reorder.
- Bounce rate on enriched emails. If this rises, a provider or the validation step has slipped.
Review the order monthly. Providers change, and a waterfall tuned in January is usually wrong by June.
The short version
Ask providers in order, cheapest first. Validate before you stop. Cache everything with a source and a date. Cap spend per row. Prove the order in Clay, run it in code at volume, and review the order every month.
I build enrichment waterfalls in Clay and in code, on your own keys, with caching and validation built in. Enrichment feeds the scores in signal data vs intent data. Book a 30-minute session and I will look at what your data is costing you now.
