{"id":1909,"date":"2026-04-21T20:31:28","date_gmt":"2026-04-21T20:31:28","guid":{"rendered":"https:\/\/inphronesys.com\/?p=1909"},"modified":"2026-04-21T20:31:28","modified_gmt":"2026-04-21T20:31:28","slug":"global-forecasting-with-xgboost-in-r-a-walmart-weekly-walkthrough","status":"publish","type":"post","link":"https:\/\/inphronesys.com\/?p=1909","title":{"rendered":"Global Forecasting with XGBoost in R: A Walmart Weekly Walkthrough"},"content":{"rendered":"

Gradient-boosted trees like XGBoost have become the default ML choice for multi-series forecasting \u2014 not because they beat classical methods by huge margins, but because they scale across hundreds of SKUs and let you fold in real covariates (promotions, holidays, prices) that ETS and SNAIVE can’t touch. This post is a hands-on walkthrough: we apply the same family of techniques popularised by M5-era gradient-boosted models to a classic public dataset (Walmart weekly sales), and honestly measure where the complexity earns its keep \u2014 and where it doesn’t.<\/p>\n

It’s the practical follow-up to two earlier posts in this series: The M5 Lesson<\/a> explained why<\/em> gradient-boosted trees won the biggest forecasting competition ever run; The Horse Race<\/a> showed how to pick a forecasting winner with MASE and cross-validation. Today is the how<\/em> \u2014 and specifically how in R<\/em>, with the tidymodels + modeltime stack.<\/p>\n

The Dataset: Walmart Weekly Sales<\/h2>\n

Our example is timetk::walmart_sales_weekly<\/code> \u2014 a public sample distributed with the timetk<\/code> R package, originally released for the 2014 Walmart Recruiting Kaggle competition. It contains 7 departments at a single Walmart store<\/strong> across 143 weeks (February 2010 to October 2012). Think of each series as a product category in one store: apparel, grocery, electronics, and so on. It’s a convenient teaching example for end-to-end ML forecasting \u2014 retail, weekly, multi-series, with a real holiday covariate baked in \u2014 without the operational weight of a production-scale dataset.<\/p>\n

That last point matters more than it looks. Most demand series come with context: promotions, holidays, price changes, weather. Classical statistical models like ETS and SNAIVE can’t use any of it \u2014 they see only the sales number. Machine learning models can use everything you hand them, which is why they tend to pull ahead on rich retail data and stay even on sparse industrial data.<\/p>\n

The IsHoliday<\/code> flag in this dataset captures exactly the kind of event that theoretically breaks a naive forecaster: Thanksgiving, Black Friday, Christmas week. A model that knows „next week is a holiday week“ has an advantage over a model that doesn’t \u2014 at least in principle. Whether it actually helps in practice on this particular dataset is a question we’ll return to in the Feature Importance section, and the answer may surprise you.<\/p>\n

We train on the first 131 weeks and hold out the last 12 weeks (from August 10, 2012 onward) as the test window \u2014 a realistic quarter-ahead forecasting horizon.<\/p>\n

\"7<\/p>\n

Why Feature Engineering Is Everything<\/h2>\n

Here is the one thing that trips up everyone new to ML forecasting: XGBoost has no idea it is looking at time series data.<\/strong><\/p>\n

ETS knows. Its equations explicitly encode level, trend, and seasonality \u2014 that’s literally what the letters stand for. SNAIVE knows \u2014 its entire method is „what happened one season ago.“ These models come pre-wired to recognise the rhythm of demand.<\/p>\n

XGBoost doesn’t. To XGBoost, every row is an independent observation, every column just a number. It has no concept of „last week“ or „same week last year“ unless you explicitly build a column called lag_52<\/code> and hand it over. If you don’t, the model cannot learn annual seasonality \u2014 not because it isn’t smart enough, but because the information literally isn’t in its input.<\/p>\n

Think of it like this: ETS is a specialist who has memorised the seasonal calendar. XGBoost is a brilliant generalist who can learn anything \u2014 but only if you point at it. Feature engineering is the pointing.<\/p>\n

This is why the M5 winners talked about features, not algorithms. Everyone at the top of the leaderboard used gradient-boosted trees. The difference between rank 1 and rank 1,000 was how thoughtfully each team had translated demand history into tabular columns the model could read.<\/p>\n

Building the Feature Engineering Recipe<\/h2>\n

Our feature pipeline adds a specific kind of column for each thing we want the model to see. Crucially, every lag and rolling feature is computed strictly from the past<\/strong> (t-n through t-1, never including t), and computed per department<\/strong> so a high-volume category can’t leak its numbers into a low-volume one.<\/p>\n

1. Lag features (1, 4, 13, 26, 52 weeks).<\/strong> These capture memory at different horizons:<\/p>\n