Construcción de un pipeline de enriquecimiento de empresas B2B

El desafío

Estás construyendo un producto SaaS B2B. Tus clientes suben una lista de nombres de empresas. Esperan recibir un registro limpio: rango de ingresos, número de empleados, stack tecnológico, ronda de financiación, contactos clave, noticias recientes. Lo esperan en minutos, no en días. Y esperan que sea correcto.

Los datos existen. Viven en Crunchbase, en las páginas de "Acerca de" de las empresas, en las páginas de empresa de LinkedIn, en Google Maps, en Glassdoor, en registros comerciales regionales, en los archivos de TechCrunch. El problema es acceder a ellos de forma fiable.

Cada fuente se rompe de forma diferente. Crunchbase sirve una aplicación pesada en el lado del cliente que se vuelve a renderizar si sospecha de un bot. LinkedIn aplica rate limit de forma agresiva y cambia su DOM más rápido de lo que puedes parchear los selectores (un post popular de la comunidad evalúa un scraper básico en Python en unos 50 perfiles antes de que caiga el muro anti-bot). Los sitios web de las empresas van desde HTML estático hasta aplicaciones de una sola página que necesitan un navegador completo incluso para mostrar su contenido. Los directorios regionales rotan los diseños cada trimestre y se ocultan tras bloqueos específicos de país. Según un informe de la industria de 2026 de GroupBWT, del 10 a 15% de los crawlers en algunos verticales necesitan arreglos semanales solo para mantenerse al día con las actualizaciones anti-bot y los cambios del DOM.

Así que tu pipeline de enriquecimiento comienza como un diseño limpio de cinco fuentes. Seis meses después, es una maraña de scrapers medio rotos, colas de reintento y un canal de Slack llamado #scraper-alerts que ya nadie abre (hemos escrito sobre el coste oculto de mantener tus propios scrapers antes). Las quejas sobre la calidad de los datos se acumulan en tu cola de soporte. Tu equipo empieza a bromear diciendo que el nombre de la empresa debería haber sido "Cinco Scrapers y una Oración".

El enfoque

Olvida los scrapers por un minuto. La parte difícil del enriquecimiento no es la extracción. Es el enrutamiento: decidir qué fuente necesita qué herramienta, qué proxy, qué política de reintentos y qué cuenta como una response "buena".

Una plataforma como FourA te ofrece tres productos que se mapean directamente con las tres clases de fuentes a las que vas a acceder.

Directorios HTML estáticos y registros. La mayoría de los registros comerciales regionales y muchos directorios B2B antiguos se renderizan en el servidor. Quieren una request HTTP rápida y de baja sobrecarga desde una IP limpia. Eso es Single: entra una URL, sale una response. Añade unblocker: true y supera los bloqueos a nivel de handshake que detienen en seco a un cliente HTTP básico. Single enruta a través de Proxy Finder de forma automática y devuelve el id del proxy en el nivel superior de la response (r.proxy) para que tus llamadas de seguimiento puedan pasarlo de vuelta como proxy:"<id>" para mantener la misma salida cuando necesitas continuidad de sesión.

SPAs con mucho JavaScript. Crunchbase, las aplicaciones de estilo LinkedIn e incluso los sitios de empresas medianas no devolverán los datos que deseas de una response HTTP simple. Se renderizan en el cliente. Eso es Browser: un navegador completo ejecuta la página, corre el JS y te devuelve el HTML renderizado, las cookies y las capturas de pantalla. Al igual que Single, enruta a través de Proxy Finder bajo el capó (no hay un paso de selección separado por tu parte).

Fuentes mixtas con validación. Cada request a la API de FourA acepta un bloque validate. Puedes requerir códigos de estado específicos, coincidencias de header o coincidencias de subcadenas en el cuerpo. Si la response es un fallo leve (una página 200 con un CAPTCHA, un armazón de datos vacío o un intersticial de "lo sentimos"), el validador la rechaza. Tu pipeline puede entonces enrutar la misma URL a través de Browser. Esa única característica elimina la clase de error más costosa en el enriquecimiento: el fallo silencioso que escribe basura en tu base de datos.

Aquí tienes la forma de una llamada de fuente única:

curl -X POST https://api.foura.ai/api/single \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://registry.example.com/company/123",
    "unblocker": true,
    "followRedirects": 5,
    "validate": {
      "status": { "accept": [200] },
      "data":   { "fail":   ["captcha", "blocked", "access denied"] }
    }
  }'

Y el equivalente en Browser para un sitio de empresa con mucho JavaScript:

curl -X POST https://api.foura.ai/api/browser \
  -H "Authorization: Bearer pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

La lógica de enrutamiento reside en tu propio pipeline. La fiabilidad reside en el nuestro. Tú decides cuál de tus fuentes usa qué herramienta. Nosotros nos aseguramos de que la herramienta realmente logre pasar.

Resultados

Hemos visto a un puñado de equipos pasar de scrapers internos a un pipeline enrutado por FourA durante la beta pública. El patrón es consistente (números ilustrativos basados en lo que hemos visto en la cohorte de la beta):

• La latencia de enriquecimiento cae de 3 a 6 segundos por empresa a menos de 1.5 segundos de media en rutas residenciales en caché
• La tasa de fallos silenciosos (responses 200 con datos vacíos) cae de alrededor del 8% a menos del 1% una vez que el bloque validate atrapa los fallos leves antes de que lleguen a la base de datos
• El tiempo de ingeniería en el mantenimiento de scrapers cae de 1 a 2 ingenieros a tiempo completo a un canal de Slack que en su mayor parte permanece en silencio
• La tasa de éxito en el primer pase en directorios protegidos sube por encima del 90% cuando unblocker: true se empareja con un id de proxy limpio

Un número más que vale la pena señalar: hemos visto que la corrección del primer pase (datos correctos, empresa correcta) se queda atrás del éxito del primer pase en unos cuatro puntos. La lección no es que el scraping sea difícil. Es que todavía necesitas validar el registro contra la empresa que realmente pediste (escribimos sobre ese patrón en por qué tu web scraper se sigue rompiendo).

Los números que importan no son el tamaño del pool de proxies o el recuento de requests. Son la tasa a la que tu endpoint de enriquecimiento devuelve los datos correctos en el primer intento, y la pendiente de tu gráfico de mantenimiento de scrapers durante los próximos seis meses.

Conclusión clave

Los pipelines de enriquecimiento fallan a cámara lenta. El primer scraper que escribes se ve bien un martes. Para la tercera fuente, estás parcheando selectores a las 11 pm. Para la décima, arrastras una deuda de mantenimiento que escala con tu base de clientes. Para la vigésima, has dejado silenciosamente de incorporar nuevas fuentes porque nadie en el equipo quiere hacerse cargo de la siguiente.

El cuello de botella nunca fue la fuente. Fue el enrutamiento: elegir la herramienta correcta, el proxy correcto, la regla de validación correcta para cada URL, cada vez. Construye esa capa una vez, entrégala a algo que ya lo hace, y tu equipo podrá dedicar el martes al producto en lugar de clasificar roturas de selectores.