Waterfall Enrichment: Provider Order and Stop Rules

Order enrichment providers by expected cost per accepted record on your segment, not by list price, and stop the waterfall the moment the next stage's marginal cost exceeds what a resolved field is worth to you. That single rule, applied per field, is the difference between waterfall enrichment as a disciplined cost curve and waterfall enrichment as a way to pay three vendors for the same unresolved rows.

Waterfall enrichment is the practice of sending unresolved fields through a sequence of providers, where each stage only attempts records the previous stages failed to fill. Several platforms support this pattern, including Clay's waterfall enrichment, which sequences providers against unresolved fields without guaranteeing completeness. The mechanics are simple. The economics are where teams get it wrong, because the cost per record typically climbs at each stage, and it is easy to run a waterfall for months without ever computing it.

The number that matters: marginal cost per accepted record

Every stage in a waterfall has three rates that determine whether it earns its place:

1. Fill rate: the share of attempted records where the provider returns a value.
2. Acceptance rate: the share of returned values that pass your verification checks.
3. Marginal cost per accepted record: stage cost divided by the count of verified, accepted fills at that stage.

The first stage in a waterfall sees the easiest records, because the population still includes every company with a strong web footprint and every contact with a common, findable identity. Later stages inherit the residue: stale domains, recently changed roles, small companies with thin footprints. So the same provider that fills 60 percent as stage one might fill 15 percent as stage three. Provider order is not a fixed ranking of vendors. It is a ranking of expected performance on the specific residue each stage will receive.

This is why comparing providers on headline match rates from their own marketing is a category error. The match rate worth trusting is the one measured on your segment, at the position in the waterfall where the provider will actually run.

Worked example: 100 records through three stages

Illustrative example with round numbers. Suppose you start with 100 records missing a verified work email, and you run three providers in sequence.

The blended cost of $0.4375 per filled record looks fine. The marginal cost tells a sharper story: stage C's records cost $1.50 each, seven and a half times stage A's $0.20. Whether stage C belongs in the waterfall depends entirely on what a resolved record is worth in this workflow. For a high-value account segment, $1.50 is trivial. For a broad prospecting sweep, it may be the point where the waterfall should stop and the 20 unresolved records should be parked instead.

Now add verification. Suppose stage C's 10 fills go through mailbox verification and only 8 pass. The stage's cost per accepted record is $15 / 8 = $1.875, and the blended figure across all stages moves too if A and B also lose some fills at verification. The verified-and-accepted count is always equal to or smaller than the raw fill count, so marginal cost per accepted record is always equal to or higher than marginal cost per fill. Budget against the accepted number, not the fill number.

One caution on verification itself: mailbox verification estimates whether an address is likely to accept mail and can come back inconclusive; it is not proof of delivery or inbox placement, not confirmation the person still holds the role, and not permission to contact them. Verification narrows risk; it does not eliminate it.

Stop rules: when the waterfall should quit

A waterfall without stop rules degrades into paying every provider for the hardest residue on every run. Three families of stop conditions are worth defining up front.

Value stops. Set a ceiling on marginal cost per accepted record for each field and segment. When the next stage's expected cost exceeds the ceiling, the record exits the waterfall and gets tagged unresolved. In the example above, a $1.00 ceiling would remove stage C for the broad segment while keeping it for named accounts.

Repeat stops. If a field was attempted by a given provider within a cooling window, say the last 60 or 90 days, skip that provider. Data providers refresh on cycles, and re-querying the same source weekly for the same unresolved field buys the same miss repeatedly. Track attempts per field per provider with timestamps so the skip is automatic rather than tribal knowledge.

Signal stops. Some misses are informative. A record that fails verification at two stages, especially providers with distinct upstream sources, is a hint that the identity itself may be stale: the person changed roles, the domain moved, the company was acquired. Route those records to a re-discovery step that re-verifies who currently holds the role, rather than a fourth email-finding attempt against an identity that no longer exists. This is where an objective-driven approach helps: AstroFabric's agents for waterfall data enrichment can treat repeated verification failure as a trigger to re-discover the person or account, not just retry the field.

Note that these are operational policies you define and own. Adopting a platform that supports waterfalls does not make the stop rules appear on their own, and the residue file, the ceilings, and the cooling windows remain your team's responsibility to review.

Track provenance or lose the ability to debug

When a downstream rep asks why a record shows a particular email, you need to answer with which provider supplied it, at which stage, on which date, and what verification it passed. A lightweight field ledger handles this: for each filled field, store the source, the stage position, the timestamp, the verification result, and the run ID. This mirrors the structure of the W3C PROV-O model, which separates the entity (the value), the activity (the enrichment run), and the responsible agent (the provider); the ledger here is an illustrative implementation of that idea, not a standards certification.

The ledger shows its value when a provider's quality slips. Without per-stage provenance, a bad batch from stage B contaminates your dataset invisibly. With it, you can identify, quarantine, and re-run exactly the affected fields. See the data provenance glossary entry for the broader concept, and the data enrichment glossary entry for how enrichment fits the wider data layer.

Tradeoffs and failure handling

Longer waterfalls raise coverage and latency together. Each stage adds wall-clock time and another dependency that can rate-limit or fail. For real-time flows, cap the waterfall at the stages that meet your latency budget and push deeper stages to an async pass.

Provider overlap wastes spend. Two providers drawing on similar upstream data tend to fill nearly the same records. If stage B's incremental fill rate on stage A's residue is very low, the overlap is high and B should be replaced or reordered, not tuned.

Residue is not garbage. The 20 unresolved records in the example are candidates for periodic retry after provider refresh cycles, for human research if the accounts are high value, or for removal if scoring says they were marginal targets anyway. Pair the residue review with your lead scoring so effort follows value.

Order is segment-specific. A provider strong on North American mid-market may be weak on European SMB. If your dataset spans distinct segments, measure fill and acceptance rates per segment and let the waterfall order differ by segment rather than forcing one global sequence.

FAQs

Should the cheapest provider always run first? No. Order by expected cost per accepted record on your segment. A cheap stage with a poor acceptance rate can cost more per usable record than a pricier stage that fills reliably, and it burns a waterfall position on easy records a better provider would have resolved anyway.

When should the waterfall stop trying a record? When the next stage's marginal cost exceeds the field's value for that segment, when every remaining provider was attempted inside the cooling window, or when repeated verification failures suggest the identity is stale and the record needs re-discovery instead of another fill attempt.

Is a filled field the same as a verified field? No. A fill is a returned value; verification is an independent check the value passes. Measure providers on verified-and-accepted output. And treat mailbox verification for what it is: an estimate of whether an address is likely to accept mail, not identity confirmation, permission, or intent.

Next step

Take your last enrichment run, compute cost per accepted record at each stage, and set one marginal cost ceiling per segment. If you want autonomous agents to run enrichment against your stop rules and deliver records with source and verification metadata into your existing systems, start with AstroFabric.

Sources

• Clay waterfall enrichment
• W3C PROV-O