«Todo normal» no es «todo bien»: el punto ciego de la detección de anomalías en medios 

_{Tiempo estimado de lectura: 8 minutos}

El punto ciego de la detección de anomalías en datos de medios

Tenemos un detector de anomalías vigilando los datos. El día que nuestro data warehouse dejó de reflejar la realidad, dio el visto bueno. Por qué el fallo más caro en performance es también el más silencioso y por qué definir «lo normal» es más difícil de lo que parece.

Siempre me han gustado los artículos con una vertiente práctica y de los que te puedes llevar un conocimiento aplicable a tu contexto. Los que me conocen y me ven despotricando por Linkedin de vez en cuando, saben que estoy especialmente pesado últimamente con la importancia de la calidad de los datos. Siempre ha sido así, pero con la IA lo es todavía más, si cabe.

Intento predicar con el ejemplo y, como responsable último de la calidad de los datos y de su uso en IA y otros proyectos, es mi obsesión del día a día. Tenemos todo tipo de controles, tests, agentes que monitorizan, etc. Y a uno le gusta pensar que tiene su casa como los chorros del oro. Obviamente siempre hay cosas…Esta es la historia de una de estas cosas.

1. El precipicio que nadie vio

De repente, un canal de performance de un anunciante de generación de leads pasó de unas 1.900 conversiones al mes a cero en nuestro data warehouse. Cero absoluto.

Las campañas no se habían roto. El anunciante había migrado su medición a un nuevo CRM (Salesforce) y, por el camino, había redefinido cuál era su conversión. Nuestros equipos de campañas lo sabían, estaban encima y seguían optimizando con datos correctos: los que llegaban directamente del CRM del cliente. En el mundo real, los leads entraban con total normalidad. La gestión funcionaba.

Lo que se rompió fue interno, y mucho más sigiloso. Nuestro data warehouse seguía contabilizando la conversión antigua (la que aquel cambio había dejado de disparar). Nadie había reajustado en nuestro lado qué tipo de conversión debía medirse, y el data warehouse que alimenta nuestros informes, nuestros dashboards y nuestros propios modelos se quedó, sin previo aviso, midiendo un fantasma. La realidad decía «sano»; nuestro dato decía «cero».

Y para cazar exactamente eso tenemos un detector de anomalías: para detectar divergencias silenciosas entre lo que ocurre de verdad y lo que refleja el dato. Una métrica que se apaga sin razón aparente es su caso de uso de manual. No la cazó. Cada mañana revisaba la cuenta y cada mañana emitía el mismo veredicto: todo normal.

Y, técnicamente, tenía razón. Ahí está el problema.

Porque en performance una caída a cero es el fallo más caro que existe y, a la vez, el más silencioso. Un pico de gasto o un CPL disparado gritan: saltan en cualquier dashboard, llaman la atención, generan un mensaje a las nueve de la mañana. Un cero, no. Un cero no levanta la voz. La curva se aplana, el coste por lead deja de poder calcularse y la pantalla se queda… en calma. Y es muy fácil confundir esa calma con salud.

Que quede claro, entonces, de qué va esta historia: no falló la gestión de las campañas, ni el cliente dejó de vender. Falló la red de seguridad (el sistema que debía avisar de que nuestros datos habían dejado de reflejar la realidad) y falló de la peor manera posible: en silencio, dando el visto bueno. Este artículo va de por qué construir esa red no es, en el fondo, un problema de estadística, sino de definir qué significa «normal»; y de cómo esa definición, mal planteada, deja a tu sistema ciego justo ante lo que más importa.

2. El problema real no es la estadística: es definir qué significa «normal» en datos de medios

Cuando alguien piensa en «detector de anomalías», suele imaginar estadística: medias móviles, desviaciones típicas, z-scores, bandas que saltan cuando un número se sale de lo esperado. Y esa parte es… la fácil. La matemática para decir «esto está tres desviaciones por debajo de lo normal» cabe en unas pocas líneas de código.

Lo difícil (lo que de verdad decide si tu sistema sirve) es responder a una pregunta mucho más incómoda: ¿qué es «normal» para esta métrica? Y en medios, «normal» es un blanco en movimiento. Las campañas se lanzan y se pausan, los presupuestos suben y bajan, hay estacionalidad, fines de semana que caen, Black Friday, plataformas que reportan con un día de retraso. La mitad de lo que un detector ingenuo marca como «anomalía» no es más que un martes cualquiera.

Y ahí está la trampa. Para que un detector sea usable hay que callar ese ruido: si salta diez veces al día por cosas que no importan, nadie hará caso a la undécima, que sí importaba. Así que lo afinas para que sea preciso, para que sólo avise cuando está razonablemente seguro. Y al hacerlo, sin darte cuenta, construyes un sistema sordo precisamente a los fallos que peor pintan: los que no se parecen a «un número fuera de la banda».

