Dealing with missing data in an exponential smoothing model

Question

There does not seem to be a standard way to deal with missing data in the context of the exponential smoothing family of models. In particular, the R implementation called ets in the forecast package seems to just take the longest subsequence without missing data, and the book "Forecasting with Exponential Smoothing" by Hyndman et al. does not seem to talk about missing data at all.

I would like to do a little more, if my users explicitly ask me to (and if the missing data don't occur too close together or in too many periods that are exactly one season apart). In particular, what I have in mind is the following. During simulation, whenever I would encounter a missing value $y_t$, I would substitute the current point forecast $\tilde y_t$ for $y_t$, so that $\varepsilon_t = 0$. This would, for example, make the data point not be considered for the parameter optimization process.

Once I have a reasonable fit for the parameters, I can estimate the standard deviation of the errors (assumed to be normal with mean $0$) and verify that using values for $\epsilon_t$ generated from that distribution do not decrease the likelihood by a big factor. I would use such values for forecasting (using simulation) as well.

Are there known pitfalls with this method?

Answer 1

Your approach makes sense. A commercial piece of software I was associated with for a couple of years did exactly this.

Your outline applies to Single Exponential Smoothing (SES), but of course you could apply the same treatment to trend or seasonal components. For the seasonal ones, you would need to go back a full seasonal cycle, just as for updating.

Another alternative would of course be to simply interpolate missing values. This is an option in newer versions of ets(..., na.action="na.interp").

From what little I know of state space models, it should not be overly hard to simply treat the missing data as unobserved. I am not sure why this is not implemented in the forecast package. A quick search through Rob Hyndman's blog didn't really yield anything useful.