The idea behind the Simple Moving Average (SMA) is to take the average of the last few observations and use it as a forecast for the next several steps ahead. Very crude and very simple. In fact, it has Naive (from this post) as a special case if you take the average of one most recent observation. On the other hand, if you increase the order to include all the observations, you will end up with the Global Mean. And this simple method works quite well if you have level data, i.e. no apparent strong trend, no obvious seasonality, and no other important elements of structure.

The only thing that makes it a bit harder to use in practice is the choice of the order, i.e. the number of observations to average over. Unfortunately, there is no universal answer here. But people report that the order of 12 or 13 is fine for weekly data, although it’s not completely clear why. In the academic literature, Aris Syntetos & John Boylan (2005) found that SMA(13) performed quite well on intermittent demand data, which was unexpected given the nature of the data (lots of zeroes). And almost 10 years ago, Fotios Petropoulos and I proposed a model underlying SMA with automatic order selection. We showed that it outperforms other simple benchmarks on supply chain data.

There is also some evidence from the VN2 inventory competition by Nicolas Vandeput. The benchmark there was built around a 13-week moving average with a simple seasonal adjustment, and only 25 out of 180+ participants managed to beat it. Many sophisticated ML pipelines lost to a method that predates computers.

So, if you work, for example, in retail or in supply chain, SMA is a method to consider for your sanity-check pool of models. But don’t expect miracles from it! It is still a simple method that works for level time series. Use it as a stepping stone to find a better model that has more features.

Anyone else found SMA to be a strong contender? Leave a comment – it would be interesting to see how many of you have had the same experience.

And yes, we discuss it in our “Demand Forecasting Principles” training in more detail. The next one will be held online in November, with live sessions from 2pm to 4pm UK time. We still have a few places left, so register here.

Message The Menace of ML: Simple Moving Average first appeared on OpenForecast.

One of the definitions I see on the internet: “A measure of the degree to which something may be forecast with accuracy”. This definition is so disturbing that I cannot resist ranting about it. The thing that annoys me the most is the “with accuracy”, which is really arbitrary and can mean anything. Your Naive method produces a relative RMSE of 1.0. Is that accurate enough? Does this make the time series forecastable? What if ETS produces 1.2, while LightGBM delivers 0.8? Is the data forecastable now? And when do you say “this is fine”?

But let me breathe and take a step back. The thing is, any method of measuring forecastability has assumptions behind it. Here is my list of five (did I miss any?):

1. The models you use: each time series has its own characteristics, so you can only say that the data is “forecastable” given the set of models you have. The data with trend might look unforecastable for the model that only has the level component.
2. The features/indicators that are available: if you do not know when promotions happen, some observations will look unforecastable. It’s a similar argument to (1), but more about what you include in your model. If you spend more time on feature generation and transformation, then the series that looked very hard might become quite easily forecastable.
3. The statistic you focus on: this could be the conditional mean, the median, some quantile, or the whole predictive distribution. A model can do great in terms of point forecasts but very poorly when it comes to prediction intervals. Does that make the time series unforecastable? Which one do you care more about?
4. The forecast horizon: the longer it is, the less accurate the forecasts become. One-step-ahead forecasts are easy, multiple steps ahead are hard. Which one do you use to measure forecastability?
5. The error measures: I’ll just leave this here: https://openforecast.org/category/forecasting-theory/forecast-evaluation/

Do I hear someone mentioning the coefficient of variation (CoV) as a good measure of forecastability? This is, by the way, what is used in the conventional XYZ classification. Well, let’s check the five points above against it and see what it assumes: (1) the global mean is suitable and the variance is constant; (2) no features are available; (3) conditional mean as the statistic of interest; (4) 1-step-ahead point forecast; (5) Root Mean Squared Error (the core of the CoV). So, it is suitable for a very small set of time series. If you use it universally, you might decide that some time series with a very clear structure are not forecastable. And the same exercise works for the more sophisticated measures, entropy-based ones included: run them through the five questions and see what they silently assume.

And then we come to the final point: so what? Let’s say you split your data into the “forecastable/not” categories. What are you going to do with that? The intention behind this is legitimate — you cannot babysit ten thousand SKUs equally, so you want to know where to spend your time. But the label “unforecastable” answers the wrong question. The right question is why the series is hard to forecast: missing promotion information? Wrong model? Genuinely random demand? Each of these implies a different action. It might well be that your “unforecastable” time series just require more time and effort to become forecastable again.

We don’t teach “forecastability” in our Demand Forecasting Principles course — because, as you can see, I don’t believe in it. What we do teach is everything in the list above: models, their assumptions, features, horizons, and how to evaluate forecasts properly. See details about the next course here.

