Method & data

Three different claims

1. Cheap: a low number. We don't use this on its own.
2. Unusually cheap: at or below the 10th percentile and at least 15% below the median of comparable fares.
3. Good opportunity: unusually cheap, and the trip holds up on length, routing, weather and crowds.

Comparable fares

Same route, observed over the last 12 months with at least 7 days' lead. We prefer the same departure date's own history and widen only when data is thin (±0, ±1, ±2, ±3, ±5, ±7, ±10, ±14, ±21 days), because nearby dates differ structurally: a Tuesday is always cheaper than the Saturday next to it, and early January is always cheaper than Christmas. Comparing across them would flag ordinary structure as an anomaly. Fewer than 20 comparable fares → “not enough data”, never a deal.

We scan ~85 date windows per destination, and the best of many noisy prices will look cheap by chance. That's why both anomaly conditions must hold and at most two windows per destination reach the feed.

Verdicts

Feed order: verdict tier first, then % below the typical fare for those dates. That's a sort key, not a quality score.

Trip length and usable days

Usable days = full days on the ground + partial credit for the arrival and departure days (by local clock time) − a jet-lag cost that grows with the time shift beyond 3 hours (eastward costs more).

Weather

We count how often a day in the trip window was historically pleasant, then compare with the destination's own year. Favorable ≥ 50% pleasant days, Mixed ≥ 30%, otherwise Unfavorable. A high-severity hazard at its peak (hurricanes) is always a concern.

• city: high 14–29 °C, <2 mm rain, not muggy
• tropical-city: high 24–35 °C, <2 mm rain
• beach: high 25–33 °C, <2 mm rain, 5 h+ sunshine
• nature: high 8–25 °C, <2 mm rain

“Below the going rate” (while history builds)

No free source of historical international fares exists (US government fare data covers domestic routes only; OAG, Cirium and ATPCO are enterprise contracts; Google's price history isn't available without scraping). So until a trip's own history can judge it, the engine compares a fare with the fares on sale right now for similar trips on the same route.

To avoid calling ordinary structure a deal, every fare is first adjusted for departure weekday, return weekday, trip length and stops, using factors learned from the whole current market (e.g. Friday departures run about 6% higher); holiday-week fares are only compared with holiday-week fares. A fare counts as below the going rate when it is in the cheapest 5% of at least 12 comparable fares and at least 20% under their median: stricter than the history rule, because comparing across dates is noisier. It says the fare is cheap for the trip right now, not that it is low for the season; the label says which basis was used.

How good are the estimates?

For date combinations with no cached round-trip fare, search estimates one: α × (outbound one-way + return one-way), with α fit per route on cells where both exist (default 0.9 and ±25% until a route has 5+ pairs). A missing day borrows the nearest one-way within 2 days, with a wider range. Estimates are labelled ≈, never called deals, and every time a real round-trip fare appears for an estimated cell, the error is recorded here (α fit without that cell).

Do the calls hold up? (backtest)

For past dates, we judge trip windows using only the history available then, and check what the same trip cost afterwards (up to a week before departure). A good “Book window” call is one where waiting would usually have cost more. Run npm run backtest; with real fares recorded, -- --source observed.

No backtest run yet.

Data sources