← 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á desenvolvendo um produto SaaS B2B. Seus clientes enviam uma lista de nomes de empresas. Eles esperam receber de volta um registro limpo: faixa de receita, número de funcionários, stack tecnológica, rodada de investimento, contatos principais e 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, nas páginas Sobre das empresas, nas páginas corporativas do LinkedIn, no Google Maps, no Glassdoor, em registros comerciais regionais e nos arquivos do TechCrunch. O problema é acessá-los de forma confiável.

Cada fonte quebra de um jeito diferente. O Crunchbase entrega uma aplicação pesada no lado do cliente que renderiza novamente se suspeitar de um bot. O LinkedIn aplica rate limits agressivos e altera o DOM mais rápido do que você consegue corrigir seletores (uma publicação popular da comunidade estima que um scraper vanilla em Python roda cerca de 50 perfis antes que o site comece a recusá-lo). Os sites das empresas variam de HTML estático a single-page apps que precisam de um navegador completo até para exibir o conteúdo. Diretórios regionais mudam os layouts a cada trimestre e aplicam bloqueios específicos por país. De acordo com um relatório de 2026 do setor feito pelo GroupBWT, de 10 a 15% dos crawlers em alguns segmentos precisam de correções semanais só para acompanhar as mudanças de detecção de bots e a variação de DOM.

Assim, seu pipeline de enriquecimento começa como um projeto limpo com cinco fontes. Seis meses depois, ele se torna um emaranhado de scrapers semi-quebrados, filas de repetição 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). Reclamações sobre qualidade dos dados se acumulam na fila de suporte. Sua equipe começa a brincar que o nome da empresa deveria ser "Cinco Scrapers e Uma Promessa".

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 fontes que você vai encontrar.

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

SPAs com muito JavaScript. Crunchbase, aplicativos estilo LinkedIn e até sites de empresas de médio porte não retornarão os dados que você quer a partir de uma resposta HTTP simples. Eles renderizam no cliente. É para isso que serve o Browser: um navegador completo executa a página, roda o JS e devolve o HTML renderizado, cookies e capturas de tela. Assim como o Single, ele faz o roteamento pelo Proxy Finder nos bastidores, sem nenhuma etapa de seleção separada do seu lado.

Fontes mistas com validação. Toda request para a API da FourA aceita um bloco validate. Você pode exigir códigos de status específicos, correspondências de cabeçalho ou correspondências de substring no corpo. Se a resposta for uma falha silenciosa (uma página 200 pedindo verificação, uma estrutura de dados vazia ou um aviso de "desculpe-nos"), o validador a rejeita. Seu pipeline pode então rotear a mesma URL pelo Browser. Esse único recurso elimina a classe mais cara de bug em enriquecimento de dados: a falha silenciosa que grava lixo no seu banco de dados.

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

E o equivalente no Browser para um site corporativo com muito 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
  }'

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 funcione.

Resultados

Acompanhamos algumas equipes migrarem de scrapers internos para um pipeline roteado pelo FourA durante o beta público. O padrão é consistente (números ilustrativos baseados no que observamos no grupo do beta):

  • Latência de enriquecimento cai de 3 a 6 segundos por empresa para menos de 1,5 segundo na mediana em rotas residenciais com cache
  • Taxa de falhas silenciosas (respostas 200 com dados vazios) cai de cerca de 8% para menos de 1% assim que o bloco validate captura falhas parciais antes que cheguem ao banco de dados
  • 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 em silêncio
  • Taxa de sucesso na primeira tentativa em diretórios protegidos sobe para a faixa acima de 90% quando o unblocker: true é combinado com um proxy id limpo

Mais um número que vale destacar: vimos a exatidão na primeira tentativa (dados corretos, empresa correta) ficar cerca de quatro pontos atrás do sucesso na primeira tentativa. A lição não é que 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 requests. São a taxa com que o 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.

Principal conclusão

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ê carrega uma dívida técnica de manutenção que escala com a sua base de clientes. Na vigésima, você simplesmente parou de adicionar novas fontes porque ninguém na equipe quer assumir a 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, sempre. Construa essa camada uma única vez, passe a tarefa para algo que já faz isso e a sua equipe poderá passar a terça-feira focada no produto em vez de lidar com a quebra de seletores.