Time Series Forecasting with Prophet

Suppose a venue's operations team wants to estimate ticket sales for the next two weeks. Sales go up on weekends, and orders pour in when presales for a particular show open. On days the venue is closed, on the other hand, sales may drop. Prophet is a method you can use to forecast data like this, where long-term change over time, repeating patterns, and the effects of special dates all show up together.

Prophet is a forecasting model that represents a time series as components such as trend, seasonality, and holiday and event effects. Because you can see how much each component contributes to the result, it's useful for explaining not just the forecast but why the forecast came out the way it did. It isn't a method that always performs well once it's set up, though, so information about events that will be known in the future and validation in time order are important.

In this article we'll use a real example to look at Prophet's basic structure, changepoints, seasonality, event effects, key settings, forecasts and uncertainty, backtesting, and how it differs from ARIMA and ETS.

It works well with data recorded at regular dates, such as daily or weekly data, and can be applied to data that has not only day-to-day changes but also weekly or yearly repeating patterns. The standard additive model is written as follows.

Here g(t) is the trend, s(t) the seasonality, h(t) the effect of holidays or events, and ε_t the remaining variation. Depending on the situation, Prophet can also use multiplicative seasonality and include additional regressors. A distinctive feature is that you can look at each component separately, but interpreting a component doesn't mean it's a causal effect.

The analysis looks at the number of paid tickets per day, with a consistent rule for how cancellations and refunds are handled. The operations team wants to forecast demand for January 2026 to plan front-of-house staffing and customer support.

Here we assume that, for presale opening days of major shows, only dates already confirmed when the forecast is made are used. If you fill in future show dates that hadn't been decided yet by looking back at past results, you'd be using information that wouldn't be available in a real operating setting.

For example, weekend sales may be higher than weekday sales, and sales may rise overall during the year-end show season. There may also be temporary spikes on the presale opening day of a particular show.

These patterns don't all mean the same thing. A difference that repeats every week is closer to weekly seasonality, and a rise or fall in sales levels over several months can be seen as a change in trend. A spike that happens only on a particular date should be examined as an event effect or an outlier. But first check whether it reflects a real operational change or an error in data collection or recording.

Days with zero sales during closures also need care. If online ticketing is available even on closure days, a closure day itself doesn't mean zero sales. Date variables should be defined to match how sales actually work.

For example, average daily sales may gradually rise as the venue becomes better known. But if a new competing venue opens or the ticketing channel changes, the rate of growth can change.

A changepoint is a point in time where the slope of the trend can change. By default, Prophet estimates changes in the trend using several candidate points in the training period. If you allow changepoints too freely, the trend can follow even temporary fluctuations; if you restrict them too tightly, it may not respond enough to real structural changes.

The key setting changepoint_prior_scale controls how flexible these trend changes are. A larger value lets the trend respond more flexibly to change but raises the risk of overfitting, while a smaller value tends to give a smoother trend. Which value works best should be compared with validation in time order.

In venue ticket sales, weekly seasonality, such as the difference between weekends and weekdays, can be pronounced, and there can also be yearly seasonality tied to school vacations or the year-end show season.

Prophet uses Fourier series to represent these repeating patterns flexibly. But you don't need to add arbitrarily complex seasonality just because there are day-of-week differences. Check whether the repeating pattern really exists and whether the training period covers enough of that cycle.

If the size of the seasonality grows with the level of sales, you can consider multiplicative rather than additive seasonality. For example, if the weekend effect also grows in absolute number of tickets when usual sales double, the multiplicative approach may be appropriate. Decide on the approach based on the characteristics of the actual data and validation performance.

The idea is to try to separate yearly seasonality that repeats every year from shocks on particular dates. In this example, official closure days and presale opening days for major shows can be included in the event list.

If the effect lasts for several days after presales open, you can use lower_window and upper_window to set the period before and after the date. These ranges should, however, be based on how sales actually unfold.

