Kenya Maize Price Forecasting

The Problem

Agricultural price forecasting in East Africa comes with a unique challenge: the data infrastructure is sparse. Markets report inconsistently, volumes fluctuate wildly between seasons, and the two available data sources — agriBORA weekly prices and KAMIS daily market data — measure slightly different things at different granularities. The task was to predict weekly wholesale maize prices for 5 Kenya counties (Kiambu, Kirinyaga, Mombasa, Nairobi, Uasin-Gishu) two weeks ahead.

The fundamental difficulty wasn't modeling — it was data alignment. KAMIS reports daily prices from individual markets within each county, while agriBORA provides weekly county-level prices. These don't perfectly match. Some weeks have missing data from one source. Some markets within a county trade vastly different volumes, meaning a simple average of their prices would be misleading. Before I could build any model, I needed a reliable way to fuse these two data sources into a single coherent price signal.

Beyond the data issues, maize prices in Kenya follow strong seasonal cycles tied to harvest periods and lean seasons — but the cycles aren't perfectly regular. Rainfall timing shifts year to year, and external shocks (import restrictions, regional supply changes) create sudden level shifts that no purely seasonal model can anticipate. The model needed to capture both the regular rhythm and the irregular disruptions.

My Approach

I started with the data alignment problem. For KAMIS daily prices, I aggregated to weekly using volume-weighted means rather than simple averages — ensuring that high-volume market days carry more weight than thin-trading days. Then I built a calibration layer between KAMIS and agriBORA prices, so the model could leverage the richer daily data while predicting against the agriBORA target. For gaps in the data, I used last-observation-carried-forward (LOCF) rather than interpolation, because in commodity markets a missing price usually means "no change" rather than "somewhere between the neighbors."

The feature engineering encoded both seasonal patterns and momentum signals. I created cyclical encodings for week-of-year (sine and cosine transforms), harvest and lean season indicators per county, rolling statistics (4-week and 8-week moving averages), lag features at 1, 2, 4, and 52 weeks, and year-over-year price changes. The cyclical encoding was important — treating week 52 and week 1 as adjacent rather than 51 units apart lets the model learn smooth seasonal transitions.

For modeling, I built an ensemble that combines ML models (LightGBM, XGBoost) with classical time series (ARIMA, ETS, Prophet). The ML models excel at capturing non-linear interactions between features but can produce unreasonable extrapolations. The classical models provide stable seasonal baselines. The ensemble blends their strengths while using walk-forward cross-validation for honest evaluation — each fold trains only on past data and predicts the next unseen window, exactly mimicking the real forecasting task.

Key Decisions

Key Takeaway

The biggest lesson from this project: in sparse-data forecasting environments, data engineering produces more lift than model sophistication. The time I spent on volume-weighted aggregation, source calibration, and gap-filling — before any model was trained — determined the ceiling of the entire system. A sophisticated model on poorly aligned data will always lose to a simple model on well-prepared data. When the infrastructure is sparse, the engineer's job is to build the data quality that the infrastructure doesn't provide.