Pregunta a un equipo de datos cuánto cuesta su recolección web y hablará de gigabytes, número de peticiones, créditos y tasas de éxito. Pregunta a finanzas qué quiere saber y la respuesta es más simple: ¿cuánto nos cuesta un registro utilizable, y esa cifra sube o baja? Las dos conversaciones rara vez coinciden, porque las cifras que rastrean los ingenieros describen la canalización (pipeline), no lo que produce.
El coste por registro limpio cierra esa brecha. Es el coste total de un trabajo de recolección dividido entre los registros que superaron la validación, aquellos que realmente pondrías en un informe, un modelo o un producto de cara al cliente. Esta guía lo define correctamente, muestra adónde va realmente el dinero, desarrolla un ejemplo y clasifica las palancas que lo mueven.
Conclusiones clave
- Mide el coste por registro limpio: coste total dividido entre los registros que superaron la validación de contenido, no entre peticiones o éxitos HTTP.
- Para trabajos de monitorización, añade el coste por cambio útil. La mayoría de las nuevas descargas confirman que nada ha cambiado, así que un cambio puede costar muchas veces más que un registro.
- El modelo de facturación decide qué desperdicio duele. La facturación por ancho de banda penaliza las páginas pesadas; la facturación por éxito penaliza las descargas innecesarias.
- Una página de inicio mediana pesa unos 2,5 MB, de los cuales solo 22 KB son HTML. Descargar solo lo que analizas es a menudo el mayor ahorro individual en recolección facturada por ancho de banda.
- Reporta la métrica mensualmente, por trabajo, con sus componentes. Una cifra que finanzas puede seguir es una cifra que consigue presupuesto.
Define la métrica con cuidado
Tres definiciones hacen la mayor parte del trabajo.
El coste total es todo lo que consumió el trabajo: ancho de banda de proxy o créditos de API, cómputo, almacenamiento y, si eres honesto, el tiempo de ingeniería dedicado a mantenerlo funcionando.
Un registro limpio es uno que superó la validación: campos obligatorios presentes, valores en rangos plausibles, y una página que era realmente la página que pediste en lugar de una página de bloqueo, un desafío o una cáscara vacía. Una respuesta con un HTTP 200 no es un registro limpio hasta que supera esas comprobaciones; la brecha entre ambos es el tema de la tasa de fallo silencioso.
Un cambio útil importa para la monitorización. Si vuelves a descargar un precio cada día y este cambia dos veces al mes, el registro que pagaste los otros 28 días no confirmó nada nuevo. El coste por cambio útil captura para qué sirve realmente la monitorización.
Conoce cómo te facturan
La misma canalización puede ser cara o barata según el modelo de facturación, porque cada modelo cuenta cosas diferentes.
| Modelo de facturación | Por qué pagas | Qué lo encarece |
|---|---|---|
| Ancho de banda de proxy residencial | Bytes a través de la puerta de enlace | Páginas pesadas, renderizado, reintentos que transfieren datos |
| Créditos de API de scraping | Respuestas exitosas | Descargas que no necesitabas |
En la puerta de enlace residencial de Shifter, cuenta cada byte enviado o recibido, incluidas las cabeceras, y las peticiones fallidas cuentan si se transfirieron bytes antes del error. En la Web Scraping API, una petición exitosa cuesta un crédito tanto si el renderizado de JavaScript está habilitado como si no, las peticiones fallidas y los errores del lado del objetivo no cuestan nada, y los reintentos automáticos dentro de una llamada se cuentan como esa única llamada. Así que, en la facturación por ancho de banda, una página renderizada que trae todas las imágenes y scripts puede costar mucho más que su HTML; en la facturación por éxito, cuesta lo mismo.
La diferencia de tamaño es grande. El Web Almanac 2025 de HTTP Archive encontró que la página de inicio mediana pesaba 2,86 MB en escritorio y 2,56 MB en móvil, mientras que el HTML mediano era de 22 KB en ambos. Si solo analizas el HTML, o un endpoint JSON detrás de él, la mayoría de los bytes de una página completamente renderizada no te compran nada.
Un ejemplo desarrollado
Considera un trabajo de monitorización durante un mes. Las cifras siguientes son ilustrativas, elegidas para mostrar la aritmética, y la tarifa de $3 por GB es una cifra redonda para el ejemplo, no una cotización.
| Entrada | Valor |
|---|---|
| Peticiones enviadas, incluidos reintentos | 120.000 |
| Bytes promedio por petición | 450 KB |
| Éxitos a nivel HTTP | 108.000 |
| Registros que superaron la validación | 97.000 |
| Registros válidos que difirieron de la última copia | 6.800 |
| Tarifa de ancho de banda | $3,00 por GB |
| Cómputo | $40 |
Ejecuta el calculador de abajo, que da:
| Métrica | Valor |
|---|---|
| Coste total | $202,00 |
| Coste por petición | $0,0017 |
| Coste por registro limpio | $0,0021 |
| Coste por cambio útil | $0,0297 |
| Tasa de fallo silencioso | 10,2% |
| Bytes por registro limpio | unos 557 KB |
Dos cosas destacan. Cada cambio útil cuesta unas catorce veces más que cada registro limpio, porque la mayoría de las descargas confirman que nada se movió. Y uno de cada diez éxitos HTTP no produjo nada utilizable.
Ahora cambia una cosa: deja de renderizar páginas completas y descarga solo el HTML o JSON que el analizador necesita, reduciendo el promedio de 450 KB a 60 KB por petición. Todo lo demás permanece igual. El coste total baja a $61,60, el coste por registro limpio a $0,0006, y el coste por cambio útil a $0,0091, una reducción de más de dos tercios a partir de un solo cambio en cómo se descargan las páginas.
El calculador son unas pocas líneas:
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 un trabajo facturado por créditos, sustituye la línea de ancho de banda por respuestas exitosas multiplicadas por tu precio por crédito. El resto de la aritmética es igual.
Las palancas, en orden aproximado de impacto
1. Deja de descargar lo que no ha cambiado. Para la monitorización, las nuevas descargas sin cambios suelen ser la mayor partida. Programar las visitas según la frecuencia real de cambio de cada página, y usar peticiones condicionales donde los sitios lo permitan, reduce las descargas sin perder cambios. El método se expone en programación de rastreo consciente del coste, y distinguir cambios reales del ruido en detección de cambios a escala.
2. Descarga menos por página. En la facturación por ancho de banda, evita renderizar salvo que los datos lo necesiten, bloquea imágenes, fuentes y medios cuando debas renderizar, prefiere endpoints JSON y mantén la compresión activada. La lista completa está en reducir los costes de ancho de banda de proxy.
3. Corrige los fallos silenciosos. Cada página de bloqueo, desafío o cáscara vacía que pasa por éxito cuesta lo mismo que un buen registro y no produce nada. Valida el contenido, cuenta los fallos por objetivo, y corrige o ralentiza los objetivos que los producen.
4. Extrae de fuentes estables. El mantenimiento es un coste real. Los selectores que se rompen en cada rediseño consumen tiempo de ingeniería, por eso los datos estructurados son más baratos a lo largo de un año de lo que parecen en una sola ejecución; consulta deja de analizar HTML.
5. Ajusta el modelo de facturación al objetivo. Las páginas pesadas que deben renderizarse pueden ser más baratas con facturación por éxito; los objetivos ligeros de HTML o JSON suelen ser más baratos con facturación por ancho de banda. Las carteras mixtas a menudo usan ambos. El compromiso más amplio se trata en construir frente a comprar infraestructura de web scraping.
Reportarlo a finanzas
Una métrica solo importa si se reporta de forma consistente. Una vez al mes, por trabajo, publica:
- Coste total, dividido en ancho de banda o créditos, cómputo y, si lo cuentas, personas.
- Registros limpios, y coste por registro limpio.
- Para trabajos de monitorización, cambios útiles, y coste por cambio útil.
- Tasa de fallo silencioso y bytes por registro limpio, como los dos indicadores adelantados.
- El cambio principal desde el mes pasado, y por qué.
Mantenido durante un trimestre, esto convierte los datos web de una partida de infraestructura opaca en un coste unitario que puede presupuestarse, compararse con comprar los datos en otro lugar, y defenderse.
La conclusión
Los gigabytes y el número de peticiones describen el esfuerzo. A finanzas le importa el resultado: cuánto cuesta un registro utilizable, y, para la monitorización, cuánto cuesta un cambio real. Define los registros limpios por validación, no por códigos de estado, cuenta cada coste que incurre el trabajo, y reporta el resultado por trabajo cada mes.
Las palancas rara vez son exóticas. Descarga con menos frecuencia donde nada cambia, descarga menos por página, deja de pagar por páginas que parecen exitosas y no lo son, y extrae de fuentes que no se rompen. Cada una se refleja directamente en un número que todos en la sala pueden leer.
Fuentes y referencias
- HTTP Archive, Web Almanac 2025: Page Weight. Peso mediano de página y HTML, rastreo de julio de 2025.
- Shifter, documentación de ancho de banda y facturación de Residential Proxies y errores y límites de la Web Scraping API.