Waterfall enrichment é pedir o mesmo campo a vários fornecedores de dados numa ordem fixa e parar no primeiro que responder. Você quer o email de trabalho de um contato: o fornecedor um é consultado e, se não devolver nada, a requisição cai para o fornecedor dois, depois o três, até alguém devolver um resultado ou a lista acabar. A documentação da Clay para o waterfall de email de trabalho descreve isso como uma cascata pelos fornecedores em sequência, “stopping as soon as one returns a valid result”. A saída é uma única coluna com uma taxa de preenchimento muito maior do que qualquer fornecedor produz sozinho.
Não é um fornecedor de dados, e não melhora o dado de fornecedor nenhum. Um waterfall é lógica de roteamento sobre fornecedores que você já paga: aumenta cobertura, não acurácia. Também não é deduplicação nem verificação: a cascata decide para quem perguntar, e vai te entregar de bom grado um endereço sintaticamente correto numa empresa que devolve todas as mensagens. Tratar uma célula preenchida como uma célula validada é o erro mais caro desse padrão, e é a razão de o waterfall e a etapa de verificação serem duas linhas de custo diferentes.
Como a cascata roda de verdade
Três configurações determinam se um waterfall economiza dinheiro ou queima dinheiro.
A ordem. Os fornecedores rodam na sequência que você definir, então o fornecedor mais barato com uma taxa de acerto decente no seu segmento vem primeiro. Ordem copiada de um template é ordem calibrada para o ICP de outra pessoa.
A condição de parada. A cascata para no primeiro resultado aceitável. O que conta como aceitável é configurável: a Clay expõe as estratégias de validação Conservative, Balanced, Aggressive e Advanced no waterfall de email, e um toggle para que o waterfall “only accepts an email if the validation provider explicitly confirms it as valid”. Apertando isso, você gasta mais créditos por linha; afrouxando, gasta menos créditos e mais reputação de envio.
As condições de entrada. Toda plataforma de enriquecimento tem um portão que decide quais linhas sequer entram na cascata. Na Clay é a fórmula “Only run if” nas run settings. Linhas que não passam na condição nunca chamam um fornecedor, e essa é a maior alavanca isolada sobre a conta.
Um diagnóstico útil: se o seu waterfall continua chamando fornecedores depois que um resultado voltou, o resultado está falhando no portão de validação, não na busca. Isso é sinal de qualidade de dado sobre um fornecedor, não um bug.
Dois medidores, não um
Plataformas de enriquecimento costumam cobrar em dois eixos separados, e confundir os dois é como orçamentos são estourados. A Clay mede actions — os passos que a sua tabela executa — e data credits, que compram registros no marketplace de fornecedores dela. Verificado em 2026-08-07, o plano Free inclui 500 actions e 100 data credits por mês; o Launch começa em US$ 167/mês por 15.000 actions ao mês; o Growth começa em US$ 446/mês por 40.000 actions ao mês, com compromissos anuais indo de 180.000 actions por ano a US$ 54/mês até 1,2 milhão por ano a US$ 261/mês. Waterfalls multi-fornecedor estão disponíveis do Launch para cima.
A regra de cobrança importa mais do que o plano. A Clay declara que “if an enrichment returns no result, you’re not charged Data Credits or Actions”, e que trazer suas próprias API keys de fornecedor pula os data credits por completo. Ou seja: errar costuma ser de graça e acertar não, o que inverte a intuição com que a maioria dos times começa. Sua conta é determinada por para quantas linhas você encontrou dado, não por quanto você procurou.
Quanto as unidades custam de fato
Preços unitários publicados deixam os trade-offs concretos. A FullEnrich, um waterfall dedicado que roda 25+ fontes, vende o plano Pro a US$ 55/mês por 1.000 créditos — US$ 0,055 por crédito — e cobra 1 crédito por email de trabalho, 3 por email pessoal e 10 por número de celular.
Leia essa tabela de preços duas vezes. Um número de celular custa o mesmo que dez emails de trabalho. Uma construção de lista que liga silenciosamente o enriquecimento de telefone em toda linha não é 10% mais cara que uma só de email; com taxas de acerto iguais, é aproximadamente uma ordem de grandeza mais cara por contato alcançado.
Agora coloque a verificação ao lado. A MillionVerifier lista 50.000 verificações de email por US$ 89 — US$ 0,00178 cada — com créditos que nunca expiram e verificação de catch-all incluída sem custo extra. Verificar um endereço custa cerca de 3% do que custou encontrá-lo. A etapa que os times pulam para economizar é justamente a que já é quase de graça.
Faça a conta com os seus números: 5.000 linhas, só email de trabalho, a US$ 0,055 por email encontrado. Meça primeiro sua taxa de acerto real numa amostra de 200 linhas — esse único dado move o total mais do que qualquer escolha de fornecedor. Com 60% de acerto, o enriquecimento sai por volta de US$ 165 e verificar os resultados soma uns US$ 5.
Pontos de atenção, cada um com sua trava
Re-enriquecer linhas que você já tem. Auto-update numa tabela que cresce roda a cascata de novo em registros que já carregam o campo. Trava: desligue o auto-update enquanto constrói, condicione a coluna com um “Only run if” que exija o campo vazio, e use colunas de lookup para puxar dado que já está no seu CRM ou em outra tabela antes de pagar um fornecedor por ele.
Créditos de telefone engolindo o orçamento. Numa razão de 10:1 em créditos, buscas de celular dominam o gasto enquanto alimentam uma motion de ligação bem menor. Trava: separe telefones num waterfall próprio, restrito às contas que um humano vai de fato ligar neste trimestre, nunca a lista inteira.
Célula preenchida tratada como célula entregável. Um endereço encontrado e nunca verificado é um bounce esperando para ser atribuído ao seu domínio, e bounces custam reputação de envio em todas as sequências que você roda. Trava: torne a verificação uma coluna obrigatória a jusante do waterfall, e escreva uma política explícita para resultados catch-all — enviar, segurar ou mandar para outro canal — antes da primeira campanha, não depois.
Sem teto e sem visibilidade programática. A Clay não tem endpoint público de API para saldo de créditos; o uso fica no dashboard de credit usage em Settings, quebrado por tabela, integração e período. Você não consegue alertar sobre um número que não consegue consultar. Trava: dê a uma pessoa a responsabilidade de olhar esse dashboard toda semana, limite quantas linhas cada tabela pode processar, e teste configurações novas em 10 linhas antes de rodar a coluna.
Vale os créditos?
Vale quando cobertura de contato é a restrição que manda e o custo de um registro faltando é alto: outbound para um segmento onde um fornecedor preenche metade da sua lista, ou uma motion de ABM em que 300 contas nomeadas precisam estar completas. Nessas condições a cascata é a cobertura mais barata disponível, porque você só paga o fornecedor que acerta.
Não vale quando o seu problema é de targeting, não de cobertura. Enriquecer uma lista mal definida produz mais contatos em contas de fit ruim, mais rápido, e os créditos vão embora do mesmo jeito. Conserte primeiro a definição de ICP e enriqueça depois. Também é a ferramenta errada quando um único fornecedor já cobre o seu segmento em 80% ou mais: pague direto esse fornecedor e pule a camada de orquestração.
Para ver onde isso entra num programa de dados mais amplo, veja estratégias de data enrichment; para o que acontece a jusante de um endereço ruim, veja como manter cold email fora do spam. Clay é a camada de orquestração usual, enquanto Apollo e ZoomInfo são mais frequentemente fornecedores individuais dentro da cascata de outra pessoa.