Skip to main content

Anomalies Vs Alerting

Anomaly detection and alerting are related, but they are not the same thing. An anomaly is a deviation from normal expectations. When looking at your analytics data, an anomaly can be the symptom of many things. It could be a business issue, a technical variation, or simply a seasonal shift.

You should not react to an anomaly the same way you react to an alert. You raise an alert when you judge that an anomaly needs to be addressed properly.

ARIMA-based anomaly detection is useful, but it is not free of false positives and false negatives. Receiving an anomaly signal is a call for investigation; an alert is a signal that an incident has occurred and requires action.

To use this module effectively, it is important to understand the distinction between these two concepts before building alert logic on top of the anomaly detection output.

How they work together​

A practical setup is a two-layer design:

  1. Detection layer: produce anomaly candidates from data.
  2. Alerting layer: apply business rules and notify only when action is needed.

Example:

  • Detection says: conversion rate for one channel is outside expected bounds.
  • Alerting rule says: trigger only if this persists for 2+ days and impacts revenue above a threshold.
  1. Use anomaly_detection_report as the detection source of truth.
  2. Define downstream alert criteria by case, metric criticality, and persistence.
  3. Track alert precision and tune thresholds (anomaly_prob_threshold, strong-series criteria).
  4. Keep a suppression list for known seasonal or campaign-driven spikes.