Pergunte à equipe de dados quanto custa a coleta de dados na web e você vai ouvir falar de gigabytes, contagem de requisições, créditos e taxas de sucesso. Pergunte ao financeiro o que eles querem saber e a resposta é mais simples: quanto nos custa um registro utilizável, e esse valor está subindo ou descendo? As duas conversas raramente se encontram, porque os números que os engenheiros acompanham descrevem o pipeline, não o que ele produz.
Custo por registro limpo fecha essa lacuna. É o custo total de um job de coleta dividido pelos registros que passaram na validação, aqueles que você de fato colocaria em um relatório, um modelo ou um produto voltado ao cliente. Este guia define isso corretamente, mostra para onde o dinheiro realmente vai, trabalha com um exemplo e classifica as alavancas que o movem.
Principais conclusões
- Meça o custo por registro limpo: custo total dividido pelos registros que passaram na validação de conteúdo, não pelas requisições ou sucessos HTTP.
- Para jobs de monitoramento, adicione o custo por mudança útil. A maioria das rebuscas confirma que nada mudou, então uma mudança pode custar muitas vezes mais que um registro.
- O modelo de cobrança determina qual desperdício dói mais. A cobrança por banda penaliza páginas pesadas; a cobrança por sucesso penaliza buscas desnecessárias.
- Uma página inicial mediana pesa cerca de 2,5 MB, dos quais apenas 22 KB são HTML. Buscar apenas o que você processa costuma ser a maior economia isolada em coleta cobrada por banda.
- Reporte a métrica mensalmente, por job, com seus componentes. Um número que o financeiro consegue acompanhar é um número que recebe orçamento.
Defina a métrica com cuidado
Três definições fazem a maior parte do trabalho.
Custo total é tudo que o job consumiu: banda de proxy ou créditos de API, computação, armazenamento e, se você for honesto, o tempo de engenharia gasto para mantê-lo funcionando.
Um registro limpo é aquele que passou na validação: campos obrigatórios presentes, valores em faixas plausíveis, e uma página que era de fato a página solicitada, e não uma página de bloqueio, um desafio ou uma casca vazia. Uma resposta com HTTP 200 não é um registro limpo até passar por essas verificações; a lacuna entre os dois é o tema de a taxa de falha silenciosa.
Uma mudança útil importa para o monitoramento. Se você rebusca um preço todos os dias e ele muda duas vezes por mês, o registro pelo qual você pagou nos outros 28 dias não confirmou nada de novo. O custo por mudança útil captura para que o monitoramento realmente serve.
Saiba como você é cobrado
O mesmo pipeline pode ser caro ou barato dependendo do modelo de cobrança, porque cada modelo conta coisas diferentes.
| Modelo de cobrança | Pelo que você paga | O que torna caro |
|---|---|---|
| Banda de proxy residencial | Bytes através do gateway | Páginas pesadas, renderização, retentativas que transferem dados |
| Créditos de API de scraping | Respostas bem-sucedidas | Buscas que você não precisava fazer |
No gateway residencial da Shifter, todo byte enviado ou recebido conta, incluindo cabeçalhos, e requisições com falha contam se bytes foram transferidos antes do erro. Na Web Scraping API, uma requisição bem-sucedida custa um crédito com ou sem renderização de JavaScript ativada, requisições com falha e erros do lado do alvo não custam nada, e retentativas automáticas dentro de uma chamada são contadas como essa única chamada. Assim, na cobrança por banda, uma página renderizada que carrega todas as imagens e scripts pode custar muito mais que seu HTML; na cobrança por sucesso, custa o mesmo.
A diferença de tamanho é grande. O Web Almanac 2025 do HTTP Archive constatou que a página inicial mediana pesava 2,86 MB no desktop e 2,56 MB no mobile, enquanto o HTML mediano era de 22 KB em ambos. Se você processa apenas o HTML, ou um endpoint JSON por trás dele, a maior parte dos bytes de uma página totalmente renderizada não lhe traz nada.
Um exemplo trabalhado
Considere um job de monitoramento ao longo de um mês. Os números abaixo são ilustrativos, escolhidos para mostrar a aritmética, e a taxa de $3 por GB é um valor redondo para o exemplo, não uma cotação.
| Entrada | Valor |
|---|---|
| Requisições enviadas, incluindo retentativas | 120.000 |
| Bytes médios por requisição | 450 KB |
| Sucessos em nível HTTP | 108.000 |
| Registros que passaram na validação | 97.000 |
| Registros válidos que diferiram da última cópia | 6.800 |
| Taxa de banda | $3,00 por GB |
| Computação | $40 |
Rodando a calculadora abaixo, obtemos:
| Métrica | Valor |
|---|---|
| Custo total | $202,00 |
| Custo por requisição | $0,0017 |
| Custo por registro limpo | $0,0021 |
| Custo por mudança útil | $0,0297 |
| Taxa de falha silenciosa | 10,2% |
| Bytes por registro limpo | cerca de 557 KB |
Duas coisas se destacam. Cada mudança útil custa cerca de quatorze vezes mais que cada registro limpo, porque a maioria das buscas confirma que nada se moveu. E uma em cada dez requisições HTTP bem-sucedidas não produziu nada utilizável.
Agora mude uma coisa: pare de renderizar páginas completas e busque apenas o HTML ou JSON de que o parser precisa, reduzindo a média de 450 KB para 60 KB por requisição. Tudo o mais permanece igual. O custo total cai para $61,60, o custo por registro limpo para $0,0006, e o custo por mudança útil para $0,0091, uma redução de mais de dois terços a partir de uma única mudança na forma de buscar páginas.
A calculadora tem poucas linhas:
from dataclasses import dataclass
@dataclass
class Run:
requests: int # every request sent, including retries
bytes_transferred: int # everything through the proxy, failures included
responses_ok: int # HTTP-level successes
records_valid: int # records that passed content validation
records_changed: int # valid records that differed from the last copy
price_per_gb: float # your plan's rate
compute_cost: float = 0.0
people_cost: float = 0.0 # engineering time spent on this job, if you count it
def unit_economics(run):
bandwidth = run.bytes_transferred / 1e9 * run.price_per_gb
total = bandwidth + run.compute_cost + run.people_cost
return {
"total_cost": round(total, 2),
"cost_per_request": round(total / max(1, run.requests), 5),
"cost_per_clean_record": round(total / max(1, run.records_valid), 4),
"cost_per_useful_change": round(total / max(1, run.records_changed), 4),
"silent_failure_rate": round(1 - run.records_valid / max(1, run.responses_ok), 3),
"bytes_per_clean_record": int(run.bytes_transferred / max(1, run.records_valid)),
}Para um job cobrado por créditos, substitua a linha de banda por respostas bem-sucedidas multiplicadas pelo seu preço por crédito. O resto da aritmética é o mesmo.
As alavancas, em ordem aproximada de impacto
1. Pare de buscar o que não mudou. Para monitoramento, rebuscas sem mudança costumam ser o maior item de custo. Agendar visitas de acordo com a frequência real de mudança de cada página, e usar requisições condicionais onde os sites suportam, reduz buscas sem perder mudanças. O método está descrito em agendamento de crawl com foco em custo, e como distinguir mudanças reais de ruído em detecção de mudanças em escala.
2. Busque menos por página. Na cobrança por banda, evite renderizar a menos que os dados precisem disso, bloqueie imagens, fontes e mídia quando precisar renderizar, prefira endpoints JSON e mantenha a compressão ativada. A lista completa está em reduzindo custos de banda de proxy.
3. Corrija falhas silenciosas. Toda página de bloqueio, desafio ou casca vazia que passa como sucesso custa o mesmo que um bom registro e não produz nada. Valide o conteúdo, conte falhas por alvo, e corrija ou desacelere os alvos que as produzem.
4. Extraia de fontes estáveis. Manutenção é um custo real. Seletores que quebram a cada redesign consomem tempo de engenharia, motivo pelo qual dados estruturados são mais baratos ao longo de um ano do que parecem em uma única execução; veja pare de fazer parsing de HTML.
5. Combine o modelo de cobrança com o alvo. Páginas pesadas que precisam ser renderizadas podem ser mais baratas na cobrança por sucesso; alvos leves de HTML ou JSON costumam ser mais baratos na cobrança por banda. Portfólios mistos costumam usar ambos. A compensação mais ampla é abordada em construir vs comprar infraestrutura de web scraping.
Reportando ao financeiro
Uma métrica só importa se for reportada de forma consistente. Uma vez por mês, por job, publique:
- Custo total, dividido em banda ou créditos, computação e, se você contar, pessoas.
- Registros limpos, e custo por registro limpo.
- Para jobs de monitoramento, mudanças úteis, e custo por mudança útil.
- Taxa de falha silenciosa e bytes por registro limpo, como os dois principais indicadores.
- A principal mudança desde o mês anterior, e o motivo.
Mantido por um trimestre, isso transforma dados web de uma linha opaca de infraestrutura em um custo unitário que pode ser orçado, comparado com a compra dos dados em outro lugar, e defendido.
Conclusão
Gigabytes e contagens de requisições descrevem esforço. O financeiro se importa com o resultado: quanto custa um registro utilizável, e, para monitoramento, quanto custa uma mudança real. Defina registros limpos por validação, não por códigos de status, conte todo custo que o job gera, e reporte o resultado por job todo mês.
As alavancas raramente são exóticas. Busque com menos frequência onde nada muda, busque menos por página, pare de pagar por páginas que parecem bem-sucedidas e não são, e extraia de fontes que não quebram. Cada uma aparece diretamente em um número que todos na sala conseguem ler.
Fontes e referências
- HTTP Archive, Web Almanac 2025: Page Weight. Peso mediano de página e HTML, crawl de julho de 2025.
- Shifter, documentação de banda e cobrança de Residential Proxies e erros e limites da Web Scraping API.