A demand forecast that is 90% accurate on average and wrong on New Year's Eve, Carnival week, and the local festival weekend is not a 90% useful forecast. In short-term rentals and seasonal hospitality, most of the money is concentrated in exactly the nights generic models get wrong. Here are the five reasons that happens, in the order we usually find them.
1. You're forecasting occupancy, but occupancy is not demand
Occupancy is censored demand. A night that sold out at $180 tells you demand was at least one booking at that price — it says nothing about the three other guests who would have paid $240. Train a model on historical occupancy and it learns to predict your past inventory decisions, not what the market wanted.
The censoring is worst precisely where it matters: peak nights sell out early, so the model sees "100% occupancy" for every event weekend and concludes demand was identical for all of them. Minimum-stay rules distort the signal further — a two-night minimum turns away one-night demand that never appears in any dataset.
What works: model the booking process, not the outcome. Booking-curve (pickup) models forecast remaining demand by days-until-checkin, so a night that is pacing 40% ahead of its typical curve at 60 days out gets flagged — and priced up — while it can still be acted on. Unconstraining techniques from hotel revenue management estimate the demand you turned away.
2. Your training data has prices in it, and that poisons the model
Historical bookings happened at historical prices — prices set by a human or by a pricing tool reacting to demand. That makes price endogenous: high prices coincide with high demand in the data because someone raised prices when demand was high. A model trained naively on this data routinely learns that higher prices cause more bookings, and a pricing engine built on it will confidently recommend nonsense.
What works: separate demand estimation from price optimization. Estimate price sensitivity from the variation you can defend — comp-set price differences, natural experiments, or deliberate randomized price tests on a slice of inventory — then optimize price against that demand model. If a vendor tells you their model "learns elasticity automatically from your history," ask how they handle endogeneity. The silence is informative.
3. Seasonality is layered, and the layers move
A beach property doesn't have "seasonality." It has at least four overlapping cycles: annual (summer vs. winter), weekly (Friday–Saturday vs. Tuesday), holiday (fixed dates like New Year's, moving dates like Easter and Carnival), and event-driven (festivals, conferences, school calendars that vary by district and by country — a real issue when your guests come from both the US and Brazil). Libraries like Prophet or ARIMA fit one smooth annual cycle keyed to the calendar date and average the rest away.
The result is systematic: the forecast underprices the ten most valuable weekends of the year and overprices the shoulder nights around them.
What works: holidays and events as explicit features with lead-time effects (an event affects booking pace weeks before the date), school-break calendars for your actual guest origin markets, and moving-holiday handling. This is unglamorous feature engineering, and it beats model sophistication every time in this domain.
4. The market itself is non-stationary
Time-series models assume the process generating the data is stable. STR markets are not: new listings enter the comp set continuously, your own review count and ranking change your demand independent of the market, platform algorithm changes shift visibility, and regulation can remove a third of the competing supply overnight. A model trained on 2023 is describing a market that no longer exists in 2026.
What works: include supply-side features (active comps, their pricing, your review velocity and rating), retrain on a schedule, and monitor forecast error by segment so drift is detected when it starts, not at the end-of-year review. This is also the argument for treating forecasting as an operated system rather than a one-time project.
5. Per-listing data is too sparse for per-listing models
A listing booked 200 nights a year produces 200 booking observations annually — and two years of history is exactly two observations of each season. No amount of model sophistication extracts a reliable holiday effect from two data points. Fitting one model per listing is the single most common structural mistake we see in home-grown STR forecasting.
What works: hierarchical pooling. Share seasonal shapes, event effects, and price-sensitivity estimates across comparable listings — same market, similar capacity and quality tier — so each listing only needs enough of its own data to establish its level relative to the pool. Pooling is also the only honest solution to cold-start: a new listing inherits the pool's patterns from day one.
The evaluation mistakes that hide all of the above
- MAPE on low-demand nights. Percentage errors explode near zero, so models get optimized to nail the empty Tuesdays that don't matter. Use revenue-weighted error, and report error separately for peak nights.
- Aggregate accuracy masking per-listing failure. Portfolio-level error can look excellent while half the listings are badly mispriced in opposite directions. Evaluate at the level where the pricing decision is made.
- Random cross-validation. Randomly shuffling nights leaks the future into training. Backtests must be time-ordered: train on the past, forecast the future, roll forward.
- Point forecasts feeding pricing decisions. Pricing is a decision under uncertainty; a single expected-demand number hides whether a night is a safe bet or a coin flip. Quantile forecasts (10th/50th/90th) let the pricing layer decide how aggressive to be.
When you don't need any of this
Under roughly 15–20 listings, the honest recommendation is usually an off-the-shelf dynamic pricing tool plus an attentive operator, not a custom model. The gains from custom modeling scale with portfolio size and with how atypical your properties are; below that threshold, the build cost rarely pays back. We wrote a separate piece on when to build vs. buy ML, and our ML ROI calculator will give you a first-pass answer in two minutes.
How we'd approach it: we build pooled, booking-curve-based demand and pricing models and prove them against a holdout before anyone pays for them — no upfront build fee, and no performance fee at all if the model doesn't beat your current method in a controlled comparison. Here is exactly how that works. The same forecasting problems show up in grocery perishables and energy, which is where most of our forecasting work sits.