Conviene además separar dos trabajos que se confunden constantemente. Vigilar la salud de la campaña es algo que ya hacen personas. El trabajo del detector es otro, y más callado: vigilar la integridad del dato, avisar cuando tu data warehouse deja de reflejar la realidad. Son cosas distintas, y el error más común es dar por hecho que la primera cubre la segunda. No la cubre. En nuestro incidente la salud de la campaña era perfecta; lo que se había roto era el espejo.

Lo que viene es el catálogo de formas concretas en que ese espejo se rompe. Seis puntos ciegos, en dos familias: las cosas que el sistema no ve (falsos negativos: el fallo de verdad ocurre y nadie se entera) y las cosas que el sistema se inventa (falsos positivos: salta la alarma cuando no pasa nada). Empecemos por las primeras, que son las que nos costaron el incidente.

3. Anatomía de un punto ciego en la monitorización de campañas

Dos ejes y cuatro celdas, con casi todo el peligro concentrado en una sola columna:

	El valor cae (p. ej. 100 → 20)	El valor se va a cero / desaparece
Monitor de volumen (umbral absoluto)	✅ Detecta: «hoy < umbral»	❌ Ciego: compara con el umbral actual, no con la propia historia; y una fila ausente no se ve
Monitor de eficiencia (ratio: CPL / CPA)	✅ Detecta: «el CPL se dispara»	❌ Ciego: CPL = NULL/∞, no hay dato → no hay alarma

La columna derecha (la caída a cero) es la zona muerta que ningún monitor naïve vigila. Ahí vivía nuestro incidente.

La fuerza del gráfico es que ambos monitores fallan en la misma columna por razones distintas: el de eficiencia porque su ratio se vuelve indefinido, el de volumen porque mira el valor de hoy contra un umbral fijo en vez de contra el pasado de ese mismo canal. Vamos celda por celda.

Lo que el sistema no ve

El punto ciego del cero. La mayoría de las métricas que de verdad importan en performance son ratios: CPL, CPA, coste por adquisición. Y un ratio esconde una trampa: divide por el resultado. Mientras hay conversiones, el CPL sube o baja y un detector lo sigue sin problema. Pero cuando las conversiones llegan a cero, el CPL no se vuelve «malo»: se vuelve indefinido —una división por cero, un NULL, un infinito—. Un sistema que vigila «¿se ha disparado el CPL?» no ve un valor alarmante; ve ausencia de dato. No hay nada contra lo que comparar. La alarma no es que no salte: es que no tiene forma de saltar. Justo lo que nos pasó: las conversiones en el almacén eran cero, así que el CPL desapareció, y con él cualquier señal.

La trampa de «lo actual, no lo histórico». «Vale —piensa uno—, pues vigilo el volumen: si las conversiones de hoy caen por debajo de un umbral, aviso.» Mejor, pero insuficiente. Un umbral fijo mira el valor de hoy de forma aislada y no sabe distinguir un canal que se ha desplomado a cero de uno que siempre estuvo cerca de cero porque apenas genera leads —y en él eso es normal—. Para que el cero de hoy signifique algo, hay que compararlo con el pasado de ese mismo canal: 1.900 → 0 es una emergencia; 3 → 0 es martes. La señal no está en el número, está en la diferencia con su propia historia.

Desaparición no es lo mismo que número bajo. Hay un escalón más sutil. A veces el problema no es que una fila valga cero, sino que la fila deja de existir. Si el canal desaparece del feed, no hay un «0» que vigilar: no hay nada. Y casi todos los detectores razonan sobre lo que está presente, recorren filas y las evalúan; lo que no está, no se evalúa. Detectar una ausencia exige cambiar la pregunta: ya no «¿este número es anómalo?», sino «¿qué esperaba ver y no está?». Eso obliga a mantener una lista de lo que debería aparecer y a vigilar rachas de ceros o de silencio.

La brecha del despliegue. El más prosaico de todos, y por eso el más frecuente. Un detector solo caza lo que ocurre mientras está mirando. Si lo construyes —o lo arreglas— después de un incidente, no lo va a encontrar: ya pasó. Mirar hacia delante no basta; hace falta también un escaneo retroactivo del histórico, que busque escalones y cambios de nivel anteriores a la existencia del propio sistema. Una monitorización sin memoria nace ciega a todo su pasado.

Lo que el sistema se inventa

El falso positivo por frescura. Ahora el reflejo opuesto. Supón que aciertas con todo lo anterior y montas un detector sensible a las caídas a cero. Llega la mañana, un conector va a medio sincronizar —algo habitual: hay integraciones que tardan horas, o que fallan y reintentan— y media jornada de datos aún no ha aterrizado. Para tu detector, un canal perfectamente sano parece haberse desplomado. Si avisas, gritas «¡que viene el lobo!»; y a la tercera vez que el lobo no viene pierdes credibilidad. La única salida es modelar la frescura del dato: saber si un día está completo antes de juzgarlo, y callar —o marcar como provisional— lo que todavía se está cargando.

