Anomaly detection automatically spots unusual queue behavior in real time and alerts supervisors proactively. Anomaly detection uses historical interaction data to train detection models and establish expected patterns for each signal of a monitored queue. The amount and quality of historical data available can affect whether a queue is eligible for monitoring and the reliability of anomaly detection results. The availability of historical data helps sharpen prediction and then flag anomalies.
While you can still enable anomaly detection on newer queues or queues with less data, the Anomaly Detection Dashboard results may not return any useful data. Review the best practices outlined below to derive the maximum benefit from anomaly detection.
Queue eligibility
Queues with sufficient historical interaction volume are eligible for anomaly detection monitoring. To initially enable anomaly detection for a queue:
- The queue must have at least 20 interactions per day for one or more days.
- The queue’s average interaction volume, aggregated across supported media types, must exceed 20 interactions per day over the previous six weeks.
You can still enable new queues with less than six weeks of historical data for monitoring. For periods where historical data is unavailable, the system returns zero values. After you enable anomaly detection for an eligible queue, the detection models can take up to 30 minutes to become operational and begin detecting anomalies for that queue.
Anomaly detection accuracy generally improves as more historical training data becomes available. Optimal performance is typically achieved with approximately six to eight weeks of historical data, after which additional accuracy improvements begin to plateau. Minimum data thresholds can vary depending on the anomaly detection algorithm.
Insufficient or unreliable historical data
A queue can meet the interaction-volume requirements and be enabled for monitoring but still have a data profile that does not support a reliable detection model for a particular signal. When sufficient or reliable historical data is unavailable, anomaly detection provides a best-effort analysis. If confidence scores are low across all detection models, the system can fall back to a single anomaly detection model for the analysis.
Sparse data
The amount of data available for individual signals can change after a queue is enabled for monitoring. If the data for a particular signal becomes too sparse, anomaly predictions for that signal are less reliable. Sparse data can also affect the expected range used to identify anomalies. When a signal does not meet the minimum data threshold, the upper and lower bounds might be less accurately informed by recent data and can rely on historical bounds instead.
For example, a queue might initially have sufficient interaction volume to support anomaly detection, but the number of transferred interactions can subsequently decrease or occur sporadically. In this case, anomaly detection results for the Interaction Transferred signal might be less reliable even though monitoring remains enabled for the queue.