Anomaly detection on metrics

Anomaly detection on metrics is an ongoing (monthly) service with an initial setup: we connect your metrics (from analytics, BI, a database), define what counts as normal (accounting for trend, seasonality, days of week), set up deviation-detection algorithms and thresholds, and send an alert when a metric drops or jumps anomalously. Honestly about the nature, this is key: the detector finds STATISTICAL deviations from the expected, but does NOT explain the cause and does NOT prove it — why a metric deviated needs investigation (correlation ≠ cause); an anomaly is a reason to check, not a diagnosis. Honestly about accuracy: thresholds are a balance; both false positives (a planned promo, a holiday) and misses (gradual degradation) are possible — we calibrate, but a 'perfect' detector does not exist; on small volumes and noisy metrics the signal is less reliable. Honestly about data: the detector works on what is fed in — wrong or incomplete data gives a false picture (garbage in, garbage out). Honestly about the essence: this is detection and alerting, NOT fixing and NOT metric growth — someone must react to an alert and investigate; the detector itself does not fix the problem or raise the metrics. Requirements: access to metrics/sources, an alert channel. An important boundary: this is anomaly detection in business metrics, not site/infrastructure monitoring (a separate service group), not analytical root-cause analysis and not forecasting. If there are few metrics and they are stable, manual review may suffice. Picture this: instead of 'at the end of the month we saw revenue had dropped since mid-month' you get a signal on the day of the deviation. The base price starts from 15,000 ₽ per month; it depends on the number of metrics and sources.

• You notice a key metric drop late, after the fact.
• You cannot tell normal fluctuations from a real anomaly.
• There is no one to watch all metrics manually.
• Seasonality throws off manual 'normal or not' judgment.

• Connecting metrics (analytics, BI, database)
• Defining normal with trend and seasonality
• Setting up detection algorithms and thresholds
• Alerts on anomalous deviation (drop/spike)
• Calibration to reduce false positives
• Monthly operation and tuning
• An alert channel of your choice
• Handover of access and an instruction

• Metric anomalies are caught early, not at period end
• Fewer false alarms thanks to seasonality handling
• Team attention only to real deviations
• A signal to investigate (root-cause and fix — separately)

• We clarify metrics, normal, seasonality, the alert channel; collect access
• We set up detection and thresholds, calibrate on history
• We launch operation, tune on real triggers

• Will the detector say why a metric dropped?

  No. It finds a statistical deviation from the expected and signals, but does not explain or prove the cause (correlation ≠ cause). An anomaly is a reason to check and investigate; root-cause analysis is separate analytical work.

• Will there be false positives?

  Both false ones (a promo, a holiday) and misses (gradual degradation) are possible — it is a threshold balance. We calibrate with seasonality to reduce them, but a perfect detector does not exist; on noisy metrics the signal is less reliable.

• Will this raise my metrics?

  No. The detector detects and alerts, but it does not fix or grow the metrics. Someone must react to an alert and take action; growth is separate work.