This is my personal view. Happy to hear what others have to say.

Message Five assumptions behind “forecastability” first appeared on OpenForecast.

In the conventional ARIMA, taking differences is treated as a pre-processing step, where we switch from, for example, the sales of a product to the sales increase/decrease. If you had a sample of 100 observations, after first differences you are left with 99 – the first observation has nothing to be subtracted from. So yes, with the conventional approach, ARIMA(1,0,1) and ARIMA(1,1,1) are estimated on different sample sizes, and their information criteria are not directly comparable.

But! MSARIMA (and ADAM in general) is a state space model, and this pre-processing step is not needed. The differences are embedded in the model as additional components: ARIMA(0,1,1) has one, ARIMA(0,2,1) has two. The sample stays the same; what changes is the number of estimated parameters – each new component needs its initial value, and the information criterion penalises that. So the comparison stays fair: same sample, same likelihood basis, different number of parameters. I have several examples of how ARIMA is formulated in the ADAM SSOE framework.

What this implies: any ARIMA model of any orders (non-seasonal, seasonal, or multiseasonal) can be compared with other ARIMA models directly via information criteria, on the same sample of data.

This is not a new idea, by the way. I used this approach in the ARIMA algorithm I developed for the DemandWorks company (now part of Netstock) more than ten years ago, and John Boylan and I later built the State Space ARIMA on the same principle (the paper).

So, yes: if you use the conventional ARIMA (auto_arima from pmdarima, ARIMA from aeon or statsforecast in Python; stats or forecast implementations in R), you NEED to make sure that you compare models with the same order of differencing. But if you use the smooth implementation, you don’t need to worry – everything is already taken care of for you. This comes as a bonus from the specific formulation of the model.

Message On differencing of ARIMA in state space first appeared on OpenForecast.

What’s greybox? It is a package for statistical modelling focusing on forecasting and time series analysis. I created it back in 2018 to split the static models (such as linear regression) from the dynamic ones that landed in the smooth package. Greybox has evolved since then, and now has linear regression (alm), regression selection (stepwise) and combinations (calm), a variety of tools for feature generation, diagnostics, forecast evaluation (e.g. rolling origin) etc. You can read more about it here. Originally, the package was available for R only, but Claude and I ported its main functions to Python back in February.

The Exploratory Data Analysis techniques for time series fit the package quite well, although I don’t have many of those yet. So, I’ve implemented the main idea of the STI of Hans Levenbach in a function called “stick” (Seasonal, Trend, Irregular Contribution Kit) in the greybox package for R/Python. The idea is straightforward: apply stick to a time series, it will use ANOVA, and give you the strength of each component. Here, for example, is how to apply the function to the AirPassengers data (everyone’s favourite toy time series) in R:

library(greybox)
stick(AirPassengers)

and in Python:

from fcompdata import AirPassengers
from greybox import stick

result = stick(AirPassengers.y, lags=12)
print(result)

which gives exactly the same result:

Strength of the components:
seasonal12      trend  irregular
    0.1061     0.8613     0.0326

So, trend dominates the time series, explaining 86.13% of its variability, meaning that if you capture it correctly, you solve a big chunk of the problem. This split also gives you a rough idea about the structure-versus-noise breakdown in the time series, although it assumes that the seasonal component does not evolve over time.

The function supports several seasonal components, and I might extend it to include external information (e.g. promotions) in the future if there is demand for it.

Message stick function for the EDA in time series first appeared on OpenForecast.

The core idea is simple and neat. For this example, I’ll use monthly data, like the time series in this image:

You can see that the data has strong seasonality, and we can qualitatively say that capturing that seasonal component correctly will probably solve the main problem in capturing the structure. But how can we quantify this?

All you need to do is put the data in a “wide” format, with months in rows and years in columns. Then, as Hans proposed, run a two-way ANOVA with “month” and “year” to capture variability due to year (trend) and due to month (seasonality). Roughly, we take row/column means to get mean seasonal profiles and mean annual changes (trend), as in the following two images:

The former has no trend, the latter has no seasonality, so they can be analysed separately. Then we calculate the sums of squares of these means from the global mean to estimate variation due to months (seasonality) and years (trend). We can also calculate the sum of squares of the irregular component (what is left), giving three elements that add up to the total sum of squares.

Next step is trivial and straightforward: calculate the shares of each component in the total sum of squares. For our example, using aov() in R and then computing the total:

Seasonal:  292,307,558
Trend:     176,308,365
Irregular:  33,618,630

Total:     502,234,552

