Time series model training: Prophet, NeuralProphet, TimesFM

Prophet training: where the forecast breaks and why

Time series forecasting seems like a modeling task, but forecast error is almost always born in the data. Prophet decomposes a series into trend, seasonalities, and event effects and faithfully reproduces what it receives at the input.

With low-quality historical data, the model will not fix the series; it will cement its defects with a confident look.

First — gaps. Missing days, a dropped collection channel, the joining of two exports: the series loses regularity, and the trend is built along a broken line.

Prophet training must be preceded by an explicit rule for bringing data to a regular grid — what to treat as zero, what as a stoppage, what as an outlier. Silent interpolation hides the problem until the first forecast.

Second — regime change. A new tariff, a promo restart, a changed process: history before and after describes different behavior, while the model averages the periods and misses both.

Change points are set explicitly, and the history window is limited so the old regime does not pull the trend backward.

Third — unlabeled events. A campaign, a release, an outage: if they are not moved into regressors or a calendar, they settle in the residual and inflate the interval.

Fourth — the wrong horizon: longer than the period over which seasonality is stable, it widens the intervals until they are useless.

This must be checked on a holdout segment, not on the training set: agreement inside the history only speaks to the ability to memorize. That is why we start Prophet training with a series audit and a quality metric, not with parameter tuning.

What a correct model delivers: effect in metrics and failures

Model quality is visible in retrospective validation over a rolling window, not at a single holdout point. The model is trained only on past data, predicts the next interval, and error is averaged over MAE, MAPE, and SMAPE.

We compare the result with a seasonal naive forecast: if the model does not beat it, the seasonality mode or regressors are set incorrectly.

Robustness to outliers is built in at the training stage. Holidays, sales, and one-off failures are described by separate regressors rather than cut out of the history — then the spike is marked as an event and does not drag the baseline trend with it.

In Prophet, sensitivity to trend change points is set a priori: higher flexibility means faster adjustment, but also a higher risk of catching noise instead of signal.

The planning horizon determines data requirements. Error grows with every step forward, so forecast accuracy is recorded separately on the short and long horizon: weekly planning and quarterly planning require different sets of regressors.

A practical indicator is the share of periods closed automatically, when the forecast fell within the confidence interval and no manual review was needed.

Hence the eliminated class of failures. While the model was retrained manually on an event, a regime change — a new supplier, a changed tariff grid, a demand shift — was noticed at the moment when the forecast had already diverged from fact.

With a retraining schedule and monitoring of input series drift, regime change is detected before the business sees it.

Prophet training and alternatives: comparison of approaches

All three options solve one task — forecasting from a historical series — but they are structured differently, and both quality and maintenance cost depend on that.

A decomposition model breaks the series into trend, seasonality, and holidays; a neural network extension adds lags and autoregression to this; a pretrained model comes with ready-made weights and on a short history is often more accurate without training from scratch.

The fork is simple: interpretability versus accuracy on irregular data. If the forecast needs to be explained — showing components, regressor contributions, interval bounds — the decomposition approach remains the baseline. Neural network variants require more history and careful validation on a holdout period.

The input data is the same for all three: a regular time index, missing value handling, external regressors. Therefore, comparison of forecasting approaches should correctly be conducted on one set of series and one error metric, rather than choosing a model in advance.

Work stages: from series audit to model handover

Training a time series model is not a single run but a sequence of steps, where each relies on the result of the previous one. Below are the model training stages that we go through together with the client, recording metrics at each step.

1. Series audit and preparation: we check frequency, gaps, outliers, regime changes, and the holiday calendar. We fill gaps by interpolation; we do not silently remove anomalies but mark them as separate events.
2. Validation scheme selection: we hold out the last segment of the series and do not show it to the model, so the evaluation is honest. For seasonal data, we set the horizon as a multiple of the period.
3. Model parameter selection: we iterate over seasonality, trend, change points, and smoothing on the training segment, monitoring the result on an intermediate segment.
4. Training: we run Prophet training on the full prepared series and save the artifact together with the configuration — reproducibility matters more than one successful run.
5. Validation on the holdout period: we calculate error by horizon, see where the model loses accuracy, and return to parameters if the discrepancy grows.
6. Model handover to the client: we deliver code, configurations, metrics, and the retraining policy, and hold a walkthrough with your team so that running it does not depend on us.

After that, the model lives in your environment: retraining on a schedule or when accuracy falls below an agreed threshold.

What we hand over: artifacts, configurations, policies

A forecasting project ends not with a chart on a slide but with a set of artifacts that your team can use to run training and maintenance without us.

We hand over everything needed for a reproducible run and subsequent retraining — from configuration to rules for responding to metric degradation.

• Model configuration: hyperparameters, seasonalities, the list of external regressors, validation window, and forecast horizon — in a file from which the run is reproduced exactly.
• Data preparation scheme: how the training sample is assembled from raw exports, how gaps, outliers, and tariff plan changes within the history are handled.
• Event labeling: the calendar of holidays, campaigns, and incidents — so the model does not attribute a one-off spike to seasonality or carry it into the forecast.
• Retraining policy: periodicity, metric triggers, the order of the run, and mandatory comparison with a naive forecast before publishing a new version.
• Model documentation: inputs and outputs, allowable horizon, applicability boundaries, known weaknesses, and causes of previous deviations.
• Forecast quality monitoring: metrics on a rolling window, comparison with a baseline, alerts when error exceeds the threshold.
• Maintenance and rollback rules: versioning of models and data, the procedure for returning to a previous version if the new one behaves worse.

