← Todos os posts
Caso de uso 6 min de leitura

Construindo um pipeline de enriquecimento de empresas B2B

Precisa enriquecer milhares de empresas diariamente a partir de diretórios, sites e imprensa? Veja como construir um pipeline de enriquecimento B2B que não quebra toda semana.

b2blead generationdata enrichmentcompany enrichmentuse case

O Desafio

Você está construindo um produto SaaS B2B. Seus clientes enviam uma lista de nomes de empresas. Eles esperam um registro limpo em troca: faixa de receita, número de funcionários, stack de tecnologia, rodada de investimentos, contatos principais, notícias recentes. Eles esperam isso em minutos, não dias. E eles esperam que esteja correto.

Os dados existem. Eles vivem no Crunchbase, em páginas Sobre de empresas, em páginas de empresas no LinkedIn, no Google Maps, no Glassdoor, em registros comerciais regionais, em arquivos do TechCrunch. O problema é chegar até eles de forma confiável.

Cada fonte quebra de maneira diferente. O Crunchbase serve um aplicativo client-side pesado que re-renderiza se suspeitar de um bot. O LinkedIn aplica rate limits agressivos e muda seu DOM mais rápido do que você consegue corrigir seletores (uma postagem popular da comunidade faz o benchmark de um scraper Python puro em cerca de 50 perfis antes da parede anti-bot cair). Os sites de empresas variam de HTML estático a single-page apps que precisam de um navegador completo até mesmo para mostrar seu conteúdo. Diretórios regionais rotacionam layouts a cada trimestre e colocam bloqueios específicos por país. De acordo com um relatório do setor de 2026 da GroupBWT, 10 a 15% dos crawlers em alguns nichos precisam de correções semanais apenas para acompanhar as atualizações anti-bot e as mudanças no DOM.

Então, seu pipeline de enriquecimento começa como um design limpo de cinco fontes. Seis meses depois, é um emaranhado de scrapers meio quebrados, filas de retry e um canal no Slack chamado #scraper-alerts que ninguém mais abre (já escrevemos sobre o custo oculto de manter seus próprios scrapers antes). As reclamações sobre a qualidade dos dados se acumulam na sua fila de suporte. Sua equipe começa a brincar que o nome da empresa deveria ter sido "Cinco Scrapers e Uma Prece".

A Abordagem

Esqueça os scrapers por um minuto. A parte difícil do enriquecimento não é a extração. É o roteamento: decidir qual fonte precisa de qual ferramenta, qual proxy, qual política de retry e o que conta como uma resposta "boa".

Uma plataforma como a FourA oferece três produtos que mapeiam diretamente para as três classes de fonte que você vai atingir.

Diretórios e registros HTML estáticos. A maioria dos registros comerciais regionais e muitos diretórios B2B antigos são renderizados no servidor. Eles querem uma requisição HTTP rápida e com baixo overhead de um IP limpo. Isso é o Single: uma URL entra, uma resposta sai. Adicione unblocker: true e ele passa por bloqueios no nível de handshake que param um cliente HTTP comum na hora. O Single roteia através do Proxy Finder automaticamente e retorna o ID do proxy no nível superior da resposta (r.proxy) para que suas chamadas subsequentes possam passá-lo de volta como proxy:"<id>" para manter a mesma saída quando você precisar de continuidade de sessão.

SPAs com uso intenso de JavaScript. Crunchbase, aplicativos estilo LinkedIn e até mesmo sites de empresas de médio porte não retornarão os dados que você deseja de uma resposta HTTP simples. Eles renderizam no cliente. Isso é o Browser: um navegador completo executa a página, roda o JS e devolve o HTML renderizado, cookies e screenshots. Como o Single, ele roteia através do Proxy Finder nos bastidores (sem um passo de escolha separado do seu lado).

Fontes mistas com validação. Cada requisição para a API da FourA aceita um bloco validate. Você pode exigir códigos de status específicos, correspondências de header ou correspondências de substring no corpo. Se a resposta for um soft-fail (uma página 200 com um CAPTCHA, ou um invólucro de dados vazio, ou um intersticial de "pedimos desculpas"), o validador a rejeita. Seu pipeline pode então rotear a mesma URL através do Browser em vez disso. Esse único recurso elimina a classe mais cara de bug no enriquecimento: a falha silenciosa que grava lixo no seu banco de dados.

Aqui está o formato de uma chamada de fonte ú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"] }
    }
  }'

E o equivalente do Browser para um site de empresa com uso intenso de 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
  }'

A lógica de roteamento fica no seu próprio pipeline. A confiabilidade fica no nosso. Você decide qual das suas fontes recebe qual ferramenta. Nós garantimos que a ferramenta realmente passe.

Resultados

Nós observamos algumas equipes migrarem de scrapers internos para um pipeline roteado pela FourA durante o beta público. O padrão é consistente (números ilustrativos com base no que vimos no grupo do beta):

  • A Latência de enriquecimento cai de 3 a 6 segundos por empresa para uma mediana abaixo de 1,5 segundos em rotas residenciais com cache
  • A Taxa de falha silenciosa (respostas 200 com dados vazios) cai de cerca de 8% para menos de 1% assim que o bloco validate captura soft-fails antes que eles cheguem ao banco de dados
  • O Tempo de engenharia na manutenção de scrapers cai de 1 a 2 engenheiros em tempo integral para um canal no Slack que permanece silencioso na maior parte do tempo
  • A Taxa de sucesso de primeira passagem em diretórios protegidos sobe para mais de 90% quando unblocker: true é pareado com um ID de proxy limpo

Mais um número que vale destacar: vimos a correção de primeira passagem (dados corretos, empresa correta) ficar atrás do sucesso de primeira passagem em cerca de quatro pontos. A lição não é que o scraping é difícil. É que você ainda precisa validar o registro em relação à empresa que você realmente solicitou (escrevemos sobre esse padrão em por que o seu web scraper continua quebrando).

Os números que importam não são o tamanho do pool de proxy ou a contagem de requisições. São a taxa na qual o seu endpoint de enriquecimento retorna os dados corretos na primeira tentativa, e a inclinação do seu gráfico de manutenção de scrapers nos próximos seis meses.

Principal Conclusão

Pipelines de enriquecimento falham em câmera lenta. O primeiro scraper que você escreve parece bom em uma terça-feira. Na terceira fonte, você está corrigindo seletores às 23h. Na décima, você carrega uma dívida de manutenção que escala com a sua base de clientes. Na vigésima, você para discretamente de integrar novas fontes porque ninguém na equipe quer ser o responsável pela próxima.

O gargalo nunca foi a fonte. Foi o roteamento: escolher a ferramenta certa, o proxy certo, a regra de validação certa para cada URL, todas as vezes. Construa essa camada uma vez, entregue-a para algo que já a faz, e a sua equipe poderá gastar a terça-feira trabalhando no produto em vez de triar quebras de seletor.