Skip to content

$ cat ~/blog/predicting-theme-park-crowds-honestly.md

 · Long read  · 6 min read ·  #theme-parks #building-in-public #data

Predicting theme-park crowds without pretending

How I am building a cautious seven-day crowd outlook from live waits, licensed recent history, park hours, and weather—while keeping unknown data unknown.

Story overview 5 main sections
  1. Start by separating observation from prediction
  2. What the first model actually knows
  3. What it does not know
  4. Unknown has to stay neutral
  5. The next useful step is measurement

Visual story map

How this long read moves

  1. Section 1 of 5: Start by separating observation from prediction
  2. Section 2 of 5: What the first model actually knows
  3. Section 3 of 5: What it does not know
  4. Section 4 of 5: Unknown has to stay neutral
  5. Section 5 of 5: The next useful step is measurement
Follow the main sections, or use the outline below to jump to a specific question.

Theme-park crowd calendars tend to arrive with a confidence level the underlying data has not earned. Pick a date six months out, get a precise-looking number, and try not to ask what happened between the source data and that cheerful green box.

I am building the opposite into the Park Field Guide: a seven-day outlook that can be useful without acting omniscient. It compares weather, published operating hours, and crowd pressure when qualified evidence exists. It also says when that evidence does not exist.

That last part is not a fallback message. It is part of the model.

Start by separating observation from prediction

The planner has three crowd states, because combining them would make the interface look cleaner and the answer less honest.

  • Observed means fresh posted standby waits are available for the park’s current local date. The system checks valid queue observations, sample coverage, freshness, the median wait, and the 75th percentile. It describes what is happening now. It does not predict tomorrow.
  • Modeled means licensed recent history produced enough comparable completed dates for a cautious same-weekday estimate. It is always labeled low confidence.
  • Unavailable means neither input qualifies. The crowd factor stays neutral instead of quietly treating missing data as an empty park.

A fresh observation takes priority over the modeled band for today. A published closed date gets an unavailable state rather than a crowd band. Those are small rules with a large effect: the page never presents yesterday’s model as a live reading, and it never rewards a date simply because an upstream source did not answer.

You can see the distinction in the seven-day planner on the park pages, including the Epic Universe field guide. The labels carry the meaning; the progress bars are only a visual summary. There is no invented percentage hiding inside them.

What the first model actually knows

The future-looking input comes from Rope Drop News open data, published under CC BY 4.0. Its audited coverage is limited to a subset of the parks in the guide, so the model is optional by design. ThemeParks.wiki supplies current operating evidence and published schedules. Open-Meteo supplies the seven-day weather forecast.

For a future date, the crowd model looks for completed recent dates on the same weekday. It needs at least two qualifying records. The latest comparable source date must be no more than fourteen calendar days old. The accepted history is bounded, strictly parsed, and limited to four source levels—Light, Moderate, Busy, and Packed—which the planner normalizes to quiet, moderate, busy, and heavy. The middle recent level becomes the outlook band.

That is deliberately modest. Tuesday is usually more comparable to another Tuesday than to the Saturday beside it, but weekday matching is not a complete theory of theme-park attendance. It is a first bounded signal.

The history request also has a short deadline and fails independently. If it times out, the planner can still show weather and hours. If it is stale, malformed, duplicated, or too thin, it cannot manufacture a modeled result. Graceful degradation is less exciting than a magic forecast. It is also much nicer when an API has a bad morning.

What it does not know

The current model does not account for every school break, holiday, ticketed event, promotion, convention, ticket-price change, attraction outage, or unusual operating day. Weather remains its own category because I have not demonstrated that a particular forecast consistently predicts attendance. A rainy afternoon may keep one family home and convince another that it is finally time to brave I-4. The code should not choose a story without evidence.

There are other tempting signals. Federal and regional holiday calendars can add date context. Severe-weather alerts can describe disruption. Dated ticket prices might reveal demand in some systems. None of those automatically becomes a crowd prediction just because an API returns JSON.

Each source needs a contract: what it covers, how fresh it is, what missing means, whether the terms permit the use, and how it behaves when it fails. Price data is especially awkward because products and inclusions differ by park. A missing price is not a bargain. A school break is not an attendance count. The absence of a weather alert is not a safety guarantee.

The planner exposes those limits alongside its result. I am not publishing the exact Park Day Score weights, normalization, or tie rules, but the categories, evidence coverage, source attribution, freshness, and confidence remain visible. Keeping the recipe private is not permission to hide what went into the meal.

Unknown has to stay neutral

This is the rule I care about most.

Many scoring systems accidentally turn missing data into good news. If the crowd feed disappears and the system substitutes zero, the park suddenly looks empty. If hours are unavailable and the model assumes a full day, the broken source makes the recommendation better. That is backwards.

Here, unavailable evidence is pulled toward a neutral contribution, while confidence and completeness fall. The result can still compare days using the evidence that remains, but it changes its language. A thin result becomes an early read. No evidence becomes not enough data. Closed dates stay closed.

That distinction matters more than an extra decimal point. A score can be mathematically precise and practically misleading. Confidence answers a different question from the score: not “how good is this date?” but “how much qualified evidence supports the comparison?” The interface needs both.

It is the same principle behind the broader field guide. The maps and attraction lists are useful because they distinguish operating, seasonal, announced, temporarily closed, and unavailable experiences rather than flattening all of them into one roster. The coaster notes can be personal. The planner has to be explicit about evidence.

The next useful step is measurement

The current model is a low-confidence baseline, not a victory lap. To improve it, I need to privately collect qualified observations over time, join them to park-local schedules and explicit calendar context, and evaluate the predictions against dates the model has not already seen.

That evaluation should be per park, per forecast horizon, and across seasons. A model that looks good one day ahead at Magic Kingdom may be useless six days ahead somewhere else. Error needs to be recorded, not remembered selectively after the one weekend it happened to nail.

Only measured calibration should raise the confidence label. New signals should earn their way into the score by improving held-out results, not by making the methodology paragraph longer. Coverage will remain uneven for a while, and uncovered parks will keep saying unavailable.

I would rather ship a small model that knows when to stop than a big one that never admits it is guessing. The goal is not to predict every crowd. It is to make the next park day a little easier to choose—and show exactly how much trust that choice deserves.

Provider contracts and model behavior reviewed August 21, 2026.

— Director of Technology at Executive Reporting Service and the builder behind DepoStack, based in St. Pete. Read The Log