This article describes how to work with Influencing Events, and includes the following:
- What are Influencing Events?
- How to use Influencing Events
- How are Influencing Events different from seasonality?
- Other things to consider
- Common questions
What are Influencing Events?
Influencing events help reduce false positives in Alerts. They can also help identify real anomalies: for example, in the scenario where a recently run sale event did not lead to the same amount of sales as previous sale events.
How is it done? By adjusting the metric baseline near the event, either before or after the event is taking place.
To understand the logic, consider this example: Christmas is an annual event. It has multiple effects, upwards or downwards, before or after the event itself:
- For organizations measuring revenue from sales - the days BEFORE Christmas are SPIKE days.
- For transportation firms - Christmas day is a DROP day, as people tend to stay at home that day.
Anodot learns the behavior of the metrics around the previous occurrences of the event. Then Anodot will update the baseline for the upcoming event, taking into consideration the previous influences based around that event.
In a nutshell - and using the example above - Anodot checks what happened during Christmas last year and the year before that, so we know what to expect this coming Christmas.
How to use Influencing Events
Follow these simple steps to setup Influencing Events:
- Inject the historical events (by using the Events API - refer to the Events Standard Authentication section) and the upcoming events you are interested in.
- Include the events in relevant alerts.
- This is done by clicking on the Show more conditions button in the in the Alert Conditions section when creating alerts. In the Events section, click Add > Influence.
- You can define one or more influencing event conditions within an alert. Note that you can also map properties in each user event group to dimensions in the alert metrics; this ensures that selected properties influence selected dimensions.
How are Influencing Events different from seasonality?
Anodot’s baseline algorithms recognize mathematical seasonality behavior in metrics. Mathematical seasonality means the metric behavior repeats itself at fairly regular intervals.
For example: the weekend rise in revenue at DIY shops, or the morning increases in employee logins on a daily basis around 09:00. Anodot finds these seasonal patterns and caters for them.
However, when considering an “end of month” payment surge, it gets a little trickier. Even though it is easy for humans to consider “end of the month” as a recurring pattern, this is not a mathematically valid season. It may occur somewhere between 29-31, might move due to the weekend falling on the last day of the month, and so on. The mathematical seasonality recognized by Anodot won’t work here.
So what will work? If we mark the “end of the month” surge as an event in the past, this enables Anodot to consider it as an influencing event in the future.
Furthermore, influencing events are not necessarily periodic, they just “occur” and influence the metric behavior.
Other things to consider
- For the most accurate analysis, Anodot needs 2-3 previous occurrences of the event and its metric information to learn the real influence of the event.
- Each event has a window of influence. This means Anodot considers baseline changes within the proximity of the event, and that proximity is limited to a number of intervals (see details below). To understand how this works, let’s consider the Christmas example:
- Anodot will consider the Christmas event for “Daily alerts” for a few days before the actual day, and a few days after it has actually taken place.
- For an hourly alert, the event will impact a 24-hour window. This means you need to specify the event time for the middle of the Christmas day event itself.
- On some occasions, you may need separate events for daily and hourly alerts.
- The event should be within Anodot at least one interval before the expected impact, otherwise, it will not be considered in the calculations of how it is actually influencing.
| Alert timescale | Window of influence |
| Weekly | +- 4 weeks |
| Daily | + - 7 days |
| Hourly | +- 24 hours |
Common questions
This section includes some common questions (and their answers) you might have regarding Influencing Events.
- How would the Influencing Events work for holidays that fall in a specific, predictable pattern?
- How many historical occurrences are enough to pick up changes in behavior?
- Can Influencing Events be applied to any other timescale other than daily, such as hourly?
- Do metrics have to be stable over a two-year period?
- How do I get this to work in an on-prem environment?
How would the Influencing Events work for holidays that fall in a specific, predictable pattern?
Below are the dates for Ramadan over the past few (and upcoming) years, As you can see, these dates fall in a specific predictable pattern.
|
Year |
First Day of Ramadan |
Last Day of Ramadan |
|
2018 |
May 16 |
June 14 |
|
2019 |
May 6 |
June 4 |
|
2020 |
April 24 |
May 23 |
|
2021 |
April 13 |
May 12 |
|
2022 |
April 3 |
May 2 |
|
2023 |
March 23 |
April 21 |
|
2024 |
March 11 |
April 9 |
|
2025 |
March 1 |
March 30 |
So, how would the Influencing Events work in this context?
Influencing Events don't care if it is a predictable or unpredictable pattern. As long as the date of the event is put into the system before the event happens (one hour before is the current minimum), it will be used. Anodot includes by default a list of all holidays per country around the world for the next few years - you can push them into any account for use in the future.
How many historical occurrences are enough to pick up changes in behavior?
In short, you only need to specify the dates of the holidays and Anodot will then pick up the expected change in behavior based on two historical occurrences.
For example, if you have no historical data collected and start to send data from 2021, the Influencing Events will only effectively work in 2023. Note that it is possible to force the code to learn the impact with just one instance of the event - but it will represent only that one instance.
Can Influencing Events be applied to any other timescale other than daily, such as hourly?
Currently, Influencing Events can work for daily and hourly timescales. In theory, they work with any timescale - but there may be performance issues (for example, S3 retention increase will be needed, depending on the timescale).
Note that annual sales events that typically take place at one time of the year can be moved to another date. For the Influencing Events, it doesn't matter that the date is moved - all that matters is that the event is injected into the system at the new date. The impact will be the same.
Do metrics have to be stable over a two-year period?
Influencing Events work on a per metric basis - so the metric has to stay the same metric for that period, without any changes to measures or dimensions.
How do I get this to work in an on-prem environment?
The main difference for an on-prem environment is data retention for offline tasks (these may have an impact on node specifications).
As in the annual Ramadan event example above, an on-prem deployment may need some substantial changes to its HW specifications. In addition, the lack of support for any timescale other than hourly, and the fact that most operators will not have historical data readily available for a two year period mean there may be a long wait before any results are seen.
Of course, no machine learning algorithm works without data, so to get your on-prem environment working with Influencing Events, you may need to make some HW changes.