Before handover, we go through the list together with your engineers: they run training on their data, and we compare the result. This way, the retraining policy and monitoring do not remain text in a document but work from the first day of handover.

Case study: how we reduced forecast error on a real series

We were planning weekly demand on a series with two seasonal peaks and an uneven promo schedule. The baseline model smoothed over holiday spikes: shifted days off and pre-holiday shipments went into the residual, and error accumulated toward the end of the quarter.

The share of periods where the miss exceeded the allowable threshold reached 38%, and planners corrected the forecast manually about 60 times per cycle — that was two days of work for each recalculation.

What we changed

We moved holidays and shifted days off into separate regressor features, kept weekly and yearly seasonality instead of one annual curve, and put promo spikes into external factors.

We trained Prophet as the main model, NeuralProphet for series with strong dependence on past values, and on cold start, where there is little history, took a quick benchmark from TimesFM. Quality was measured by rolling cross-validation over seasonal slices, not by the last month alone.

What we got

The average forecast error on a four-week horizon decreased by about half. Manual correction stopped being a mandatory stage of the cycle.

The remaining 11% are mainly one-off campaigns that were not in the history; we handle them with a separate exceptions list that the planner confirms manually. The retraining policy is once a month plus an unscheduled run when the assortment changes.

Technical concerns: gaps, regimes, incremental training

Before a Prophet training pilot, engineering concerns are usually the same: how much history to feed as input, what to do with gaps, how to label events, and whether the model can be updated without a full rebuild. Below are short answers to each.

What to do with gaps in the data?

First, we separate gaps by nature. A technical collector failure is interpolated and marked as a restored segment. A meaningful zero — a holiday, a line stoppage — is a fact; filling it with the average is not allowed: the model will learn false dynamics. The decision is made for each segment separately, using a gap map.

How to label calendar events?

We feed holidays, promos, releases, and incidents as separate regressors rather than hiding them inside seasonality — otherwise a one-off jump is smeared across the whole year. The labeling is stored as a table of dates and weights and can be edited without changing the code.

Can the model be incrementally trained without a full rebuild?

Yes: Prophet accepts new points to an already trained model, and NeuralProphet continues training from the current weights.

We launch a full rebuild when the series regime changes — the seasonality structure has changed, a major new regressor has appeared, or the data has moved to a different scale. The decision is recorded by metrics on the holdout segment, not by eye.

Let's discuss your task: send the series and requirements

To discuss the forecasting task concretely, rather than in general terms, we need the series itself and the context of its use.

Data requirements differ across approaches: one needs a strictly regular time grid, another needs history depth to separate seasonality from trend, and a third needs known-in-advance external factors.

The more complete the initial picture, the more accurate the project estimate and the fewer reworks at the implementation stage.

• The series in a machine-readable form — CSV or Parquet, a timestamp with time zone, a fixed step, explicitly marked gaps and downtime. An empty value and zero are not the same thing.
• History depth — at least two to three full seasonal cycles. For weekly and yearly seasonality, these are different horizons, and they determine what can be learned at all.
• Forecast horizon and frequency — how many steps ahead, how often we recalculate, whether one cut or a distribution with quantiles is needed.
• External factors — calendar and holidays, campaigns, weather, repairs. The key thing: what is known at the time of the forecast and what appears only after the fact.
• Events that break the series — outages, accounting migrations, methodology changes. They should be marked: we cut some outliers and leave others as signal.
• Acceptance criterion — the metric (symmetric error, quantile error) and the threshold at which we consider the model working, plus the rule for behavior when it is exceeded.
• How the forecast fits into your environment — scheduled recalculation or on-demand calculation, where we send the result, and with what delay.

In response, you receive a project estimate, a work plan, and two or three training scheme options: a simple baseline model as a quick benchmark, a local model with regressors for your series, and a global pretrained one — if your own history is limited.

We compare the options on historical windows, show which one stays within the threshold, and fix the incremental training scheme: by schedule or by data drift.

What to do if the series is already forecast by another tool

The series is already forecast by another tool — that is not a reason to start from scratch but a starting point. First, we collect the behavior of the current model: retrospective runs on historical windows, error by horizon and by seasonal slices.

Without these numbers, any comparison with a new solution will be a conversation about tastes, not forecast quality.

Separately, we transfer everything the model knows beyond the series itself: the calendar of holidays and shifted days, promo periods, regressors, and rules for handling gaps and outliers.

If only the value column is transferred, the new scheme will lose — but not because of the algorithm, rather because of lost features and different preprocessing.

The compromise path is to run two models in parallel: the current one remains operational, and the new one is calculated in shadow mode and does not affect decisions.

After several forecasting cycles, we compare error by horizon and by series groups, and see where the discrepancy is systemic and where it is noise. This way, the transition relies on accumulated statistics rather than a single successful run.

We keep the switching loop reversible: the current solution is preserved in full, and model selection is set by configuration, not by code changes. This allows rollback in one step if quality on live data turns out to be worse.

If you already have Prophet or your own calculation running, describe which features and horizons matter, and we will come back with a transition plan and timeline estimate.