← 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 receber de volta um registro limpo: faixa de faturamento, número de funcionários, stack de tecnologia, rodada de investimento, contatos principais, notícias recentes. Eles esperam isso em minutos, não em dias. E esperam que esteja correto.

Os dados existem. Eles estão no Crunchbase, em páginas de "Sobre" das empresas, em páginas de empresas no LinkedIn, no Google Maps, no Glassdoor, em registros comerciais regionais, em arquivos do TechCrunch. O problema é acessá-los de forma confiável.

Cada fonte quebra de um jeito diferente. O Crunchbase serve uma aplicação pesada no lado do cliente que renderiza novamente se suspeitar de um bot. O LinkedIn aplica rate-limits de forma agressiva e altera seu DOM mais rápido do que você consegue corrigir seletores (um post popular da comunidade estima que um scraper em Python puro consiga extrair cerca de 50 perfis antes que a barreira anti-bot caia). Os sites das empresas variam de HTML estático a aplicações de página única que precisam de um navegador completo para sequer exibir seu conteúdo. Diretórios regionais mudam de layout a cada trimestre e bloqueiam acessos com restrições geográficas 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 de DOM.

Assim, seu pipeline de enriquecimento começa com um design limpo de cinco fontes. Seis meses depois, é um emaranhado de scrapers parcialmente quebrados, filas de retentativas e um canal do Slack chamado #scraper-alerts que ninguém mais abre (já escrevemos sobre o custo oculto de manter seus próprios scrapers antes). 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 Oração".

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 retentativa e o que conta como uma resposta "boa" de uma response.

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

Diretórios e registros em HTML estático. A maioria dos registros comerciais regionais e muitos diretórios B2B mais antigos são renderizados no servidor. Eles exigem uma request HTTP rápida e de baixo custo a partir de um IP limpo. Isso é o Single: uma URL de entrada, uma response de saída. Adicione unblocker: true e ele supera bloqueios no nível de handshake que parariam um cliente HTTP padrão. O Single roteia pelo Proxy Finder automaticamente e retorna o proxy id no nível superior da response (r.proxy) para que suas chamadas seguintes possam passá-lo de volta como proxy:"<id>" para manter a mesma saída quando você precisar de continuidade de sessão.

SPAs pesadas em JavaScript. Crunchbase, aplicativos no estilo do LinkedIn e até mesmo sites de empresas de médio porte não retornarão os dados que você deseja a partir de uma response HTTP simples. Eles renderizam no cliente. Isso é o Browser: um navegador completo executa a página, roda o JS e entrega de volta o HTML renderizado, cookies e capturas de tela. Assim como o Single, ele roteia pelo Proxy Finder por baixo dos panos, sem uma etapa de seleção separada do seu lado.

Fontes mistas com validação. Cada request 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 response for uma falha parcial (uma página 200 com um CAPTCHA, uma estrutura de dados vazia ou uma tela intermediária de "desculpe-nos"), o validador a rejeita. Seu pipeline pode então rotear a mesma URL pelo Browser. Essa única funcionalidade elimina a classe de bug mais cara no enriquecimento: a falha silenciosa que grava lixo no seu banco de dados.

Here's the shape of a single-source call:

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"] }
    }
  }'

And the Browser equivalent for a JavaScript-heavy company site:

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 cada ferramenta. Nós garantimos que a ferramenta realmente consiga acessar.

Resultados

Acompanhamos algumas equipes migrarem de scrapers internos para um pipeline roteado pela FourA durante o beta público. O padrão é consistente (números ilustrativos baseados 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 segundo em rotas residenciais em cache
  • A taxa de falha silenciosa (responses 200 com dados vazios) cai de cerca de 8% para menos de 1% assim que o bloco validate captura as falhas parciais antes que elas 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 do Slack que quase sempre fica silencioso
  • A taxa de sucesso na primeira tentativa em diretórios protegidos sobe para a faixa superior dos 90% quando unblocker: true é combinado com um proxy id limpo

Mais um número que vale destacar: vimos que a exatidão na primeira tentativa (dados certos, empresa certa) fica cerca de quatro pontos percentuais atrás do sucesso na primeira tentativa. A lição não é que fazer 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 seu web scraper continua quebrando).

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

Conclusão Principal

Pipelines de enriquecimento falham em câmera lenta. O primeiro scraper que você escreve parece ótimo em uma terça-feira. Na terceira fonte, você está corrigindo seletores às 23h. Na décima, você está carregando uma dívida de manutenção que cresce junto com sua base de clientes. Na vigésima, você silenciosamente parou de adicionar novas fontes porque ninguém na equipe quer assumir a próxima.

O gargalo nunca foi a fonte. Era 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, passe-a para algo que já faça isso, e sua equipe poderá passar a terça-feira focada no produto em vez de triar quebras de seletores.