So, the seasonal contribution is 292,307,558 / 502,234,552 ≈ 58.2%, the trend contribution is 35.1%, and the irregular component is 6.69%.

Why bother? This simple EDA technique tells you roughly what to focus in forecasting. In this example, capturing seasonality correctly is roughly 60% of the story, with trend being second in importance. Hans goes further in his derivations, see his LinkedIn post. He also analysed M3 results at some point, explaining why some methods performed better (trend dominated the data).

It is worth pointing out that this approach assumes that the seasonal component does not evolve over time, which is reasonable but not always correct. And the model behind this is essentially a regression with dummy variables for year and month. Nonetheless, it is a great starting point for EDA.

P.S. Hans Levenbach passed away on 7 April 2026. I wasn’t sure whether to write about it and what to write about him, but I had several nice discussions with him, and I have admired his approach to forecasting: first explore the data, then build a model. His passing is a loss for the forecasting community.

P.P.S. You can read a bit about him on the IIF website.

CMAF had a webinar with Hans a couple of years ago. We had technical issues, but he managed to explain his idea well.

Message Hans Levenbach’s classification scheme for trend/seasonal components first appeared on OpenForecast.

When I test my functions in R, I usually use the M1, M3, and tourism competition datasets because they are diverse enough, containing seasonal, non-seasonal, trended, and non-trended time series of different frequencies (yearly, quarterly, monthly). The total number of these series is 5,315, which is large enough but not too heavy for my PC. So, when I run something on those datasets, it becomes like a stress test for the forecasting approach, and I can see where it fails and how it can be improved. I consider this type of test a toy experiment — something to do before applying anything to real-world data.

In R, there are the Mcomp and Tcomp packages that contain these datasets, and I like how they are organised. You can do something like this:

series <- Mcomp::M3[[2568]]
ourModel <- adam(series$x)
ourForecast <- forecast(model, h=series$h)
ourError <- series$xx -
            ourForecast$mean

Each series from the dataset contains all the necessary attributes to run the experiment without trouble. This is easy and straightforward. Plus, I don’t need to download or organise any data — I just use the installed package.

When I started vibe coding in Python, I realised that I missed this functionality. So, with the help of Claude AI, I created a Python script to download the data from the Monash repository and organise it the way I liked. But then I realised two things, which motivated me to package it:

1. I needed to drag this script with me to every project I worked on. It would be much easier to just run "pip install fcompdata" and forget about everything else.
2. Some series in the Monash repository differ from those in the R package.

Wait, what?! Really?

Yes. The difference is tiny — it’s a matter of rounding. For example, series N350 from the M1 competition data (T169 from the quarterly data subset) has three digits in the R package and only two if downloaded from the Monash repository (Zenodo website).

Who cares?! It's just one digit difference, right?

Well, if you want to reproduce results across different languages, this tiny difference might become your nightmare. So, I care (and probably nobody else in the world), and I decided to create a proper Python package. You can now do this in Python and relax:

pip install fcompdata

from fcompdata import M1, M3, Tourism
series = M3[2568]

The "series" object is now an instance of the MCompSeries class that has the same attributes as in R: series.x, series.h, series.xx, etc.

As simple as that!

One more thing: I’ve added support for the M4 competition data, which — when imported — will be downloaded and formatted properly. The dataset is large (100k time series), and I personally don’t like it. I even wrote a post about it back in 2020. But if I want the package to be useful to a wider audience, I shouldn’t impose my personal preferences — you should decide for yourselves whether to use it or not.

P.S. Submitting to PyPI gave me a good understanding of the submission process for Python and why it can be such a mess. My package was published just a few seconds after submission — nobody looked at it, nobody ran any tests. CRAN does a variety of checks to ensure you don’t submit garbage. PyPI doesn’t care. So, I’ve gained more respect for CRAN after submitting this package to PyPI.

Message Forecasting Competitions Datasets in Python first appeared on OpenForecast.

DISCLAIMER: the image in the post is taken from the paper, Figure 6, showing the proportion of GRP A&E admissions, the forecast errors and two detectors.

Here’s a brief summary of what it’s about:

One of the common issues in forecasting is that there might be some serious changes in the data due to external factors (e.g. changes in consumer preferences). These changes are not always captured by the model, which can lead to reduced accuracy, increased variance, and ultimately to losses. The changepoint detection literature addresses this by trying to automatically identify such structural changes and alert analysts when intervention might be needed. This becomes especially useful when managing large numbers of time series, where visual inspection isn’t feasible.

However, most existing approaches either work directly on raw data or rely on a model, which makes their usefulness limited.

