what is waterfall enrichment

Waterfall enrichment is the practice of routing a contact or company record through multiple data enrichment providers **in sequence**, stopping only when the desired data field is successfully filled. Think of it like a waterfall: water flows over the first ledge, and whatever doesn't land there flows to the next, and the next, until the pool is full.

In GTM terms, you might configure it like this: first hit Apollo for a work email. If Apollo can't find it, pass the record to Clearbit. If Clearbit misses, try Datagma. If Datagma fails, fall back to Hunter.io. The moment any provider returns a valid result, the chain stops — you don't keep spending credits unnecessarily.

This matters because [no single data provider covers the entire addressable market](https://www.linkedin.com/posts/cashmere-ai_using-a-single-enrichment-provider-is-risky-activity-7431748435759845376-mHoh). Each vendor builds its database from different sources — web scraping, user contributions, licensing agreements, email verification partnerships — so their coverage maps overlap but are never identical. Apollo might have excellent coverage for US mid-market SaaS companies but thin coverage for European SMBs. ZoomInfo might excel at enterprise firmographics but miss direct-dial numbers for startups. Waterfall enrichment exploits these overlapping coverage gaps systematically.

The term 'waterfall' is borrowed loosely from waterfall project management (a sequential, phase-gated process), but the mechanics here are purely about **priority ordering** and **conditional fallback logic**. You define the order. You define the fields. You define the stopping condition.

Common use cases where waterfall enrichment is deployed: - Enriching inbound leads before they route to an SDR - Filling phone numbers on a list of target accounts - Appending technographic data to ICP accounts at scale - Cleaning and re-enriching a decaying CRM database

Here's a concrete walkthrough of how a waterfall enrichment workflow operates in practice:

**Step 1: Define your target fields.** Decide which data points you need filled — typically work email, direct dial, LinkedIn URL, job title, company headcount, and tech stack. This determines which providers you need in your chain, since each has different field-level strengths.

**Step 2: Rank your providers by priority.** Order providers based on your experience with match rate, data quality, and cost per successful hit. If Apollo has a 65% match rate for your ICP at $0.02/hit and Clearbit has a 55% match rate at $0.05/hit, Apollo goes first.

**Step 3: Submit the record to provider #1.** The system sends the available identifiers (name, company domain, LinkedIn URL) to the first provider's API.

**Step 4: Evaluate the response.** If the provider returns a confident, verified match for the target field — stop the chain for that field. Write the result to your CRM or data warehouse.

**Step 5: Escalate to provider #2 on failure.** If provider #1 returns nothing, a low-confidence score, or a bounced email, the record is automatically passed to the next provider in the sequence.

**Step 6: Repeat until filled or exhausted.** The record cascades through the chain until either (a) a valid result is found, or (b) all providers are exhausted and the field remains null.

**Step 7: Log the enrichment source.** Always capture *which* provider filled which field. This is critical for auditing data quality, managing compliance obligations, and calculating provider-level ROI over time.

**Real example:** You have a lead from a webinar — you know their name (Sarah Chen), company (Acme Corp), and LinkedIn URL. Your waterfall for email: Apollo → Clearbit → Hunter.io → Skrapp. Apollo finds her email in 0.3 seconds. Done. You used 1 Apollo credit. For the next lead, Apollo misses — you burn a credit, then Clearbit hits on attempt 2. Total: 2 credits to fill 1 email. You track this as a 'depth-2 match.'

Tools like **Clay** make this visual and no-code — you drag providers into a waterfall sequence and set field-level logic without writing API calls. For code-native teams, building this in Python using a provider priority array and a simple `for provider in chain: try:` loop is straightforward.

'Full enrich' typically refers to a **single-pass, single-provider enrichment** where you submit a list of records and a vendor returns every available data field they have on each contact in one shot. It's the 'all at once, from one source' approach — you bulk upload a CSV to ZoomInfo or Clearbit, and they fill what they have.

The key distinction:

| | Full Enrich | Waterfall Enrichment | |---|---|---| | **Providers** | One | Multiple (2–10+) | | **Process** | Single API call / batch | Sequential, conditional | | **Fill rate** | 40–70% typically | 75–95% achievable | | **Cost model** | Pay per record or flat subscription | Pay per attempt per provider | | **Speed** | Fast (batch) | Slightly slower (sequential) | | **Complexity** | Low | Medium to high |

In Apollo's interface, 'Full Enrich' is a specific button/action that tells Apollo to use **all available enrichment sources it has access to** — including its waterfall — to populate as many fields as possible on a contact. It's Apollo's branded name for their internal multi-source enrichment pass. When you click Full Enrich in Apollo, it may query several of Apollo's integrated data partners behind the scenes and consume credits accordingly.

For ops teams: use full enrich (single provider) when you need speed and simplicity for a well-covered market segment. Switch to waterfall enrichment when your single provider's fill rate drops below ~65% or when a specific high-value field (like mobile direct dials) is chronically unfilled.

Apollo.io has built waterfall enrichment directly into its platform, making it one of the most accessible entry points for teams new to multi-provider enrichment. Here's how it actually works:

**Apollo's waterfall mechanics:** When you enrich a contact in Apollo, the platform queries its own database first. If it doesn't find a result for a specific field, it can pass the request to third-party partner providers it has integrated. Each query — successful or not — consumes credits. This is the core mechanic most users misunderstand: **you pay credits per attempt, not per successful result**.

**Waterfall credits on Apollo:** Apollo uses a credit system where: - Each email enrichment attempt costs 1 credit (whether it succeeds or fails) - Direct dial attempts typically cost 2–5 credits depending on your plan - When the waterfall cascades to a secondary provider, that attempt also costs credits - Premium data (like mobile numbers sourced from specialty providers) may cost additional credits on top

This means a single contact enrichment that fails at provider #1, partially succeeds at provider #2, and fully succeeds at provider #3 could cost 3–7 credits total. Budget accordingly.

**Enabling/disabling waterfall in Apollo:** In Apollo's settings, you can configure which data sources are included in enrichment requests. Enterprise plans allow more control over provider sequencing. If you want to limit credit burn, you can disable the cascade to third-party providers and restrict enrichment to Apollo's native database only — useful when you're doing bulk enrichment of a large, cold list where you expect low match rates.

**What happens when a provider fails in Apollo:** Apollo logs the failure silently and either moves to the next provider (if waterfall is enabled) or marks the field as unavailable. You won't get an explicit error notification per contact — so always audit fill rates post-enrichment rather than assuming the job completed successfully.

**Pro tip for Apollo users:** Run enrichment on a test batch of 50–100 contacts first. Calculate your actual cost-per-filled-field before running against a list of 10,000. The math changes significantly depending on how cold or niche your ICP is.

The choice isn't always waterfall. Here's when each approach makes more sense:

**Choose single-provider enrichment when:** - Your ICP is a well-covered market (US enterprise SaaS, Fortune 1000) where one provider like ZoomInfo or Apollo has 70%+ fill rates - Speed is paramount — batch enrichment through one API is 3–5x faster than sequential multi-provider calls - You're operating under strict data compliance requirements and need to minimize third-party data processors (each provider in your chain is a separate data processor under GDPR) - You're early-stage and need to minimize tooling complexity and cost

**Choose waterfall enrichment when:** - Your fill rate from a single provider consistently falls below 65% - You're prospecting into niche, international, or SMB markets where no single provider has deep coverage - Specific fields (mobile dials, direct emails) are critical to your outreach and chronically unfilled - You have a RevOps or GTM engineering resource to maintain the workflow

**The parallel enrichment alternative:** Some newer platforms (ZoomInfo's GTM Studio, for example) are experimenting with **parallel enrichment** — querying multiple providers simultaneously rather than sequentially, then selecting the highest-confidence result. This is faster than waterfall but more expensive (you pay for all attempts, not just until a hit). It also produces better results for confidence scoring since you can cross-validate signals across providers. Parallel enrichment is still nascent but worth watching for high-volume, data-quality-sensitive operations.

**Cost comparison example:** Single provider at $0.03/record × 10,000 records = $300, with 60% fill rate = 6,000 filled records at $0.05 effective cost each. Waterfall at average 2.3 attempts × $0.02/attempt × 10,000 records = $460, with 85% fill rate = 8,500 filled records at $0.054 effective cost each. The waterfall costs 53% more in total but delivers 42% more filled records — typically worth it if those records convert.

**Genuine pros:** - **Higher fill rates** — chaining 3–5 providers routinely pushes fill rates from 60% to 85%+, directly impacting pipeline generation and outreach deliverability - **Reduced single-vendor dependency** — [relying on one provider is genuinely risky](https://www.linkedin.com/posts/cashmere-ai_using-a-single-enrichment-provider-is-risky-activity-7431748435759845376-mHoh); vendors sunset products, change APIs, or lose data partnerships with no warning - **Optimizable over time** — because you track which provider fills which field, you can continuously improve your chain ordering based on real performance data

**Genuine cons — the ones vendors don't advertise:** - **GDPR/CCPA compliance complexity:** Each provider in your chain is a separate data processor or data controller. Under GDPR, you may need a Data Processing Agreement (DPA) with each one, and chaining providers means personal data flows through multiple third-party systems. For enterprise buyers selling into the EU, this isn't theoretical — it's a real audit risk. Audit your chain for DPAs before deploying at scale. - **Data inconsistency:** Provider A might return 'VP of Sales' for a contact while Provider B (queried later for a different field) returns 'Head of Revenue.' If your enrichment logic isn't field-level-isolated, you can end up with mismatched, internally contradictory records. - **Credit/cost accounting is difficult:** When credits span 3–4 vendors, each with different pricing models (credits, per-record, API calls, subscription tiers), accurately calculating true cost-per-enriched-contact requires dedicated tracking infrastructure. - **Maintenance burden:** Provider APIs change. Rate limits shift. A provider gets acquired. Your waterfall can silently break at any step, leading to undetected fill rate degradation.

Here's a neutral breakdown of the major platforms, since no single tool is universally best:

**Clay** — The most flexible waterfall enrichment platform for GTM engineers and growth ops. Connects to 75+ data providers through a no-code interface. You build waterfall logic visually, set field-level conditions, and Clay handles API orchestration. Pricing is credit-based and can get expensive at scale, but the flexibility is unmatched. Best for teams who want full control over their enrichment stack.

**Apollo.io** — Built-in waterfall enrichment with a native database plus third-party integrations. Best for teams already in the Apollo ecosystem who want enrichment without managing a separate tool. Less transparent about which providers it uses internally. Credit model requires careful monitoring.

**FullEnrich** — Purpose-built waterfall enrichment focused specifically on email and phone. Simple API, straightforward pricing, good fill rate claims (80%+ for email). Less customizable than Clay but easier to deploy. Good for teams that just need email/phone and don't need a full data platform.

**ZoomInfo** — Excellent single-provider fill rates for enterprise/mid-market US companies. Their GTM Studio product is adding parallel enrichment capabilities. Expensive, and GDPR compliance for EU prospecting requires careful setup. Better as anchor provider #1 in a waterfall than as a standalone solution for niche markets.

**Cognism** — Strong GDPR compliance positioning, particularly for European markets. Diamond Data (phone-verified mobiles) is a genuine differentiator for direct dial fill rates. Less strong for US SMB. Good to include in a waterfall chain specifically for EU contacts.

**Datagma / Prospeo / Skrapp / Hunter.io** — Lightweight, API-first providers that work well as later-stage fallbacks in a Clay or custom waterfall. Cheaper per-call cost makes them good for the bottom of the chain where you're chasing the remaining 15–20% fill rate gap.

**Decision framework:** Start with the provider that covers your core ICP best. Add 2–3 specialty providers for your gap fields (especially mobile dials and international contacts). Build in a scraping-based fallback (via Clay's Claygent or a custom LinkedIn scraper) as a last resort.

Here's a practical build path for a RevOps team that wants waterfall enrichment without six months of engineering work:

**Step 1: Audit your current fill rates.** Pull your CRM and calculate field-level fill rates for email, phone, title, company size, and industry. This establishes your baseline and tells you which fields need the waterfall most urgently. If email fill rate is 72% but phone is 34%, prioritize building the phone waterfall first.

**Step 2: Select your anchor provider.** The anchor is the first provider in your chain — the one with the best match rate for your specific ICP. Run a 200-record test against 2–3 candidates with known identifiers and measure match rate and field accuracy. Don't assume Apollo or ZoomInfo is best for your ICP — test it.

**Step 3: Identify your gap-fill providers.** For the records your anchor misses, which providers have complementary coverage? Check Datagma for European contacts, Hunter.io for verified work emails, Cognism for phone-verified mobiles. Add them to the chain in order of match rate on your test set.

**Step 4: Build in Clay or via API.** Clay's waterfall feature lets you set this up in under 2 hours for a basic chain. If you have API access and a developer, building this in Python or Node is viable — use a priority list, iterate through providers, break on a valid result, write source metadata to a separate field.

**Step 5: Instrument your tracking.** For every enrichment run, capture: records attempted, records enriched per field, provider that filled each field, credits/cost per provider, and total cost-per-enriched-contact. Without this, you're flying blind.

**Step 6: Set a re-enrichment cadence.** Contact data decays at roughly 22–30% per year. Schedule re-enrichment on your CRM contacts every 6 months. Run the waterfall only on contacts where key fields are null or last enriched >180 days ago to avoid wasting credits on fresh data.

**Step 7: Review and optimize quarterly.** Check provider-level fill rates and adjust chain order if a provider's performance has shifted. Providers change their databases, pricing, and APIs frequently.