Time series decomposition<\/strong> is the statistical technique that separates a time series into its component parts: trend, seasonality, and remainder. It’s one of the most powerful diagnostic tools in the forecaster’s toolkit, and it’s been evolving for over a century \u2014 from the crude methods of the 1920s to sophisticated algorithms that can handle multiple seasonal patterns, holidays, and abrupt structural changes.<\/p>\n By the end of this post, you’ll understand not just how<\/em> decomposition works, but which<\/em> method to use for your specific data. That distinction matters more than most textbooks let on.<\/p>\n Mathematically, decomposition models a time series y_t as a combination of three components:<\/p>\n The question is: how do these three components combine?<\/p>\n In an additive<\/strong> model, the components simply add up:<\/p>\n y_t = S_t + T_t + R_t<\/strong><\/p>\n This means seasonal swings are roughly constant in absolute terms. If your product sells 200 extra units every December regardless of whether baseline demand is 1,000 or 5,000, that’s additive seasonality.<\/p>\n In a multiplicative<\/strong> model, the components multiply:<\/p>\n y_t = S_t x T_t x R_t<\/strong><\/p>\n Here, seasonal swings scale proportionally with the level. If December demand is always about 20% higher than baseline \u2014 whether baseline is 1,000 (so +200) or 5,000 (so +1,000) \u2014 that’s multiplicative seasonality.<\/p>\n Why this matters for your supply chain:<\/strong> Get this choice wrong and your seasonal factors will be systematically biased. Additive factors applied to multiplicative data will underestimate peaks at high demand levels and overestimate them at low levels. Your safety stock calculations, production plans, and procurement schedules all inherit that error.<\/p>\n The practical test:<\/strong> Plot your data. If the seasonal „amplitude“ (the distance from peak to trough) stays roughly constant as the level changes, use additive. If it grows proportionally with the level, use multiplicative. When in doubt, there’s an elegant trick: apply a log transformation<\/strong> to your data. Since log(S_t x T_t x R_t) = log(S_t) + log(T_t) + log(R_t), taking logarithms converts a multiplicative model into an additive one. Decompose the log-transformed series additively, then exponentiate back. Problem solved.<\/p>\n Most retail and consumer goods demand data is multiplicative \u2014 higher-volume products have proportionally larger seasonal swings. Most industrial and MRO data is closer to additive. But always check. Your data doesn’t care about rules of thumb.<\/p>\n Before we decompose anything, we need a way to estimate the trend. The classic tool is the moving average<\/strong> \u2014 and despite its simplicity, it’s worth understanding properly, because every decomposition method builds on this idea.<\/p>\n An m-order moving average estimates the trend at time t by averaging m consecutive observations centered around t:<\/p>\n T\u0302t = (1\/m) (y<\/em>{t-(m-1)\/2} + … + y_t + … + y_{t+(m-1)\/2})<\/strong><\/p>\n For odd values of m, this is straightforward \u2014 a 5-MA averages the two observations before, the current one, and the two after. For even periods (like monthly data with m = 12), you need a small adjustment: the 2xm-MA<\/strong>, which takes a moving average of the moving average to re-center it. A 2×12-MA is the standard approach for monthly data.<\/p>\n What you’re seeing:<\/strong> Lower-order moving averages (m = 3, m = 5) follow the data closely but don’t fully remove the seasonal pattern. Higher-order averages (m = 12 for monthly data) smooth out the seasonality entirely, revealing the pure trend underneath. The 2×12-MA is the sweet spot for monthly supply chain data \u2014 it removes the 12-month seasonal cycle while preserving the trend.<\/p>\n There’s a trade-off here that mirrors a fundamental tension in supply chain planning: responsiveness vs. stability.<\/strong> A short moving average responds quickly to changes but is noisy. A long moving average is stable but slow to react. Sound familiar? It’s the same trade-off you face choosing between responsive and stable safety stock parameters, or between short and long planning horizons in your MRP.<\/p>\n Weighted moving averages<\/strong> generalize this by assigning different weights to each observation (weights must sum to 1 and be symmetric). The 2×12-MA is actually a weighted MA where the first and last observations get half weight. This matters because it means the trend estimate is less influenced by extreme values at the edges of the window.<\/p>\n Classical decomposition has been around since the 1920s \u2014 longer than most supply chain concepts. It’s beautifully simple, which is both its charm and its fatal flaw.<\/p>\n For the multiplicative version, replace subtraction with division in steps 2 and 4.<\/p>\n What you’re seeing:<\/strong> The top panel is the original series. Below it, the smooth trend-cycle estimated by the 2×12-MA. Then the seasonal component \u2014 a repeating pattern that’s identical<\/em> every year (this is a critical limitation we’ll discuss). And finally the remainder, which should ideally look like random noise if the decomposition captured everything meaningful.<\/p>\n Classical decomposition is still taught \u2014 and still used in many supply chain organizations \u2014 but Rob Hyndman’s verdict in Forecasting: Principles and Practice<\/em> is blunt: „not recommended.“<\/strong> Here’s why:<\/p>\n These aren’t minor quibbles. They’re structural problems that make classical decomposition unreliable for real forecasting work. It’s like using a typewriter in 2026 \u2014 historically interesting, good for understanding the concept, but you wouldn’t build your production plan on it.<\/p>\n STL \u2014 Seasonal and Trend decomposition using LOESS<\/strong> \u2014 was developed by Cleveland, Cleveland, McRae, and Terpenning in 1990, and it remains the workhorse of modern time series decomposition. If classical decomposition is the typewriter, STL is the word processor.<\/p>\n Instead of simple moving averages, STL uses LOESS<\/strong> (LOcally Estimated Scatterplot Smoothing) \u2014 a form of local weighted regression that fits smooth curves through data points by giving more weight to nearby observations. The algorithm alternates between two nested loops:<\/p>\n Inner loop<\/strong> (runs multiple times per iteration):<\/p>\n Outer loop<\/strong> (for robustness):<\/p>\n This iterative LOESS-based approach is what gives STL its superpowers:<\/p>\n Evolving seasonality<\/strong> is the game-changer. In the real world, your December peak might be getting stronger every year as e-commerce grows. Your Q3 trough might be shifting as your customer base changes regions. STL captures this because it re-estimates the seasonal component at every time point, rather than averaging all Decembers together and assuming they’re identical.<\/p>\n STL has several parameters, but two dominate:<\/p>\n What you’re seeing:<\/strong> The same data decomposed with three different parameter settings. Narrow windows (left) produce a wiggly trend and rapidly changing seasonality \u2014 responsive but noisy. Wide windows (right) produce a smooth trend and near-constant seasonality \u2014 stable but potentially missing real changes. The middle ground is where the art meets the science.<\/p>\n The diagnostic trick:<\/strong> Look at the remainder. If it shows obvious patterns \u2014 clear seasonality, systematic trends \u2014 your decomposition hasn’t captured everything. Go back and adjust. A good decomposition produces a remainder that looks like white noise (random, unpatterned, centered on zero).<\/p>\n STL isn’t perfect. Two limitations matter for supply chain work:<\/p>\n One of the most valuable outputs of decomposition isn’t a forecast \u2014 it’s the seasonally adjusted<\/strong> series. By removing the seasonal component, you can see the underlying trend and unusual events without the seasonal noise:<\/p>\n Seasonally adjusted = y_t – S\u0302_t<\/strong> (additive)<\/p>\n Why supply chain teams should care:<\/strong> Seasonally adjusted data makes it much easier to detect real changes in underlying demand. Did that jump in March represent genuine demand growth, or was it just the seasonal March peak? Subtracting out the seasonal component gives you the answer. It’s also what central banks and government statisticians use when they report „seasonally adjusted“ GDP or employment figures \u2014 the same technique, applied at a very different scale.<\/p>\n STL was published in 1990. A lot has happened in 36 years. The core idea \u2014 iterative LOESS smoothing \u2014 remains sound, but researchers have extended it to handle increasingly complex real-world data. Here are three methods pushing the frontier.<\/p>\n MSTL (Multiple Seasonal-Trend decomposition using LOESS)<\/strong>, developed by Bandara, Hyndman, and Bergmeir, extends STL to handle data with multiple<\/em> seasonal patterns simultaneously.<\/p>\n Why does this matter? Because much real-world supply chain data has more than one seasonal cycle. Daily warehouse data might have both a weekly<\/strong> pattern (lower volumes on weekends) and an annual<\/strong> pattern (holiday peaks in December). Hourly electricity demand has daily<\/strong> cycles (morning ramp-up, evening peak), weekly<\/strong> cycles (weekday vs. weekend), and annual<\/strong> cycles (summer cooling, winter heating).<\/p>\n STL can only handle one seasonal period at a time. You could nest multiple STL passes, but the order of decomposition affects the results, and parameter tuning becomes a nightmare. MSTL handles all seasonal patterns in a single, principled algorithm \u2014 and with fewer tuning parameters than alternatives like Prophet or TBATS.<\/p>\n In fpp3, you can use MSTL directly with the STAHL (Seasonal, Trend, and Holiday Decomposition with LOESS)<\/strong> is a 2025 innovation from Quantcube Technology that adds something STL and MSTL can’t handle: an explicit holiday component<\/strong>.<\/p>\n Think about it: Easter moves. Chinese New Year moves. Ramadan moves. These events create demand spikes (or dips) that don’t align with fixed seasonal periods. STL dumps them into the remainder. Your seasonal factors end up contaminated by holiday effects that shift from year to year, and your remainder contains systematic patterns that aren’t truly random.<\/p>\n STAHL solves this with three key innovations:<\/p>\n The results are striking: in automated quality assessments, STAHL showed a 42% improvement<\/strong> over comparable methods on key decomposition quality metrics. For supply chain data with significant holiday effects \u2014 retail, food & beverage, consumer electronics \u2014 this is a major advance.<\/p>\n BASTION (Bayesian Adaptive Seasonality and Trend DecompositION)<\/strong> takes a fundamentally different approach. Instead of LOESS smoothing, it uses a Bayesian framework<\/strong> to decompose time series into trend and multiple seasonal components.<\/p>\n What makes BASTION interesting for supply chain applications:<\/p>\n BASTION is still relatively new and not yet part of the standard fpp3 toolkit, but it represents where the field is heading: probabilistic decomposition that quantifies what we know and what we don’t.<\/p>\n No discussion of decomposition is complete without mentioning the methods used by statistical agencies worldwide. X-11<\/strong> (developed at the U.S. Census Bureau) and SEATS<\/strong> (developed at the Bank of Spain) are the backbone of official economic statistics \u2014 the methods behind every „seasonally adjusted employment figure“ and „seasonally adjusted GDP growth rate“ you’ve ever seen in the news.<\/p>\n The modern implementation, X-13ARIMA-SEATS<\/strong>, combines both approaches with ARIMA modeling for trend extension. In R, the For most supply chain applications, STL or MSTL will serve you better \u2014 X-11\/SEATS are optimized for the specific needs of macroeconomic statistics (calendar adjustment, trading day effects, holiday correction) that matter less for demand planning. But if your organization needs to produce official or regulatory-grade seasonally adjusted figures, these are the methods to use.<\/p>\n Here’s the cheat sheet. Every method has trade-offs \u2014 there is no single „best“ decomposition method for all data.<\/p>\n The decision tree for supply chain forecasters:<\/strong><\/p>\n Explore the decomposition methods yourself \u2014 adjust parameters, switch between additive and multiplicative models, and see how different STL window settings change the results in real time.<\/p>\nThe Three Components (And Why They Matter for Planning)<\/h2>\n
\n
Additive vs. Multiplicative: The Decision That Shapes Everything<\/h3>\n
![\"Additive](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_additive_vs_multiplicative.png\")
<\/p>\nMoving Averages: The Foundation of Trend Estimation<\/h2>\n
![\"Moving](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_moving_averages.png\")
<\/p>\nClassical Decomposition: Where It All Started<\/h2>\n
The Algorithm (Additive Version)<\/h3>\n
\n
![\"Classical](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_classical.png\")
<\/p>\nWhy Hyndman Says „Not Recommended“<\/h3>\n
\n
STL: The Method You Should Actually Be Using<\/h2>\n
How STL Works<\/h3>\n
\n
\n
![\"STL](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_stl.png\")
<\/p>\nWhy STL Beats Classical (Every Time)<\/h3>\n
\n\n
\n \nFeature<\/th>\n Classical<\/th>\n STL<\/th>\n<\/tr>\n<\/thead>\n \n Handles any seasonal period<\/td>\n Limited<\/td>\n Yes \u2014 daily, weekly, monthly, any<\/td>\n<\/tr>\n \n Evolving seasonality<\/td>\n No \u2014 static pattern<\/td>\n Yes \u2014 seasonal shape can change over time<\/td>\n<\/tr>\n \n Adjustable smoothness<\/td>\n No \u2014 fixed<\/td>\n Yes \u2014 tune trend and seasonal windows<\/td>\n<\/tr>\n \n Robust to outliers<\/td>\n No<\/td>\n Yes \u2014 via outer loop weighting<\/td>\n<\/tr>\n \n Edge estimates<\/td>\n Missing first\/last m\/2<\/td>\n Available for the full series<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The Two Parameters That Matter<\/h3>\n
\n
season(window = ...)<\/code><\/strong> \u2014 Controls how quickly the seasonal component can change. Larger values mean more stable seasonality (closer to classical decomposition). Smaller values allow the seasonal pattern to evolve more freely. A common starting point for monthly data is season(window = 13)<\/code>, which uses just over one year’s worth of data to estimate each seasonal value.<\/li>\ntrend(window = ...)<\/code><\/strong> \u2014 Controls how smooth the trend is. Larger values produce smoother trends. Smaller values let the trend respond to shorter-term changes. A rough rule of thumb: set it to about 1.5 times the seasonal period, then adjust based on what the remainder looks like.<\/li>\n<\/ul>\n![\"STL](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_stl_comparison.png\")
<\/p>\nSTL’s Limitations<\/h3>\n
\n
The Payoff: Seasonally Adjusted Data<\/h3>\n
![\"Original](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_seasonally_adjusted.png\")
<\/p>\nBeyond STL: Modern Decomposition Methods<\/h2>\n
MSTL: Multiple Seasonal Patterns<\/h3>\n
STL()<\/code> function by specifying multiple seasonal periods. It’s already built into the tidyverts ecosystem.<\/p>\nSTAHL: When Holidays Break Your Patterns<\/h3>\n
\n
BASTION: Bayesian Decomposition with Uncertainty<\/h3>\n
\n
X-11 and SEATS: The Official Statistics Workhorses<\/h3>\n
seasonal<\/code> package by Christoph Sax provides a clean interface:<\/p>\nlibrary(seasonal)\nseas_model <- seas(AirPassengers)\nplot(seas_model)\n<\/code><\/pre>\nMethod Comparison: Choosing the Right Tool<\/h2>\n
\n\n
\n \nCriterion<\/th>\n Classical<\/th>\n STL<\/th>\n X-11 \/ SEATS<\/th>\n MSTL<\/th>\n STAHL<\/th>\n BASTION<\/th>\n<\/tr>\n<\/thead>\n \n Evolving seasonality<\/td>\n No<\/td>\n Yes<\/td>\n Yes<\/td>\n Yes<\/td>\n Yes<\/td>\n Yes<\/td>\n<\/tr>\n \n Multiple seasonal periods<\/td>\n No<\/td>\n No<\/td>\n No<\/td>\n Yes<\/td>\n Yes<\/td>\n Yes<\/td>\n<\/tr>\n \n Robust to outliers<\/td>\n No<\/td>\n Yes<\/td>\n Partial<\/td>\n Yes<\/td>\n Yes<\/td>\n Yes<\/td>\n<\/tr>\n \n Holiday handling<\/td>\n No<\/td>\n No<\/td>\n Yes (X-11)<\/td>\n No<\/td>\n Yes<\/td>\n No<\/td>\n<\/tr>\n \n Uncertainty estimates<\/td>\n No<\/td>\n No<\/td>\n No<\/td>\n No<\/td>\n No<\/td>\n Yes<\/td>\n<\/tr>\n \n Calendar adjustment<\/td>\n No<\/td>\n No<\/td>\n Yes<\/td>\n No<\/td>\n Yes<\/td>\n No<\/td>\n<\/tr>\n \n Ease of use in R<\/td>\n Easy<\/td>\n Easy (fpp3)<\/td>\n Moderate ( seasonal<\/code>)<\/td>\nEasy (fpp3)<\/td>\n Specialized<\/td>\n Specialized<\/td>\n<\/tr>\n \n Best for<\/td>\n Teaching<\/td>\n General use<\/td>\n Official statistics<\/td>\n Complex seasonality<\/td>\n Holiday-heavy data<\/td>\n Scenario planning<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
seasonal<\/code> package.<\/li>\n![\"Comparing](\"https:\/\/inphronesys.com\/wp-content\/uploads\/2026\/04\/decomp_method_comparison.png\")
<\/p>\nInteractive Dashboard<\/h2>\n