Detector de anomalías en métricas de negocio

El detector de anomalías es un servicio que escanea las métricas de negocio a diario (o con mayor frecuencia) y levanta la mano cuando un indicador se comporta de forma atípica. La lógica es simple: el modelo aprende de datos históricos, fija el rango normal teniendo en cuenta la estacionalidad y la tendencia, y marca los puntos fuera de ese rango. El equipo se entera de una caída de ingresos, un pico en el churn rate o una conversión inusual en el momento en que aparece la señal, y no dos semanas después en una retrospectiva.

Qué incluye el esquema típico:

1. Conexión a la fuente de datos: data warehouse o consulta directa a una herramienta de BI.
2. Definición del conjunto de métricas: ingresos por canal, MRR, usuarios activos, conversión por etapas del embudo, churn, ticket promedio, tamaño del pedido, existencias en almacén, runway.
3. Entrenamiento de modelos base con datos históricos de cada métrica: se tienen en cuenta la estacionalidad diaria y semanal, los festivos y la tendencia.
4. Ejecución periódica de verificaciones (cron o event-driven) con cálculo de la desviación respecto al valor esperado.
5. Publicación de la alerta en Slack o Teams con contexto: métrica, valor actual, rango esperado, magnitud de la desviación, enlace al dashboard.
6. Registro de anomalías confirmadas y falsos positivos, para el reajuste de umbrales.

Lo que el detector NO hará:

• No explica la causa de la anomalía. La señal indica «aquí algo no cuadra», pero el root cause analysis queda a cargo de la persona.
• No funciona sin datos históricos limpios. Si la vista de ingresos falla una vez a la semana o la métrica cambió de fórmula recientemente, el modelo generará ruido.
• No es responsable de las decisiones de negocio. La alerta en Slack es un disparador de entrada para la investigación, no una instrucción para detener una campaña o subir los precios.

Arquitectónicamente, el servicio consta de cuatro capas: fuente de datos, motor de cálculo, motor de alertas, canal de entrega. El enfoque Custom-code se aplica cuando las plataformas SaaS para anomaly detection son excesivas en precio o encajan mal en la especificidad de las métricas del cliente.

Flujo técnico

1. El planificador (Airflow, Prefect, Dagster o cron en kubernetes) lanza la tarea batch según el calendario — una vez por hora o una vez al día, según la métrica.
2. El Job realiza una consulta SQL en el data warehouse y obtiene la serie temporal de la métrica necesaria con un historial de 90-365 días.
3. El módulo de detección aplica uno de los modelos: descomposición STL y z-score para la mayoría de las métricas, Prophet o ARIMA para series con estacionalidad pronunciada, isolation forest para casos multidimensionales.
4. Cálculo del rango esperado para el punto actual. Si el valor real supera los límites del intervalo de confianza, se registra una anomalía con indicación de la dirección y la magnitud.
5. Postprocesamiento: filtrado de duplicados (una anomalía no genera alerta dos veces), agregación de señales relacionadas, clasificación por severity.
6. Generación del mensaje en Slack o Teams mediante webhook — métrica, valor, expectativa, delta, ventana temporal, enlace al BI-dashboard para drill-down.

Pasos de implementación

1. Auditoría de métricas y priorización: lista de 10-20 KPI críticos que tiene sentido monitorizar (más — se ahogará en alertas).
2. Preparación de datos: verificación de calidad, tabla unificada de métricas en DWH o materialized view, documentación del SLA sobre la frescura de los datos.
3. Elección del stack: Python con bibliotecas para análisis de time-series, orquestador, secretos para la conexión a DWH y messenger.
4. Prototipo con 2-3 métricas, calibración manual de umbrales, ejecución sobre datos históricos para verificar la precisión.
5. Ampliación de la cobertura, adición de niveles de severity, separación de canales (las alertas P1 van al canal de guardia, P2 — al digest).
6. Modo shadow de dos semanas: las alertas se escriben en el log, pero no se envían a Slack — se verifica la frecuencia de falsos positivos.
7. Lanzamiento en producción, revisión mensual de umbrales y eficiencia.

Componentes del sistema

El coste de la infraestructura es bajo: el cálculo toma minutos, la carga sobre el DWH es pequeña. El principal recurso es el tiempo del data engineer o ML engineer para la calibración de modelos y el trabajo con los propietarios de las métricas.

Lo que debe tener el cliente antes del inicio del proyecto:

Datos y accesos:

• Data warehouse o base analítica centralizada con historial de métricas de al menos 6 meses (un año es mejor).
• Consultas SQL documentadas o modelos dbt para las métricas clave. Si cada métrica se calcula ad hoc de distintas formas — primero se pone orden.
• Cuenta de servicio para lectura de datos y webhook URL en Slack o Teams para el envío de alertas.
• Comprensión de la estacionalidad: el equipo sabe que los sábados baja la facturación y en diciembre sube el ticket medio — el modelo se entrena con esto en cuenta.

Equipo y responsables:

• El responsable de métricas de turno — la persona que responde a la alerta. Sin owner el servicio se convierte en un canal de ruido.
• Analista o data engineer que conoce la lógica de las métricas y ayuda en la calibración.
• DevOps o ingeniero de plataforma para el despliegue (Docker, secretos, acceso al DWH desde la infraestructura).

Stack tecnológico:

• Python 3.10+, Docker, orquestador (si aún no existe — levantamos un Prefect sencillo o cron en el clúster kubernetes existente).
• Acceso a Slack o Microsoft Teams mediante incoming webhook.

Plazos:

• Prototipo con 2-3 métricas: 2-3 semanas.
• Conjunto completo de 10-20 métricas con calibración y modo shadow: 4-6 semanas.
• Si el data warehouse no está configurado o los datos están sucios — añada 2-4 semanas de preparación.