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 de vuelta un registro limpio: rango de ingresos, número de empleados, 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 de información 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 manera confiable.

Cada fuente se rompe de manera diferente. Crunchbase sirve una aplicación pesada del lado del cliente que se vuelve a renderizar si sospecha de un bot. LinkedIn aplica un rate limit agresivo 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 de Python básico alcanza unos 50 perfiles antes de que caiga el muro anti-bot). Los sitios web de las empresas varían desde HTML estático hasta aplicaciones de una sola página que necesitan un navegador completo para mostrar su contenido. Los directorios regionales rotan sus diseños cada trimestre y bloquean el acceso según el país. Según un informe de la industria de 2026 de GroupBWT, entre el 10 y el 15% de los crawlers en algunos sectores necesitan correcciones semanales solo para mantenerse al día con las actualizaciones anti-bot y la deriva del DOM.

Así que tu pipeline de enriquecimiento comienza 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 antes sobre el costo 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 el nombre de la empresa debería haber sido "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é se considera una response "buena".

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

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

SPAs con mucho JavaScript. Crunchbase, las aplicaciones tipo LinkedIn e incluso los sitios web de empresas medianas no devolverán los datos que deseas a partir de una response HTTP simple. Se renderizan en el cliente. Eso es Browser: un navegador completo ejecuta la página, procesa el JS y te devuelve el HTML renderizado, las cookies y las capturas de pantalla. Al igual que Single, se enruta a través de Proxy Finder bajo el capó, sin necesidad de un paso de selección independiente 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, una estructura de datos vacía o una pantalla intermedia de "lo sentimos"), el validador la rechaza. Tu pipeline puede entonces enrutar la misma URL a través de Browser en su lugar. Esa única característica elimina el tipo de error más costoso en el enriquecimiento: el fallo silencioso que escribe basura en tu base de datos.

Así se ve 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 de Browser para un sitio web 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 confiabilidad reside en el nuestro. Tú decides cuál de tus fuentes recibe qué herramienta. Nosotros nos aseguramos de que la herramienta realmente funcione.

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 visto en el grupo de la beta):

• La latencia de enriquecimiento disminuye de 3 a 6 segundos por empresa a una mediana de menos de 1.5 segundos en rutas residenciales con 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 detecta los fallos leves antes de que lleguen a la base de datos
• El tiempo de ingeniería dedicado al mantenimiento de scrapers se reduce de 1 o 2 ingenieros a tiempo completo a un canal de Slack que casi siempre permanece en silencio
• La tasa de éxito en el primer intento en directorios protegidos sube a más del 90% cuando unblocker: true se combina con un proxy id limpio

Una cifra más que vale la pena destacar: hemos visto que la exactitud en el primer intento (datos correctos, empresa correcta) se queda por detrás del éxito en el primer intento por unos cuatro puntos. La lección no es que el scraping sea difícil. Es que aún necesitas validar el registro con respecto a la empresa que realmente solicitaste (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 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áfico de mantenimiento de scrapers durante los próximos seis meses.

Conclusión clave

Los pipelines de enriquecimiento fallan en cámara lenta. El primer scraper que escribes parece estar 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 junto con tu base de clientes. Para la vigésima, has dejado de incorporar 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 adecuada, el proxy adecuado, la regla de validación adecuada para cada URL, cada vez. Construye esa capa una vez, delégala en algo que ya lo haga, y tu equipo podrá dedicar el martes al producto en lugar de resolver roturas de selectores.