Tu modelo ya sabe cuándo hay que enviar la alerta

Cuando somos parte de un equipo de análisis de datos, a veces hace falta entregar algo más que un reporte: hace falta avisar. Que un tablero no se actualizó. Que una medida se salió del rango que definen las reglas del negocio. Que algo necesita atención antes de que alguien lo note por accidente, o peor, antes de que lo note un cliente.

Con un tablero, o hasta tres, de pocas páginas, revisar eso a mano es perfectamente viable. El problema aparece cuando el número de tableros en observación crece, o cuando los pocos que hay tienen muchas páginas: el monitoreo manual se vuelve agotador y, honestamente, un poco absurdo. Para eso existen las alertas —el tema está hipertrillado, llevan años entre nosotros, y no voy a ser quien te explique qué son o para qué sirven.

Este artículo trata de otra cosa: de cómo, intentando construir determinadas alertas de la forma más natural posible —usando las herramientas que normalmente aparecen primero cuando buscas una solución—, perdí de vista lo más importante: según qué alerta necesito, es la solución que más se adecúa. Y en este caso la respuesta ya estaba en el modelo.

Para mí, el modelo de datos es la parte más importante de este trabajo, y hay cuatro razones concretas. Primero, concentra la lógica de negocio en un solo lugar. Así, una condición como «vencido» o «fuera de rango» se define una sola vez y se aplica de la misma manera en todo el modelo. Segundo, conecta tablas que en el origen están separadas y permite responder preguntas que ninguna de ellas podría responder por sí sola. Tercero, las medidas se adaptan al contexto de filtros, sin tener que reescribir la misma regla para cada situación. Y, por último, todo lo que consume ese modelo —un visual, un correo automático o un flujo— trabaja sobre exactamente el mismo cálculo.

La prueba más concreta que tengo es el caso que armé para resolver justamente esto, usando el modelo de datos como fuente de la alerta.