Simple statistics for anomaly detection on timeseries data
Anomaly detection is a type of data analytics whose goal is detecting outliers or unusual patterns in a dataset.
When working with timeseries data (time based network, systems or operational metrics) having a mechanism to detect contextual anomalies is useful to take action on potential risks (such a DDoS attack), system failures and corrections (like a sudden decrease in stock or sales) or business opportunities (such as an unexpected raise on a product’s sales).
Zscore to the rescue ¶
You can detect contextual anomalies in timeseries applying simple statistics, such as Zscore.
The Zscore measures how far a data point is away from the mean as a signed multiple of the standard deviation. Large absolute values of the Zscore suggest an anomaly.
zscore = (x  avg) / stddev

x
is the current value of the data point you are evaluating 
avg
is the mean of the population 
stddev
is the standard deviation of the population
Testing a Zscore based algorithm for anomaly detection ¶
Let’s see an application of the Zscore for realtime anomaly detection:
In the graph above, the xaxis represents time and the yaxis a quantity. We want to get notified when such kind of an anomaly takes place in the data, in this case an unusual decrease in the quantity.
First thing is choosing a data context:
In timeseries, nearby data points tend to be more similar than far away data points.
That means most of the time the best context is last n
minutes of data given a data point you want to evaluate. Or if you want to take into account seasonality, the same period of time for the previous day, month or year.
A very basic anomaly detection algorithm would be:
 Take 30 minutes of data prior to a given timestamp.
 Remove outliers from the sample, and calculate the average and standard deviation of your metric (you could use median based statistics as well).
 Calculate the Zscore for a series of data points, comparing to the context average and standard deviation.
 To avoid locality in the anomalies, do some aggreggations. For instance, you can work in groups of ten seconds and consider an anomaly if the Zscore is beyond the threshold during a period of time.
 Return ‘ok’ or ‘error’ depending on the Zscore value, a threshold of ±2 would work.
In the graph above, for any period in which the zscore is under 2 (which is a value that makes sense statistically) the anomaly status is 1 which means there’s a contextual anomaly, otherwise it’ll return 0.
You can find here an example of a Zscore based anomaly detection algorithm written in SQL.
Realtime anomaly detection ¶
Anomaly detection systems are really valuable when you can react to unexpected events as they happen. You need a product that has at least these three features:
 Able to handle large production datasets, updated very frequently, ideally from an events stream (think for instance in the volume of HTTP requests coming from a CDN provider)
 Customizable: Even when you use an algorithm that can learn from itself, it’s sometimes required some domain knowledge to support corner cases, avoid false positives, etc.
 Easy to integrate: Anomaly detection is just one step of the process, but then you might need integrate to an alerting system, a visualization software to understand or explore the data, or some capabilities for actionable outputs.
Caveats ¶
Some caveats when manually building this kind of anomaly detection processes:
 Normalize your data: quantities in the same units, dates in the same timezone, etc.
 When talking about realtime, make sure everyone understands it as something that happened in the last 10 to 20 seconds.
 Avoid false positives as much as possible. There’s nothing worse in an alerting system, than being notified from events that don’t require your attention.
 Add context to your notifications: a graph snapshot of the timeseries and data point that fired the alert, brief explanation on the reason, thresholds configured, actionable links or tools for further exploration, etc.
A real example ¶
One of Tinybird’s customers, a large retailer, wishes to be notified of sudden changes in their sales numbers. If something is preventing sales or causing sales to spike, they want to know about it immediately.
How we do it:
 We ingest all sales transactions in realtime using our Kafka Connector.
 Since the transactions are in JSON, we extract and materialize on ingestion all the values we need onto another Tinybird data source.
 We write our anomaly detection logic in SQL in a Tinybird Pipe that we expose as an API endpoint.
 We query the endpoint every X seconds: if we detect an anomaly, an alert is triggered (in this case, a message in a Microsoft Teams chat)
Alerts of course is just one way to exploit realtime data. What’s interesting about doing this with Tinybird is that, once you have ingestion set up, you can do many more things with that data.
Those transactions can be used for realtime analysis, to build data products such as operational dashboards, to build analytics for endconsumers, to expose APIs for other areas of the organization and much more. Every new use case is just one SQL query away.