No todo cero es un fallo. Y el último, el más sutil de los falsos positivos. A veces un cero es… correcto. Por ejemplo, la atribución se traslada al adserver y la conversión nativa de la plataforma cae a cero por diseño. Una línea se pausa a propósito. Una métrica se deja de medir porque ya no aplica. Un detector que trate todo cero como una emergencia acabará disparando ante decisiones deliberadas, y cada falso positivo erosiona esa confianza que tanto cuesta construir. El sistema no solo tiene que detectar el cero: debe tener algún modo de saber qué ceros eran esperados.

Los seis puntos ciegos, de un vistazo

Cuatro de los seis son cosas que el sistema no ve; dos, cosas que se inventa. Y la frescura del dato está en el centro de ambos lados, es lo que separa «campaña rota» de «dato que aún no ha llegado».

4. Qué cambiamos: arreglos que se generalizan

Lo bueno de tener un mapa de puntos ciegos es que las soluciones dejan de ser improvisación: cada arreglo cierra una celda concreta. Ninguno es especialmente sofisticado, lo difícil fue saber qué había que arreglar.

Comparar contra el máximo de (hoy, histórico), no contra un umbral fijo. Respuesta directa al punto ciego del cero y a la trampa de «lo actual»: si mides la caída tomando como referencia el mayor entre el valor de hoy y la línea base del propio canal, un 1.900 → 0 dispara la alarma y un 3 → 0 se queda donde debe, en silencio.

Detección explícita de desaparición / rachas de ceros. Cambiar la pregunta de «¿este número es anómalo?» a «¿qué entidad esperaba ver y lleva N días sin aparecer, o a cero?». Sin esto, las ausencias (el fallo más silencioso) no se ven nunca.

Modelar la frescura del dato. Antes de juzgar un día, comprobar si está completo. Lo que aún se carga se marca como provisional y no genera alarma. Es lo que separa «campaña rota» de «el conector no ha terminado», y lo que evita falsas alarmas.

Escaneo retroactivo al desplegar. Al arrancar o cambiar un detector, no mirar solo hacia delante: pasarlo por el histórico para cazar los escalones anteriores a su existencia. La monitorización debería nacer con memoria.

Una persona al final del bucle. Nada de un torrente de alertas: un resumen diario, con niveles de severidad, que llega antes de que el equipo empiece la jornada. El KPI de verdad de un sistema de monitorización no es cuántas anomalías detecta, sino cuánto se confía en él (y la confianza se gana siendo preciso y honesto sobre lo que no sabe).

5. Lo que nos llevamos (y vale para cualquiera)

Más allá de nuestro caso, un puñado de ideas que sirven para cualquier sistema que vigile datos de medios, o datos, en general:

«Todo normal» no es «todo bien». Un dashboard en calma no prueba que haya salud; puede probar que has dejado de medir.

Vigila la ausencia de lo bueno, no solo la presencia de lo malo. El fallo más caro casi nunca es un número feo: es un número que debería estar y no está.

Todo ratio esconde un denominador que puede traicionarte. Vigila numerador y denominador por separado, no solo el cociente.

Compara cada cosa con su propio pasado y su contexto, no con un umbral universal: lo «normal» de un canal es anómalo en otro.

Un monitor falla de dos maneras (no ver lo que pasa y ver lo que no pasa) y la frescura del dato está justo en el centro de ambas.

Trata tu monitorización como un producto: tiene bugs, regresiones y puntos ciegos propios. El día que asumes que «ya está hecho» es el día en que empieza a mentirte.

6. La red de seguridad, y por qué cada vez importa más

Es tentador leer todo esto como una anécdota técnica: un mapeo de conversión que no se propagó, un detector que no se enteró. Pero el fondo es más grande, y va a más.

Cada vez automatizamos más capas de la operación de medios: la puja, el reparto de presupuesto, la optimización, incluso el control de calidad del setup. Y todas esas automatizaciones beben del mismo sitio: el dato del data warehouse. En el momento en que ese dato deja de reflejar la realidad —en silencio, como nos pasó—, no es un informe el que se equivoca: es cada decisión automática que cuelga de él. La capa de monitorización es la red de seguridad de todo lo demás, y sus puntos ciegos dejan de ser un problema local para convertirse en riesgo sistémico.

Por eso el trabajo no acaba en detectar caídas a cero. El siguiente paso es hacer la red más lista: líneas base por entidad, umbrales que entienden la estacionalidad, alertas que no solo dicen qué se rompió sino que apuntan al porqué, y —en el horizonte— detección conectada a una respuesta automática.

Por ahora basta con un cambio de mentalidad. La próxima vez que un panel esté tranquilo, todo en verde, en calma, merece la pena hacerse la pregunta incómoda: ¿está todo bien… o es que se nos está escapando algo?

Alex Masip Data & Martech Director MIO One