A maioria dos guias sobre como construir um dataset por meio de web scraping para em “escreva um scraper, salve os resultados”. Isso é os 20% fáceis. Os 80% difíceis, a parte que decide se seu dataset é realmente utilizável, é tudo em torno do fetch: garantir que você coletou as linhas certas, que elas estão completas, que estão atualizadas, e que as lacunas nos seus dados são aleatórias e não sistemáticas.
Esse último ponto é o que arruína datasets silenciosamente, e é o que quase ninguém escreve sobre. Quando um scrape falha em 30% das páginas, você não perde 30% dos seus dados de forma aleatória. Você perde uma fatia específica desses 30%, a parcela mais difícil de alcançar, mais defendida, mais restrita por geolocalização, e o que sobra é uma amostra enviesada que parece completa. Um modelo treinado com ela, ou uma decisão tomada a partir dela, herda esse viés sem que ninguém perceba.
Este é um guia prático para construir um dataset obtido por web scraping que se sustenta: os estágios do pipeline, as dimensões de qualidade que importam, e onde a camada de proxy é a diferença entre um dataset representativo e um enviesado.
O que “um bom dataset” realmente significa
Antes de qualquer código, deixe claro o que você está otimizando. Um dataset construído por scraping é julgado em cinco aspectos:
Completude. Você coletou tudo o que estava no escopo, ou apenas as partes que não reagiram? Linhas faltantes são ruins; linhas faltantes de forma sistemática são piores.
Representatividade. A amostra corresponde à população real? Se você está fazendo scraping de preços de produtos, mas seu scraper é bloqueado nos varejistas de alto tráfego e passa tranquilamente pelos pequenos, seu “preço médio” está errado em uma direção que você não consegue ver.
Atualidade (freshness). Dados da web decaem. Um dataset de preços do mês passado é um dataset diferente do de hoje. Você precisa saber o quão desatualizada cada linha está e ter um plano para atualizá-la.
Consistência. Toda linha deve seguir o mesmo schema, com as mesmas unidades, formatos e codificações. Scraping extrai de HTML bagunçado, então a normalização é metade do trabalho.
Proveniência. Para cada linha: de onde ela veio (URL de origem), quando você a coletou, e de onde (geo). Sem proveniência, você não consegue depurar, deduplicar, atualizar ou justificar o dataset depois.
Tenha esses cinco pontos em mente, porque toda decisão de pipeline abaixo está a serviço de um deles.
O pipeline, estágio por estágio
Um pipeline de scraping para dataset tem seis estágios. Trate-os como etapas distintas com sua própria validação, não como um único script grande.
1. Descobrir. Enumere as URLs no escopo, a partir de um sitemap, um crawl de busca/listagem, um índice de API, ou uma faixa de IDs conhecida. Esse estágio define sua população pretendida. Anote isso explicitamente; será sua referência para a completude mais tarde.
2. Buscar (fetch). Recupere cada URL. É aqui que ocorrem bloqueios, redirecionamentos por geo, limites de taxa e timeouts, e é onde nasce o viés do dataset. Mais sobre isso abaixo, porque é o estágio mais importante para a qualidade.
3. Extrair. Analise a resposta em campos estruturados. Seja defensivo: layouts mudam, campos desaparecem, e um seletor frágil silenciosamente se transforma em nulos em milhares de linhas.
4. Normalizar. Converta os valores brutos extraídos em tipos e unidades consistentes, moedas em uma única denominação, datas em ISO, espaços em branco removidos, codificações corrigidas, categorias mapeadas para um vocabulário controlado.
5. Deduplicar. A mesma entidade frequentemente aparece em várias URLs (canônica + variantes, duplicatas paginadas, itens relistados). Deduplique por uma chave estável, não pela URL.
6. Armazenar e atualizar. Persista com proveniência completa, depois decida uma cadência de recrawl para que o dataset permaneça atualizado em vez de decair para um snapshot de ponto único.
O estágio que decide a qualidade: fetch
Aqui está o argumento central de todo este texto. A qualidade do seu dataset é limitada no estágio de fetch, porque uma requisição bloqueada não apenas perde dados, ela perde dados não aleatórios.
Três mecanismos transformam falhas de fetch em viés de dataset:
Viés de bloqueio. Sistemas anti-bot (Cloudflare, Akamai, DataDome) protegem os alvos de maior valor e maior tráfego de forma mais agressiva. Se seu scraper roda a partir de um IP de datacenter e é bloqueado nesses alvos, seu dataset perde sistematicamente as linhas mais importantes enquanto mantém as fáceis. O resultado se inclina para fontes menores, menos defendidas, e parece completo porque você ainda obteve milhares de linhas. (Veja por que scrapers são bloqueados para entender a mecânica.)
Viés geográfico. Muitos sites servem conteúdo, preços ou disponibilidade diferentes de acordo com a localização do visitante, e redirecionam ou localizam silenciosamente com base no IP. Se todas as suas requisições se originam de uma região, todo campo que varia por geo no seu dataset reflete esse único ponto de vista, não a realidade global que você acha que capturou. Faça scraping da “disponibilidade global de produtos” a partir de um país e você na verdade capturou a visão de um único país, rotulada incorretamente como global.
Viés de limite de taxa. Quando um alvo limita sua taxa de requisições, a resposta ingênua é desacelerar ou desistir das páginas de resposta lenta, que costumam ser justamente as pesadas e ricas em dados. Você acaba superamostrando as páginas rápidas e leves.
A correção para os três é a mesma: fazer o fetch por meio de um pool de IPs que se pareçam com usuários reais, nos locais certos, para que a cobertura seja completa e uniforme, em vez de enviesada para o que era fácil de alcançar.
Por que a camada de proxy é uma decisão de qualidade de dados, não apenas infraestrutura
É por isso que uma rede de proxy residencial importa especificamente para a construção de datasets, além de apenas “não ser bloqueado”:
Cobertura completa. IPs residenciais carregam o perfil de confiança de conexões reais de consumidores, então eles conseguem passar pelos alvos defendidos que um IP de datacenter não consegue alcançar. Isso fecha a lacuna do viés de bloqueio, você coleta as linhas difíceis, não apenas as fáceis.
Cobertura geográfica intencional. Com segmentação por país, estado e cidade, você pode amostrar deliberadamente cada mercado e rotular cada linha com o ponto de vista de onde ela veio. Em vez de um único ponto de vista acidental, você obtém um dataset controlado e multi-geo, onde geo é uma coluna, não um fator de confusão oculto. Essa é a diferença entre “eu fiz scraping de preços” e “eu fiz scraping de preços como vistos a partir de 12 mercados específicos, registrados por linha”.
Amostragem uniforme em escala. Rotacionar por meio de um pool grande distribui as requisições de modo que nenhum IP único dispare limites de taxa, o que evita que você superamostre as páginas rápidas e subamostre as lentas e pesadas em dados.
Dito de forma simples: a camada de proxy é onde você decide se seu dataset é uma amostra representativa ou uma amostra de conveniência. Para trabalho com datasets, isso não é um detalhe de infraestrutura, é uma escolha metodológica. (Para a visão mais ampla de infraestrutura, veja infraestrutura de proxy para machine learning.)
Atualidade: um dataset é um verbo, não um substantivo
Um scrape único é um snapshot, e snapshots apodrecem. Decida de antemão se você está construindo um dataset estático (adequado para um estudo em um ponto específico no tempo) ou um dataset vivo (necessário para preços, estoque, listagens, qualquer coisa que mude).
Para datasets vivos:
- Defina uma cadência de recrawl compatível com a velocidade de mudança dos dados, por hora para preços voláteis, semanal para metadados de catálogo, mensal para dados de referência de mudança lenta.
- Faça atualizações incrementais, não re-scrapes completos. Detecte o que mudou (ETags, last-modified, hashes de conteúdo, diffs de listagem) e refaça o fetch apenas disso. Mais barato, mais rápido e mais leve para o alvo.
- Registre um timestamp de fetch em cada linha para que os consumidores posteriores possam filtrar por recência e você possa medir a desatualização.
Atualidade também é um problema de cobertura: se seu crawl de atualização for bloqueado repetidamente nas mesmas páginas defendidas, essas linhas ficam desatualizadas enquanto as fáceis permanecem atuais, reintroduzindo viés ao longo do tempo. A mesma correção se aplica.
Deduplicação e normalização, onde datasets são ganhos ou perdidos
Dados brutos de scraping são sujos. Dois estágios os limpam:
Normalizar para um schema. Decida primeiro o schema alvo, depois mapeie cada fonte para ele. Moedas em uma única denominação, datas em ISO 8601, números extraídos de strings como “1.299 unidades”, texto aparado e normalizado em unicode, categorias ajustadas a um vocabulário controlado. Normalização inconsistente é o motivo mais comum de um dataset de scraping ser tecnicamente completo, mas analiticamente inútil.
Deduplicar por uma chave estável, não pela URL. O mesmo produto, pessoa ou registro rotineiramente existe em várias URLs. Construa uma chave de deduplicação a partir da identidade estável (SKU, ISBN, nome normalizado + localização, URL canônica) e colapse duplicatas, mantendo a versão mais recente ou mais completa. Deduplicar apenas pela URL bruta deixará você com contagens infladas e linhas com peso duplicado que distorcem silenciosamente qualquer agregação.
Armazenando com proveniência
Para cada linha, armazene no mínimo:
- A URL de origem de onde ela veio
- O timestamp de fetch (UTC)
- O ponto de vista geográfico usado pela requisição (país/cidade), se geo importar para os dados
- Um hash de conteúdo ou versão, para que você possa detectar mudanças no recrawl
- O payload bruto (ou uma referência a ele), separado dos campos analisados, para que você possa reanalisar sem refazer o scraping quando seu extrator melhorar
Proveniência parece uma sobrecarga até a primeira vez que alguém pergunta “de onde veio esse número” ou seu extrator tem um bug e você precisa reanalisar 500 mil linhas sem acessar a rede novamente. Armazene isso desde o primeiro dia.
Validando o dataset antes de confiar nele
Antes que qualquer pessoa construa algo sobre o dataset, execute verificações de cobertura e qualidade, é assim que você detecta o viés que o estágio de fetch pode introduzir:
- Auditoria de cobertura. Compare as linhas coletadas com a população pretendida do estágio de descoberta. Uma taxa de conclusão de 92% é aceitável; a questão é se os 8% ausentes são aleatórios. Verifique amostras das falhas, se elas se concentram em uma fonte, um geo ou um tipo de site, você tem um viés sistemático para corrigir, não apenas dados ausentes.
- Verificação de taxa de nulos por campo. Um campo que de repente está 40% nulo geralmente significa um seletor quebrado, não dados ausentes.
- Verificações de sanidade de distribuição. A distribuição de preços, a mistura de categorias ou a distribuição geográfica correspondem ao esperado? Um desvio frequentemente revela um problema de amostragem a montante.
- Verificação de atualidade. Qual é a distribuição de idade das linhas? Se uma parte está sempre desatualizada, seu crawl de atualização está sendo bloqueado ali.
Essas verificações são baratas e são a diferença entre entregar um dataset e entregar um dataset confiantemente errado.
Uma nota sobre fazer isso de forma responsável
Construir datasets a partir da web vem com obrigações reais. Colete apenas dados públicos, respeite o robots.txt onde for determinante, respeite limites de taxa e não degrade os sites dos quais você extrai, evite dados pessoais a menos que você tenha uma base legal, e siga os termos de cada alvo. Um proxy muda de qual IP a requisição vem, não se você deveria estar fazendo essa requisição. Nossa política de uso aceitável é a fonte da verdade sobre o que é permitido na Shifter, e coleta ética de dados vale a pena ler antes de escalar.
Perguntas frequentes
Qual é a parte mais difícil de construir um dataset por web scraping? Não é o scraping, é a cobertura. Obter uma amostra completa e sem viés é muito mais difícil do que buscar páginas, porque requisições falhas removem fatias não aleatórias de dados e o dataset resultante ainda parece completo. A maioria dos problemas de qualidade de dataset remonta ao estágio de fetch.
Como os bloqueios enviesam um dataset obtido por scraping? Sistemas anti-bot protegem alvos de alto valor de forma mais agressiva, então um scraper que é bloqueado perde as linhas importantes e bem defendidas, mantendo as fáceis. O dataset se inclina para fontes menos defendidas, o que corrompe qualquer agregação ou modelo construído a partir dele.
Eu preciso de proxies residenciais para construir um dataset? Só se seus alvos bloquearem IPs de datacenter ou variarem o conteúdo por geografia, o que a maioria dos alvos valiosos faz. Para fontes desprotegidas e geo-neutras, IPs de datacenter são suficientes. Para cobertura completa e representativa de sites defendidos ou localizados, proxies residenciais fecham a lacuna de viés.
Como mantenho um dataset obtido por scraping atualizado? Defina uma cadência de recrawl compatível com a velocidade de mudança dos dados, faça atualizações incrementais (detecte mudanças via ETags/hashes/diffs em vez de re-scrapes completos), e registre um timestamp de fetch em cada linha para que você possa medir e filtrar por desatualização.
Como devo deduplicar dados obtidos por scraping? Por uma chave de identidade estável (SKU, ISBN, URL canônica, nome normalizado + localização), nunca pela URL bruta, porque a mesma entidade aparece em muitas URLs. Colapse duplicatas para a versão mais recente ou mais completa.
O que devo armazenar além dos campos extraídos? Proveniência: URL de origem, timestamp de fetch, ponto de vista geográfico, um hash de conteúdo para detecção de mudanças, e idealmente o payload bruto para que você possa reanalisar sem refazer o scraping quando seu extrator melhorar.
Conclusão
Construir um dataset com web scraping é um problema de qualidade de dados disfarçado de scraping. Qualquer um consegue buscar páginas; o trabalho é garantir que você buscou as páginas certas, de forma completa, atual, e sem uma lacuna sistemática onde deveriam estar os alvos difíceis. O pipeline, descobrir, buscar, extrair, normalizar, deduplicar, armazenar, atualizar, é direto. O único estágio que silenciosamente limita sua qualidade é o fetch, porque é ali que bloqueios e geo transformam dados ausentes em dados enviesados.
Acerte a camada de fetch e o resto é engenharia. Se suas fontes são defendidas ou variam por geo, uma rede de proxy residencial é o que transforma uma amostra de conveniência em uma amostra representativa, cobertura completa dos alvos difíceis, amostragem multi-geo deliberada, e rotação uniforme em escala. Quando estiver pronto para implementar, o guia de Python mostra o código do estágio de fetch, e a página de preços tem os planos por GB. Construa a cobertura primeiro, e o dataset cuida de si mesmo.