Por qué un umbral fijo no alcanza para detectar anomalías de tráfico
La forma más básica de detectar anomalías es un umbral fijo: "avisame si el tráfico cae más de 20%". El problema es que ese umbral no sabe que hoy es feriado, ni que ayer hubo una campaña de email que infló el número de referencia — así que dispara alertas en momentos completamente esperables, o peor, se queda callado ante una caída real que no llega a ese 20% arbitrario.
GA4 ya trae un detector propio para este problema (la sección "Insights" del panel), que usa un modelo estadístico bayesiano para aprender qué rango de valores es normal para cada métrica, en vez de un porcentaje fijo. Igual tiene el mismo punto ciego que cualquier detector automático: según Tatvic Analytics, los períodos promocionales que duplican el tráfico habitual pueden disparar alertas por picos que en realidad son completamente esperados, así que sigue haciendo falta ajustar la sensibilidad a mano antes de cada pico conocido (Black Friday, un lanzamiento, una campaña grande). Tampoco baja al nivel de dimensión o parámetro: si las conversiones de Safari se caen a cero pero el total general se mantiene estable, Insights no lo va a marcar.
Modelos estadísticos simples: cuánta data histórica hace falta
Un modelo simple de detección de anomalías (media móvil con bandas de desvío estándar) ya corrige buena parte de ese ruido: en vez de un porcentaje fijo, marca como anómalo lo que se aleja de un rango calculado sobre el comportamiento reciente. La propia GA4 usa ventanas de este tipo para su detector nativo: 2 semanas de historial para anomalías por hora, 90 días para las diarias, 32 semanas para las semanales.
Para un modelo propio conviene apuntar más alto: al menos un año completo de datos, para que aprenda la estacionalidad específica del negocio — no solo que los lunes hay más tráfico que los domingos, sino los picos de diciembre, el bache de enero, el efecto de un Hot Sale. Con menos de un año, cualquier pico o valle estacional que el modelo todavía no vio se lee como anomalía, aunque se repita puntualmente cada año.
¿Puede un modelo de lenguaje reemplazar un modelo dedicado?
Para equipos que no quieren mantener infraestructura de ML, hay una alternativa más simple: pedirle a un modelo de lenguaje que reciba la serie temporal de los últimos 90 días y señale outliers, dándole contexto de fechas relevantes (feriados, lanzamientos, campañas). La pregunta es qué tan bien lo hace en la práctica, y ahí la respuesta depende de qué tipo de anomalía estás buscando.
Un estudio de 2026 que evaluó modelos multimodales aplicados a detección de anomalías en series temporales (Xu et al.) midió esto por tipo de anomalía:
| Tipo de anomalía | LLM / modelo multimodal | Método estadístico tradicional |
|---|---|---|
| Puntual (un día específico) | ~4% F1 | ~16% F1 |
| Por rango (varios días seguidos) | ~50% F1 | ~9% F1 |
| Por variable (una dimensión completa) | ~63% F1 | ~12% F1 |
En criollo: un modelo de lenguaje es bueno detectando que "algo viene raro hace tres o cuatro días" o que una dimensión completa se despegó del resto, pero es notablemente peor que un modelo estadístico dedicado para señalar el día puntual exacto de una caída. Como primera alerta de tendencia funciona mejor de lo esperable; como reemplazo de un detector fino, todavía no.