Tom Grundy and Rebecca Killick came up with a better idea: analysing forecast errors instead. They kindly invited me to join as a co-author (since I know a thing or two about forecasting). The result is an online changepoint detection mechanism that is more universal and can be applied to classical statistical forecasting models and potentially to machine learning approaches.

The paper is quite technical and includes theoretical derivations, showing that the proposed method substantially reduces detection delay compared to some conventional approaches. We also evaluated its performance with ARIMA and ETS models on simulated data and provided several examples with real time series, demonstrating how it works.

The final version of the paper is available here, while the pre-print is here.

Message Online Detection of Forecast Model Inadequacies Using Forecast Errors first appeared on OpenForecast.

I understand why people use the term “Time series forecasting” – they want to show the type of data they work with and explain what they are doing. But there is no point in forecasting outside of time series. According to one of the definitions (I previously mention it here and here), “forecast is a scientifically justified assertion about possible states of an object in the future”, while forecasting is just a process of producing forecasts. So, the time is already embedded in the definition, and there is no need to add “time series” to it.

Furthermore, you cannot do “cross-sectional forecasting”. It wouldn’t be forecasting per se, but rather scenarios generation. For example, you can say that based on the collected cross-sectional data across several shops in our chain on Monday, the increase of price of a product should cause a decline in sales on average by some amount. You can even say what sales to expect if the price and other variables were somehow defined. But you cannot say what to expect in next week based on this data, because the cross-sectional data itself does not have dynamic element. It is good for scenario planning, but useless in forecasting.

Furthermore, when you say “time series forecasting”, you imply a wide area without any specificity. But there are many areas, where you can do forecasting which differ substantially from one to another. Are you doing “demand forecasting”, “revenue forecasting”, “price forecasting”, “volatility forecasting” or something else? While some approaches can be applied to many of these areas, they still have their specificity and own set of instruments and rules. So, you should always keep the specific domain in mind, otherwise you might do something unreasonable. For example, GAMLSS works very well in energy demand forecasting, but it does not necessarily perform as well in supply chain forecasting, where you often have short history and lots of zeroes.

But most importantly, forecasting should not be done for the sake of itself (see my old post from COVID times on this). If you “forecast a time series”, then you just do an exercise without a specific aim. Forecasting should inform decisions. Yes, you can show how cool you are, but is there anything beside that?

So, when I see statements like “This and that guy will talk in our webinar about time series forecasting”, I feel that the person has a poor understanding of forecasting itself and does not know what to talk about, because there is no specificity in such talk. It’s like presenting on the topic of “frequentist statistics” – too broad and too general.

I feel that this post might provoke some debate, so feel free to express yourselves in the comments! :)

Message Is there such thing as “Time series forecasting”? first appeared on OpenForecast.

First things first, in forecasting, the term “seasonality” refers to any natural pattern repeating with some periodicity. For example, if you work in a hospital with A&E attendance, you know that every Monday has higher demand than other days, while weekends tend to have lower demand. This is a well known phenomenon: people have fun over the weekend and then go to hospital first thing in the morning of the work week, so if you don’t want to get stuck in the hospital, don’t injure yourselves over the weekend!

Anyway, back to the main topic of this post!

Consider the following example:

This is a daily data. Is it seasonal? Without context, you might assume so: there’s a midweek peak followed by a decline, repeating weekly, so it must be seasonal, right? But what if I told you that this data is daily LinkedIn impressions of my posts? The peaks coincide with posts releases, and it is hard to tell from the image, but I released first three posts on Thursdays and then switched to Wednesdays, shifting peaks one day forward. So, this is not a seasonal data, but instead it is a classical life cycle (which can be described, for example, by the Bass model), repeating every week. It would be seasonal if the impressions happened naturally without me releasing anything. For example, number of visitors of my website has natural seasonality, because they happen without my interventions:

Bringing this to a business context, I have encountered several times the “spurious seasonality”. For example, one company, working with weekly data, used a seasonal model with periodicity of 4, because they noticed that at the end of each month, people get their salary and spend it, increasing the sales of the company. However this is not true seasonality, but rather a calendar event that happens seemingly periodically, on a specific day of month (not necessarily the same one).

Why is this important?

Relying on a seasonal model (like seasonal ETS or ARIMA) in such cases poses risks. If the periodicity shifts (e.g., salaries received on a different week), the model will produce misaligned forecasts (e.g., predicting an earlier peak). To address this, you should model such events with explanatory variables instead of seasonal indices. This way you will be able to control the timing of the event in your model and adjust it if needed.

So, next time you see a pattern that looks seasonal, think whether it happens naturally, or whether you are dealing with the spurious seasonality. Remember, the context is always important!

Message Seasonal or not? first appeared on OpenForecast.