Construcción de un pipeline de enriquecimiento de empresas B2B

El desafío

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

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

Cada fuente falla de forma distinta. Crunchbase entrega una aplicación pesada del lado del cliente que vuelve a renderizar si sospecha de un bot. LinkedIn aplica rate limits agresivos y cambia su DOM más rápido de lo que puedes parchear los selectores (una publicación popular de la comunidad estima que un scraper básico en Python procesa unos 50 perfiles antes de que el sitio empiece a rechazarlo). Los sitios web de empresas van desde HTML estático hasta single-page apps que necesitan un navegador completo solo para mostrar su contenido. Los directorios regionales rotan sus layouts cada trimestre y restringen el acceso mediante bloqueos por país. Según un informe sectorial de 2026 de GroupBWT, del 10 al 15% de los crawlers en ciertos sectores necesitan ajustes semanales solo para seguir el ritmo de los cambios en la detección de bots y el desfase del DOM.

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

El enfoque

Olvídate de los scrapers por un momento. 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 respuesta "buena".

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

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

SPAs con uso intensivo de JavaScript. Aplicaciones como Crunchbase, plataformas al estilo de LinkedIn e incluso sitios web de empresas medianas no devolverán los datos que buscas a partir de una respuesta HTTP simple. Renderizan en el cliente. Para eso está Browser: un navegador completo ejecuta la página, procesa el JS y te entrega el HTML renderizado, cookies y capturas de pantalla. Al igual que Single, se enruta a través de Proxy Finder internamente, sin un paso de selección adicional por tu parte.

Fuentes mixtas con validación. Cada request a la API de FourA admite un bloque validate. Puedes exigir códigos de estado específicos, coincidencias de encabezados o subcadenas en el cuerpo. Si la respuesta es un fallo silencioso (un 200 que solicita verificación, una estructura de datos vacía o una pantalla de aviso de tipo "lo sentimos"), el validador la rechaza. Tu pipeline puede entonces enrutar la misma URL a través de Browser. Esa sola funcionalidad elimina el tipo de error más costoso en el enriquecimiento: el fallo silencioso que escribe datos corruptos en tu base de datos.

Esta es la estructura de una llamada de fuente única:

curl -X POST https://api.foura.ai/api/single \
  -H "X-API-Key: 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 de Browser para un sitio corporativo con alto uso de JavaScript:

curl -X POST https://api.foura.ai/api/browser \
  -H "X-API-Key: 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 utiliza cada herramienta. Nosotros nos aseguramos de que la herramienta realmente funcione y pase.

Resultados

Hemos visto a varios equipos migrar de scrapers internos a un pipeline enrutado con FourA durante la beta pública. El patrón es constante (cifras ilustrativas basadas en lo que hemos observado en el grupo de la beta):

• Latencia de enriquecimiento: baja de 3 a 6 segundos por empresa a una mediana inferior a 1.5 segundos en rutas residenciales con caché
• Tasa de fallos silenciosos (respuestas 200 con datos vacíos): baja de alrededor del 8% a menos del 1% una vez que el bloque validate detecta fallos suaves antes de que lleguen a la base de datos
• Tiempo de ingeniería en mantenimiento de scrapers: baja de 1 o 2 ingenieros a tiempo completo a un canal de Slack que casi siempre permanece tranquilo
• Tasa de éxito al primer intento en directorios protegidos: sube a más del 95% cuando unblocker: true se combina con un proxy id limpio

Un dato más que vale la pena destacar: hemos visto que la exactitud en el primer intento (datos correctos de la empresa correcta) se queda unos cuatro puntos por detrás del éxito en el primer intento. La lección no es que el scraping sea difícil. Es que todavía necesitas validar el registro contra la empresa que realmente solicitaste (escribimos sobre ese patrón en por qué tu web scraper no para de romperse).

Las cifras que importan no son el tamaño del pool de proxies ni el recuento de requests. Son la tasa a la que tu endpoint de enriquecimiento devuelve los datos correctos al primer intento y la pendiente de tu gráfica de mantenimiento de scrapers durante los próximos seis meses.

Conclusión principal

Los pipelines de enriquecimiento fallan en cámara lenta. El primer scraper que escribes parece funcionar bien un martes. Para la tercera fuente, estás parchando selectores a las 11 de la noche. Para la décima, arrastras una deuda de mantenimiento que escala al ritmo de tu base de clientes. Para la vigésima, has dejado de integrar nuevas fuentes silenciosamente 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 y la regla de validación correcta para cada URL, cada vez. Construye esa capa una sola vez o delégala en algo que ya lo haga, y tu equipo podrá dedicar el martes al producto en lugar de clasificar roturas de selectores.