El 78% de sus informes no decía nada y no era un problema de umbrales

Un desarrollador que mantiene un producto de monitorización se puso a mirar qué estaba enviando de verdad a sus usuarios. El 78% de los informes traía un delta de exactamente cero: nada había cambiado respecto a la ejecución anterior. El informe era correcto, puntual y estaba vacío.

Su primera lectura fue que los umbrales de detección de cambios eran demasiado gruesos, que había movimiento real por debajo de la granularidad que medía y que una escala más fina lo sacaría a la luz. Se pasó un mes con eso. No era el problema. Un informe cuyo contenido es «sin cambios» no arrastra un problema de sensibilidad: simplemente no tiene nada dentro.

«Sin cambios» es el estado esperado

Dicho en voz alta, el razonamiento parece obvio. Alguien se registra, lanza una auditoría, recibe una lista de problemas, arregla unos cuantos y para. Ese es el camino del éxito. A partir de ahí su sitio queda quieto en las dimensiones que el producto mide, porque esas dimensiones son estáticas por naturaleza: robots.txt no se mueve, el marcado schema no se degrada y un llms.txt bien formado sigue bien formado hasta que alguien lo edita, y nadie lo edita. La población a la que iba dirigido el informe semanal era, en su mayoría, gente cuya respuesta honesta era «no pasó nada, y está bien».

De ahí sale una conclusión incómoda: un producto que vigila una señal de evolución lenta no tiene cadencia semanal propia. La tenía porque los productos de monitorización mandan informes semanales, que es una convención del sector y no una propiedad de los datos.

La métrica que faltaba no era un umbral

La cifra que el autor no estaba midiendo no describe el detector, sino la salida: qué fracción de los artefactos generados contiene al menos un dato que el destinatario no sabía ya. Él la llama tasa de contenido y la suya era del 22%. A partir de ese número, las decisiones de producto cambian de forma, y ninguna consiste en tocar umbrales.

Primero, ajustar la cadencia a la señal: enviar cuando hay algo y decirlo, porque «vigilamos y no se movió nada» encaja en un resumen mensual y desentona en un correo semanal. Segundo, añadir señales que se muevan solas, como la posición frente a competidores, la aparición o desaparición de una cita o un user-agent de crawler nuevo en los logs; son precisamente las que no dependen de que el usuario haga nada. Tercero, decidir si la estabilidad es una promesa explícita del producto o se elimina: «nada ha cambiado» vale dinero si el producto se presenta como una confirmación y es lastre si se presenta como un buscador de problemas. Él tenía lo segundo con la salida de lo primero.

Para medirlo propone una consulta sobre los propios informes, con una ventana que compare cada puntuación con la anterior del mismo dominio y cuente los pares idénticos. El detalle que importa es usar IS NOT DISTINCT FROM en lugar de =: NULL = NULL no es verdadero, así que una igualdad normal descarta en silencio todos los pares sin puntuación, y esos huecos se concentran justo donde está pasando algo raro.

Lo que le diría a su yo anterior es que se pasó semanas afinando umbrales porque ese trabajo parece el esfuerzo correcto: es medible, vive en el código, genera diffs y al final del día puedes señalar algo. Preguntarse si el informe debería existir no produce ningún diff. La señal de alarma, con perspectiva, es que estuvo ajustando la sensibilidad de un detector sin haber medido antes con qué frecuencia ocurre lo que ese detector busca. Es una comprobación barata: una consulta, antes de tocar nada.