El enriquecimiento en cascada consiste en pedirle el mismo dato a varios proveedores en un orden fijo y detenerse en el primero que responde. Quieres el email de trabajo de un contacto: se consulta al proveedor uno y, si no devuelve nada, la petición cae al proveedor dos, luego al tres, hasta que alguno devuelve un resultado o se acaba la lista. La documentación de Clay para su waterfall de email de trabajo lo describe como una cascada por proveedores en secuencia, “stopping as soon as one returns a valid result”. El resultado es una sola columna con una tasa de llenado mucho más alta que la que produce cualquier proveedor por sí solo.
No es un proveedor de datos, y no mejora los datos de ningún proveedor. Un waterfall es lógica de enrutamiento sobre proveedores que ya estás pagando: sube la cobertura, no la exactitud. Tampoco es deduplicación ni verificación: la cascada decide a quién preguntar, y con gusto te entregará una dirección sintácticamente correcta en una empresa que rebota todos los mensajes. Tratar una celda llena como una celda validada es el error más caro de este patrón, y es la razón por la que un waterfall y un paso de verificación son dos partidas distintas.
Cómo corre la cascada en realidad
Tres ajustes determinan si un waterfall ahorra dinero o lo quema.
El orden. Los proveedores corren en la secuencia que tú definas, así que el proveedor más barato con una tasa de acierto decente en tu segmento va primero. Un orden copiado de una plantilla es un orden afinado para el ICP de otra persona.
La condición de parada. La cascada se detiene con el primer resultado aceptable. Qué cuenta como aceptable es configurable: Clay expone estrategias de validación Conservative, Balanced, Aggressive y Advanced para su waterfall de email, y un toggle para que el waterfall “only accepts an email if the validation provider explicitly confirms it as valid”. Si lo aprietas, gastas más créditos por fila; si lo aflojas, gastas menos créditos y más reputación de envío.
Las condiciones de entrada. Toda plataforma de enriquecimiento tiene una compuerta que decide qué filas entran siquiera a la cascada. En Clay es la fórmula “Only run if” en la configuración de ejecución. Las filas que no cumplen la condición nunca llaman a un proveedor, y esa es la palanca más grande sobre la factura.
Un diagnóstico útil: si tu waterfall sigue llamando proveedores después de que volvió un resultado, el resultado está fallando la compuerta de validación, no la búsqueda. Eso es una señal de calidad de datos sobre un proveedor, no un bug.
Dos medidores, no uno
Las plataformas de enriquecimiento suelen cobrar por dos ejes separados, y confundirlos es la forma en que se desvían los presupuestos. Clay mide actions —los pasos que ejecuta tu tabla— y data credits, que compran registros en su marketplace de proveedores. Revisado el 2026-08-07, el plan Free incluye 500 actions y 100 data credits al mes; Launch arranca en $167/mes por 15.000 actions al mes; Growth arranca en $446/mes por 40.000 actions al mes, con compromisos anuales que van desde 180.000 actions al año a $54/mes hasta 1,2 millones al año a $261/mes. Los waterfalls multiproveedor están disponibles desde Launch hacia arriba.
La regla de cobro importa más que el plan. Clay declara que “if an enrichment returns no result, you’re not charged Data Credits or Actions”, y que traer tus propias API keys de proveedor evita los data credits por completo. Es decir: fallar suele ser gratis y acertar no, lo cual invierte la intuición con la que empieza la mayoría de los equipos. Tu factura la determina para cuántas filas encontraste datos, no cuánto buscaste.
Cuánto cuestan las unidades en realidad
Los precios unitarios publicados hacen concretos los trade-offs. FullEnrich, un waterfall dedicado que corre 25+ fuentes, vende su plan Pro a $55/mes por 1.000 créditos —$0,055 por crédito— y cobra un email de trabajo a 1 crédito, un email personal a 3 y un número de celular a 10.
Lee esa lista de precios dos veces. Un número de celular cuesta lo mismo que diez emails de trabajo. Un armado de listas que activa en silencio el enriquecimiento telefónico en cada fila no es 10% más caro que uno solo de email; con tasas de acierto iguales es aproximadamente un orden de magnitud más caro por contacto alcanzado.
Ahora pon la verificación al lado. MillionVerifier lista 50.000 verificaciones de email por $89 —$0,00178 cada una— con créditos que nunca vencen y verificación de catch-all incluida sin costo extra. Verificar una dirección cuesta cerca del 3% de lo que costó encontrarla. El paso que los equipos se saltan para ahorrar dinero es el que ya es casi gratis.
Haz el ejercicio con tus propios números: 5.000 filas, solo email de trabajo, a $0,055 por email encontrado. Mide primero tu tasa de acierto real sobre una muestra de 200 filas: ese único dato mueve el total más que cualquier elección de proveedor. Con una tasa de acierto del 60%, el enriquecimiento sale cerca de $165 y verificar los resultados agrega unos $5.
Puntos de cuidado, cada uno con su guardia
Re-enriquecer filas que ya tienes. El auto-update sobre una tabla que crece vuelve a correr la cascada sobre registros que ya traen el campo. Guardia: apaga el auto-update mientras construyes, condiciona la columna con un “Only run if” que exija que el campo esté vacío, y usa columnas de lookup para traer datos que ya están en tu CRM u otra tabla antes de pagarle a un proveedor por ellos.
Los créditos de teléfono devorando el presupuesto. Con una relación de 10:1 en créditos, las búsquedas de celular dominan el gasto mientras alimentan una motion de llamadas mucho más chica. Guardia: separa los teléfonos en un waterfall aparte, restringido a las cuentas que un humano realmente va a llamar este trimestre, nunca a la lista completa.
Tratar una celda llena como una celda entregable. Una dirección encontrada y nunca verificada es un rebote esperando a ser atribuido a tu dominio, y los rebotes cuestan reputación de envío en todas las secuencias que corres. Guardia: haz de la verificación una columna obligatoria aguas abajo del waterfall, y escribe una política explícita para los resultados catch-all —enviar, retener o derivar a otro canal— antes de la primera campaña, no después.
Sin techo y sin visibilidad programática. Clay no tiene un endpoint público de API para el saldo de créditos; el uso vive en el dashboard de credit usage en Settings, desglosado por tabla, integración y periodo. No puedes alertar sobre un número que no puedes consultar. Guardia: asigna a una persona para revisar ese dashboard cada semana, limita cuántas filas puede procesar cada tabla, y prueba las configuraciones nuevas en 10 filas antes de correr la columna.
¿Vale la pena por lo que cuesta en créditos?
Sí, cuando la cobertura de contactos es la restricción que manda y el costo de un registro faltante es alto: outbound hacia un segmento donde un proveedor te llena la mitad de la lista, o una motion de ABM donde 300 cuentas nombradas tienen que estar completas. En esas condiciones una cascada es la cobertura más barata disponible, porque solo le pagas al proveedor que acierta.
No, cuando tu problema es de targeting y no de cobertura. Enriquecer una lista mal definida produce más contactos en cuentas de mal fit, más rápido, y los créditos se van igual. Arregla primero la definición de ICP y después enriquece. También es la herramienta equivocada cuando un solo proveedor ya cubre tu segmento al 80% o más: págale directo a ese proveedor y sáltate la capa de orquestación.
Para ver dónde encaja esto dentro de un programa de datos más amplio, mira estrategias de enriquecimiento de datos; para lo que pasa aguas abajo de una dirección mala, mira cómo mantener el cold email fuera de spam. Clay es la capa de orquestación habitual, mientras que Apollo y ZoomInfo son más seguido proveedores individuales dentro de la cascada de alguien más.