An event coefficient is a related pattern the model estimates while controlling for the other components. Without a randomized experiment or an appropriate causal identification strategy, you shouldn't conclude that the event increased sales by a given amount.

Then you configure the trend, seasonality, events, additional regressors, and so on.

To use a logistic trend, you need to set a saturation cap and, if needed, a floor. Even if you'd like to use the venue's seat count as the cap, check whether daily sales are really limited by that number of seats. If tickets for several future shows are sold on the same day, daily sales may not be directly limited by the seat count of any one venue.

Additional regressors must also have values available for the forecast period. Using actual revenue or actual visitor counts that can't be known in the future as predictors causes information leakage.

Here is a simplified decomposition of the expected sales for January 3, 2026.

In an additive model, these values add up to 520 tickets. These figures are examples set up to show how components are calculated, however, not output from actually fitting Prophet.

The values for each component can vary with the baseline level and the model settings. For example, positive weekend seasonality reflects a pattern of higher sales than on weekdays after accounting for other factors, but it isn't evidence that the weekend itself causes sales to increase.

The table below shows an excerpt for some of the dates.

In the figure, January 8–14 are dates not in the table, drawn by continuing the same components.

For example, the expected sales for January 3 are 520 tickets, with a 95% prediction interval of 390–665 tickets. This means the range is designed to reflect the uncertainty in future observations, on the condition that the model's assumptions and its uncertainty estimation procedure are appropriate.

Note that Prophet's default uncertainty intervals don't automatically reflect every real-world risk. There's no guarantee they properly cover events that haven't appeared often enough in the past, such as a sudden show cancellation or a ticketing system outage. So the actual coverage of the intervals should be checked by backtesting past forecasts.

To reproduce the situation of forecasting the future, you must keep the order: train on past data and forecast the period that follows.

In this example, you can hold out December 2025 as the final holdout and run rolling-origin validation on the earlier data, moving the forecast start point several times. At each point, you forecast sales 7 or 14 days ahead and compare performance.

Forecast performance can be evaluated with the mean absolute error (MAE), root mean squared error (RMSE), and so on. MAE shows how many tickets the forecast is off from actual sales on average, while RMSE gives more weight to large errors. You should also check how often the actual values fall inside the 95% prediction interval.

Below are forecast results using the same December 2025 holdout.

In this example, Prophet had the lowest MAE and RMSE. But this is just the result for the example; it doesn't mean Prophet is better on all venue data.

ETS can do well with structures where level, trend, and seasonality are smoothed, and SARIMA is suited to modeling the autocorrelation structure of a time series directly. Prophet is convenient for combining interpretable trend changes, multiple seasonalities, and events whose dates are known. Which method is best should be validated against the forecast horizon and the actual operational purpose.

You can use future dates that are already confirmed, such as presale opening days, but entering future events that weren't known at forecast time after the fact, by looking at what actually happened, causes information leakage.

Second, beware of too much flexibility.

If you give changepoints or seasonality too many degrees of freedom, the model can explain past data well while forecasting new periods poorly. Compare settings with validation in time order.

Third, distinguish closure days from missing dates.

A date with genuinely zero sales is different from a date whose sales record is missing. Treating both as 0 can distort the trend and seasonality.

Fourth, don't interpret prediction intervals as firm upper and lower limits.

Prediction intervals depend on the model's assumptions, and actual errors can be larger if an unusual operational incident or a structural change occurs.

Fifth, distinguish forecasting from causal analysis.

Even if a positive effect is estimated for a holiday or show event, other simultaneous changes may have played a role. You shouldn't claim a causal effect of a policy or event from Prophet's event effects alone.

In particular, distinguish the dates on which the model was evaluated from the dates actually being forecast.

It can be a useful choice especially when the series shows clear repeating patterns and future event dates are known to some extent.

But the advantage of being easy to explain component by component is separate from actual forecast performance. Check that the trend changepoint and seasonality settings are appropriate, don't use information that can't be known in the future, and carry out backtesting in time order and comparisons with simple baseline models.