Pregunta a un equipo de scraping cómo van las cosas y normalmente obtendrás un número: la tasa de éxito. Es la métrica obvia y es genuinamente útil, pero por sí sola es casi inútil para dirigir un pipeline, porque oculta las dos preguntas que un líder de equipo realmente necesita responder. ¿Son correctos los datos que estamos recopilando? ¿Es razonable lo que pagamos por recopilarlos?
Un pipeline puede reportar un noventa y ocho por ciento de éxito mientras llena silenciosamente un almacén con páginas de challenge, y puede reportar el mismo número este mes que el pasado mientras cuesta el doble. Aquí está el conjunto de métricas que detecta ambos casos, organizado según para qué sirve cada una.
Empieza por la métrica que todo el mundo se equivoca
Tasa de éxito validada. No la proporción de solicitudes que devolvieron 200, sino la proporción que devolvió los datos que querías.
Esta distinción es el cambio de mayor valor que la mayoría de los equipos pueden hacer en su monitorización. Una página de challenge, un conjunto de resultados vacío, un listado truncado, un muro de consentimiento o una redirección regional genérica pueden llegar todos con un estado 200. Un contador que confía en los códigos de estado reportará salud mientras tu conjunto de datos se degrada, y te enterarás por un usuario de negocio que pregunta por qué un gráfico se ve mal, en lugar de por tu propio panel. Define una comprobación de validez por objetivo, un elemento esperado, una longitud de contenido plausible, un campo requerido en el JSON, y cuenta solo las respuestas que la pasan, como se describe en detectar contenido bloqueado o falso.
Rastréala por objetivo y por región, nunca como una cifra global única. Un 95% global podría ser cada objetivo al 95%, o diecinueve objetivos al 100% y uno a cero, y esos exigen respuestas completamente distintas.
Métricas de calidad de datos
Más allá de la validez, tres números indican si el resultado es fiable.
Cobertura. De los registros que esperabas en una ejecución, ¿cuántos obtuviste realmente? Un trabajo que tiene éxito en cada solicitud que hace, pero que hace menos solicitudes que ayer porque la paginación se rompió o un paso de descubrimiento devolvió menos, parecerá perfecto en tasa de éxito y estará materialmente incompleto. La cobertura detecta eso.
Actualidad (freshness). ¿Qué antigüedad tienen los datos más recientes por fuente? Para trabajos que cambian rápido, como precios o disponibilidad, la falta de actualidad es un defecto incluso cuando todo técnicamente tuvo éxito, así que rastrea la antigüedad de la recopilación exitosa más reciente por objetivo y alerta cuando supere lo que el caso de uso tolera.
Completitud a nivel de campo. De los registros recopilados, ¿qué proporción tiene todos los campos que necesitas? Un cambio de diseño que elimina un atributo raramente hace fallar una solicitud; simplemente deja una columna en nulo silenciosamente, y solo el seguimiento a nivel de campo lo detecta a tiempo.
Juntas, estas responden a “¿son correctos los datos?”, algo que la tasa de éxito por sí sola no puede.
Métricas de eficiencia y coste
Estas responden a “¿es razonable lo que pagamos?”, y suelen ser las menos instrumentadas.
Bytes por registro. La métrica de coste más útil de todo el conjunto. Divide el ancho de banda consumido por los registros útiles extraídos, por objetivo. Normaliza entre trabajos de tamaños diferentes, hace que los objetivos sean comparables, y un aumento repentino casi siempre se debe a alguien que renderiza una página completa cuando bastaría un endpoint de datos. Dado que los proxies residenciales se facturan por datos transferidos, este número está cerca de tu coste unitario, y las palancas sobre él están en reducir los costes de ancho de banda de proxy y elegir cuándo se justifica un navegador headless.
Coste por mil registros. Bytes por registro multiplicado por tu tarifa, expresado por objetivo. Este es el número que presentar a cualquiera que pregunte si una fuente de datos merece la pena recopilarse, porque convierte la infraestructura al lenguaje que el negocio ya usa, y es lo que hace concreta la previsión en estimar el ancho de banda mensual.
Ratio de reintentos. Reintentos como proporción del total de solicitudes, por objetivo. Es un indicador adelantado: sube antes de que caiga la tasa de éxito, porque un pipeline que reintenta hasta obtener un resultado que parece normal está ocultando un problema en lugar de resolverlo. También es puro desperdicio en un producto facturado por ancho de banda, así que es simultáneamente una señal de salud y una línea de coste, por lo que ocupa el centro de reintentos y backoff.
Ancho de banda por objetivo. Donde realmente va el dinero. Los equipos se sorprenden habitualmente al descubrir que un objetivo consume la mayoría de un plan, y la solución suele ser económica una vez que es visible.
Métricas de rendimiento
Percentiles de latencia, no promedios. Rastrea p50, p95 y p99 por objetivo. Las conexiones residenciales son más lentas que las directas por naturaleza, así que el número absoluto importa menos que la forma y la tendencia. Un promedio oculta por completo la cola, y la cola es lo que determina si un trabajo con límite de tiempo termina.
Rendimiento (throughput) frente al plan. Registros por hora, comparados con lo que exige el calendario. Así sabes si necesitas más concurrencia, mejor ritmo, o una estrategia de recopilación diferente, y es el insumo práctico para la cuestión de distribución en cuántas IPs de proxy realmente necesitas.
Tasa de bloqueo y challenge. Distinta de las solicitudes fallidas: la proporción de respuestas que fueron específicamente un bloqueo, un captcha o un challenge. Una tasa de challenge creciente con una tasa de éxito estable significa que estás trabajando más para el mismo resultado, y es una alerta temprana de que las defensas de un objetivo han cambiado.
Qué no rastrear
Dos cosas se miden mucho y merecen menos atención de la que reciben.
Tamaño del pool. Es un número del proveedor, no una métrica de rendimiento, y no predice tus resultados. La densidad en los países desde los que realmente recopilas sí lo hace, y la única forma de saberlo es tu propia tasa de éxito por región.
Recuento bruto de solicitudes. Volumen sin validez es actividad, no producción. Un pipeline que duplica sus solicitudes mientras recopila el mismo número de registros utilizables ha empeorado, y un contador de solicitudes llamará a eso crecimiento.
De forma similar, ten cuidado con cómo usas un SLA de disponibilidad. La disponibilidad del proveedor es real y merece atención, pero es un eje distinto de si tus objetivos aceptan tu tráfico, y confundir ambos te deja cubierto contractualmente pero ciego operativamente, que es el límite tratado en SLAs de proxy y garantías de disponibilidad.
Convertir métricas en alertas
Un panel que nadie mira es decoración. Un número reducido de alertas, vinculadas a las métricas anteriores, es lo que realmente protege un pipeline.
Alerta cuando la tasa de éxito validada caiga por debajo de un umbral por objetivo, ya que un solo número no puede ajustarse a cada sitio. Alerta cuando la cobertura descienda respecto a la misma ejecución de la semana anterior, lo que detecta reducciones silenciosas. Alerta cuando la actualidad supere la tolerancia del caso de uso. Alerta cuando los bytes por registro suban con fuerza, lo cual es una regresión de coste y normalmente un cambio de código. Y alerta cuando el ratio de reintentos aumente, porque es el que se dispara antes que todos.
Dos reglas prácticas hacen que esto sea manejable. Compara contra una línea base móvil en lugar de un número fijo, porque los objetivos tienen sus propios ritmos y un umbral estático o da falsas alarmas constantemente o nunca se dispara. Y exige una desviación sostenida en lugar de un solo intervalo malo, ya que una mala ventana de cinco minutos es ruido. La instrumentación en sí se trata en monitorizar un pipeline de web scraping.
Un conjunto mínimo para empezar
Si estás instrumentando desde cero, seis métricas por objetivo te dan la mayor parte del valor: tasa de éxito validada, cobertura frente a lo esperado, actualidad del registro más reciente, bytes por registro, ratio de reintentos y latencia p95. Añade la región como dimensión en las dos primeras, ya que la geografía es donde los pipelines multi-mercado fallan en silencio. Todo lo demás puede esperar hasta que una de esas seis plantee una pregunta que no puedas responder.
La conclusión
La tasa de éxito responde si las solicitudes se completaron, que es la menos interesante de las tres preguntas que tiene un líder de equipo. Valida lo que volvió antes de contarlo como éxito, luego mide cobertura, actualidad y completitud de campos para saber si los datos son correctos, y bytes por registro, coste por mil registros y ratio de reintentos para saber si el precio es razonable. Rastrea todo por objetivo y por región en lugar de globalmente, alerta ante una desviación sostenida respecto a una línea base móvil, y resiste la tentación de juzgar la infraestructura por el tamaño del pool o el volumen bruto de solicitudes. Las métricas que importan son las que cambian una decisión, y estas son las que lo hacen.
Medir contra la propia red es un ejercicio distinto, tratado en probar velocidad, tasa de éxito y precisión de ubicación. Los proxies residenciales subyacentes se facturan por GB, que es exactamente por qué los bytes por registro son la métrica de coste que vale la pena vigilar: es el número del que está hecha tu factura.