Seasonal
Seasonal alerts can be thought of as an extension of ‘Smart’ alerts, used when known seasonalities exist in the data and should be accounted for
Configuration parameters
Parameter name  Parameter values 
1. Name  Arbitrary String 
2. Sensitivity
Typical start value: 3 
Positive float value 
3. Error smoothing
Typical start value: 10 
Positive float value >= 1 
4. Level smoothing
Typical start value: 5 
Positive float value >= 1 
5. Trend model type 

6. Trend smoothing
Typical start value if used: 10 
Positive float value >= 1 
7. Seasonal model type 

8. Seasonal period
Period of seasonality  domain knowledge required 
Positive integer value 
9. Seasonal smoothing
Typical start value if used: 3 
Positive float value >= 1 
10. Decision bounds type 

Setting the right parameter values is often an iterative process in the beginning to balance false positives and alert fatigue vs. false negatives and missing out on real errors. Apart from the seasonal period parameter which requires domain knowledge  finding the right values for the other parameters will be an iterative process
Let your data scientist or someone who are familiar with the data and its seasonality help you set up the parameter values for a seasonal alert
Parameter details
It’s helpful to have a highlevel understanding of the math behind the seasonal alert when setting the parameters. While not a full mathematical treatment, we’ll give a highlevel explanation of the different components and how to think about them when setting the parameters.
The range of accepted values set by the seasonal alert can be thought as being a function of four components:
Accepted range = f(s_{t+1}, e_{t}, Trend, Seasonality)
Let ‘t’ denote the timestamp of the latest calculated metric. t1 the second last calculated metric, conversely, t+1 the next calculated metric we are yet to observe.
 S_{t+1}  point forecast of the next metric, think of it as the ‘midpoint’ of the accepted range in t+1
 e_{t}  error between the actual observed metric and St (past prediction)
 Trend  the trend component
 Seasonality  the seasonality component
Sensitivity
Like smart alerts, higher sensitivity on the alert means that more alerts will be identified  i.e. the accepted range of values will be narrower. Conversely, lower sensitivity values implies a wider range of accepted values. Sensitivity regulates how the accepted range is impacted by e_{t.}
Error smoothing
Higher smoothing values implies more historic error terms (e_{t}) are taken into account when calculating the accepted range.
Use higher smoothing when the accepted range should react less to transient shifts, lower smoothing when the accepted range should reach more to transient data shifts.
Level smoothing
Higher smoothing values implies more historic forecasted terms (S_{t}) are taken into account when calculating the accepted range.
Use higher smoothing when the accepted range should react less to transient shifts, lower smoothing when the accepted range should react more to transient data shifts.
Trend model type
Additive
Trend is additive (linear). Example:
“Number of ice creams sold increases with 100 units each week”
Multiplicative:
Trend is multiplicative (exponential). Example:
“Number of ice creams sold increases with 10% each week”
Not used:
Select when no trend in the data exists
Trend smoothing
Same concept as other smoothing parameters (see Error and Level smoothing)  applied on the trend component.
Seasonal model type
Same concept as the Trend model type  applied on the seasonality component
Seasonal period
Important parameters requiring domain knowledge to set. Seasonality is dependent on how often a Metric is calculated (configured when setting up a Dataset pipeline). Examples:
 We monitor and compute average sales volume each day knowing that each Friday, sales volume spikes. Seasonality period should be set to 7
 We monitor and compute average energy generation from solar panels each hour, knowing peak energy production is around noon. Seasonality period should be set to 24
Seasonal smoothing
Same concept as other smoothing parameters (see Error and level smoothing)  applied on the seasonality component.
Decision bounds type
Decision bounds types specifies whether the boundaries should be double or single sided.
 Upper and lower: Both upper and lower anomalies will be detected
 Upper: Only deviations upwards will be treated as anomalies, deviations downwards will never be considered anomalous (used e.g. for freshness validations monitoring time since last update, and 'too fresh' data should not be alerted for)
 Lower: Only deviations downwards will be treated as anomalies, deviations upwards will never be considered anomalous
Updated about 1 month ago