Nobody names a room the same way twice: the hard part of hotel rate data

Hotel rate shopping sounds like the easiest data problem in travel. The rates are on a public page. There is no login, no quote engine, no expiry measured in minutes. You open an OTA, you read a number, you write it down. People reasonably assume the work is volume.

The number is the easy part. The hard part is knowing what the number is a price for — and on that question, the industry has agreed on almost nothing.

Room-type matching is the actual product

There is no shared identifier for a hotel room. None. The same physical room with the same bed and the same view is sold as a Deluxe King City View on the brand site, a Superior Double on one OTA, and a Premier Room, 1 King Bed, City View on another. The property next door uses Deluxe to mean what this one calls Standard. A third has decided its entry-level room is a Classic, which sits below its Superior, which sits below its Deluxe, which is the same tier as the first property's Standard.

None of this is sloppiness. Room names are merchandising, and a hotel has every incentive to make its entry-level room sound like somebody else's mid-tier.

So matching has to be inferred, from a handful of signals that are themselves inconsistently published: the name, bed configuration, maximum occupancy, floor area where it is given, view, and whatever amenity list the channel chose to show. Each one is partial. Together they are usually enough, and "usually" is doing real work in that sentence — this is the part of a rate feed that is genuinely hard to get right, and it is the part that decides whether everything downstream is signal or noise.

Get it wrong and you have not produced a slightly imprecise comparison. You have compared a suite to a standard double and concluded your competitor is expensive.

A rate is four numbers in a trench coat

Even with the room matched, a displayed rate bundles several decisions that have to be separated before two numbers can be compared:

• The rate itself, which may or may not include tax, and the convention differs by market and by channel.
• Occupancy. A rate for two is not a rate for one, and many channels default to two without saying so.
• Cancellation policy. A non-refundable rate is routinely 10–20% below the flexible rate for the identical room. Comparing your flexible rate to a competitor's non-refundable one is not a finding.
• Inclusions. Breakfast, resort fees, parking, city tax, service charge. A resort fee collected at the property does not appear in the headline price on most channels and can be a material fraction of it.

You need the curve, not tonight

Plenty of rate tools will tell you what your comp set is charging right now. It is the least useful thing they could tell you.

Rate decisions are made 30 to 90 days before arrival, which is when the bulk of demand for most properties actually commits. Tonight's rate is the price the market settled on under pressure, after inventory decisions were already made and with nothing left to influence. By the time it appears you cannot act on it.

What a revenue team needs is the whole booking window, repeatedly: the rate for every arrival date across the next three months, captured often enough that you can see the curve move. The signal is rarely the level. It is the shape — a competitor who drops 40 days out every Tuesday is managing a pickup problem, and that is a fact about their demand you can price against.

This is also the point where the volume stops being trivial. One property, one comp set of six, 90 arrival dates, three room types, two occupancies, refundable and non-refundable, twice a day: that is tens of thousands of observations a day for a single hotel. For a group, multiply by the estate.

Restrictions are the invisible half

Rate is one of two levers. The other is availability, and it is barely visible on a public page.

A competitor showing no rooms might be genuinely sold out, or holding inventory back for a group block, or closed to arrival on that date, or enforcing a three-night minimum that your single-night query silently failed. On most channels these look identical — the room simply does not appear.

They are completely different signals. A sold-out competitor is permission to raise your rate. A competitor enforcing a minimum length of stay on a shoulder date has told you they expect a compression event, which is a different and more useful thing to know. A feed that records only "unavailable" has thrown the distinction away. The restrictions — minimum length of stay, closed to arrival, closed to departure, and the shape of the closeout across adjacent dates — are inferrable if you query deliberately for them, and invisible if you do not.

Parity and leakage

The last piece is your own rate, which is easy to assume you already know.

You know what you loaded. You do not necessarily know what is being displayed. An OTA discounting into its own commission, a wholesale allocation resurfacing on a retail channel, an opaque site repackaging your rate — each produces a cheaper version of your room, competing with you, usually through the channel that costs you most. The guest sees one price and books it.

The only way to find it is to shop yourself with the same rigour as the comp set, across every channel, every day. It is unglamorous and it reliably pays for the feed on its own.

A worked example

A 120-room resort property. Average daily rate of $210, running 42% occupancy — about 50 rooms a night, roughly $10.5K in room revenue.

The revenue team's position is that the ADR is the one thing they have protected through a soft season, and dropping it would be giving away the year. The rate data says something more specific. Their comp set moved three weeks earlier, in the 30-to-60-day band, and they did not. On metasearch they appear third-cheapest of seven, which is where the team believes they sit — but that ranking is on the headline rate. Add the resort fee, which two competitors have folded into their displayed price and they have not, and they are second-most-expensive of seven at the moment of comparison.

They were not losing on rate. They were losing on the number the guest actually saw.

Repricing to $168 against the corrected comp set, and matching the inclusion convention, fills 109 of 120 rooms — 91% occupancy, about $18.3K a night.

Priced blind

$10.5K

Priced on market data

$18.3K

Room revenue per night

+74%

ADR fell 20% and room revenue rose 74%, because the unsold room was never saved for later. Tonight's empty room does not become tomorrow's inventory — tomorrow already has 120 of its own. RevPAR went from $88 to $153, and RevPAR is the number that pays for the building.

What good looks like

A rate feed is usable when it carries:

• Room-type matching as an explicit, inspectable field — with a confidence signal, so a revenue manager can see when the match is a judgement call rather than a certainty.
• Rate, occupancy, cancellation policy and inclusions as separate fields, never pre-blended into one comparable number by someone who guessed at your conventions.
• The full booking window, not the current night, captured often enough to show movement.
• Restrictions as first-class data — MinLOS, closed to arrival, closed to departure — distinguished from genuine sold-out.
• Your own property shopped alongside the comp set, on every channel, so parity breaks surface the day they happen.
• Capture timestamps, deduplication, a stable schema and backfill on failure — the same unglamorous plumbing any serious feed needs, for the same reasons set out in the airfare piece.

None of this is exotic. It is simply more work than it appears from the outside, which is the honest summary of most data problems — and the reason the interesting question is rarely "can you scrape it" but "can you still trust it in March".

---

We run this as a feed: hotel rate intelligence, by property, room type and date, across OTAs, brand sites and metasearch. If the problem you have is bigger than a feed, that is forward-deployed engineering, and it is the same team.