What is a rate shopper? What a competitor price tool shows and what it hides
A rate shopper records what a guest sees, not why that price exists. Learn what it misses, how to check parity, and when to buy a tool.
Contents
Key takeaways
- A rate shopper records what a guest sees on a public booking page at a moment in time; it does not record why that price exists.
- Two prices are comparable only when room type, board, cancellation terms, length of stay, number of guests and tax basis match.
- Contract and wholesaler rates are negotiated privately and never appear on a public page, so a rate shopper cannot see the prices a resort actually sells most of its rooms at.
- The test before paying for a tool is simple: name one decision from last month's log that this data would have changed.
- A rate shopper supplies an input; a person supplies the decision. Automatic matching turns a reading tool into a pricing policy nobody wrote.
A rate shopper is software that reads publicly displayed room prices, for your hotel and a chosen set of competitors, on chosen dates and booking sites, and puts them side by side. It shows what a guest would see at that moment. It does not show whether those prices are comparable, or why they were set.
On Monday morning a revenue manager opens a rate shopper, sees a rival at a lower price for the same night, and cuts the rate. On Wednesday the rival's price turns out to have been a single room, non-refundable, no breakfast, on a three-night stay. The number was accurate. The comparison was not. After reading this you will know what a rate shopper for hotels actually collects, why two numbers on its screen are rarely the same product, and how to decide whether to pay for one.
What is a rate shopper, in plain words?
A rate shopper is software that opens public booking pages on your behalf, records the prices it finds for your hotel and a chosen set of competitors, and lays them side by side for chosen dates. It replaces a person opening tabs on booking sites and hotel websites, writing prices into a spreadsheet, several times a week.
What it produces is a grid of dates against hotels and channels, holding the price a guest was shown at that moment. Better tools also keep history, so you can see when a price moved and by how much. The unit it works in is a price for a stay, not a rate plan: the screen usually shows the cheapest available price for the dates entered, which is always one specific product.
It does not see a competitor's costs, demand, occupancy or contract rates, and it decides nothing. It reads. The value sits in the decision, not in the grid, which is why hotels buy it: to spend less time reading and more time deciding.
NoteThree systems, three jobs
The property management system holds the hotel's own rooms and prices. The channel manager sends those prices to booking sites. The rate shopper reads the prices that result, on public pages, and changes nothing.
What does a rate shopper actually read, and how often?
It reads the prices a guest would see on public booking pages: the hotel's own website, the booking sites it sells on, and sometimes metasearch results, for the dates you set. Coverage differs by tool and by market, and a hotel with no online availability on a site simply does not appear.
The session matters more than most buyers expect. Many sites show different prices to different visitors, through member rates, mobile rates, currency, country of origin or stored cookies. The shopper sees one version of the page, not every version. Frequency ranges from several times a day to once a week, set per hotel and per date range; more frequent reads cost more and matter most close to arrival. Reading tonight's price is a different job from reading prices ninety days out, and the second is where pricing decisions are actually made.
Currency and tax basis need attention too. Some sites show prices before tax, or in the visitor's currency. You must know whether the tool normalizes this or passes it through. What it cannot read at all: closed sites, prices behind a login, negotiated corporate rates, contract rates, and anything quoted by email or telephone. Availability is information as well: a competitor showing sold out, or a very high price that closes out the date, tells you something a price alone does not.
Watch outOne page, one visitor
A price captured from a booking site is one rendering of one page for one visitor. Treating it as the hotel's price for everyone leads to wrong conclusions about both the rival and your own position.
Why is a price on the screen not like for like?
Because a booking page price is the total for a specific product: a room type, a board basis, a cancellation rule, a length of stay and a number of guests. Change any one and the number changes. The cheapest room in a hotel is usually the smallest, so comparing your standard double with a rival's single room is not a comparison.
Board is a real cost carried by one hotel and not the other, not a discount. A non-refundable rate is a different product from a flexible one, and the gap between them is the price of flexibility. Many hotels price a three-night stay lower per night than a single night, so a shopper reading one night sees a different hotel from the one a week-long guest sees. Prices are usually quoted for two adults; a single traveler or a family of four is shown a different number for the same room. Member, mobile and packaged rates are prices for a subset of visitors, not the public price.
The working rule is simple: write the attributes down before you compare. If two prices differ on any attribute, you have two products, not two prices.
| Attribute | What varies between two screens | What to do before comparing |
|---|---|---|
| Room type | Size, view, floor, capacity | Match room types, or note the gap |
| Board basis | Room only, breakfast, half board | Add or strip the meal cost before comparing |
| Cancellation and prepayment | Flexible vs non-refundable | Compare like with like, never mixed |
| Length of stay | One night vs three or seven | Read the same stay length for both |
| Number of guests | One, two, four | Set the same occupancy in both searches |
| Taxes and fees | Included or excluded | Normalize to one tax basis |
| Currency | Lira, euro, dollar | Convert at one rate, on one date |
| Access channel | Member, mobile, package | Compare public rates only, or note the channel |
If any attribute differs, record it and treat the two prices as different products. This is the same discipline you apply when choosing a competitive set and comparing rates fairly.
How do you use a rate shopper for parity and leakage checks?
You use it as evidence, not as a verdict. The shopper shows what is displayed; you then decide whether the difference is a parity breach, a different product, or a rate that has leaked.
A parity check compares your own site with a booking site for the same product: the same room, board, terms and date. Anything else is a product comparison, not a parity check. A fixed routine beats a daily panic: same day of the week, same set of dates, same set of channels, recorded in the same format each time. Keep the capture with date, time, currency, tax basis, room and terms. A conversation with a distribution partner needs that record, not a memory of a screen.
Leakage is a net or contract rate appearing publicly below your published price. The shopper shows the symptom; tracing the cause needs the booking path and the partner, which is a separate exercise. Before calling anything a breach, separate it from a legitimate difference: a member rate, a mobile rate, a package with breakfast, or a different room type explains most apparent gaps. Then act on the cause, not the number. A stale rate, a mapping error or a rate loaded into the wrong channel is fixed at the source; matching the displayed price hides the fault. Read the market as well as your own brand, since the same grid shows where you sit against the set, which is a pricing input and not a parity issue.
TipFour things to record with every capture
Date and time of the read; currency and whether tax is included; room type and board; cancellation and prepayment terms. Without all four, the capture cannot be used in a parity conversation.
For the routine itself, a fixed weekly pattern works well: see a weekly rate parity routine for direct and booking-site prices.
What can a resort selling on contracts not learn from a rate shopper?
It cannot learn the prices the hotel actually sells most of its rooms at, because contract and wholesaler rates are negotiated privately and never appear on a public booking page. A tour operator or wholesaler buys rooms at a net rate agreed for a season. That rate is invisible to the shopper, so the largest part of the hotel's business is outside the grid.
What the shopper does show is the retail price of the package the operator sells, where it is public. That is the operator's price, carrying the operator's margin and often a flight, not your room price. A static contract fixes a price for a season, a dynamic one follows your availability and price; the shopper can only see the second, and only where it surfaces publicly. Rooms held for an operator leave your inventory on a release date, and the shopper sees the effect, a date that looks sold out or expensive, never the cause.
For the contract side, use pickup and pace from your own property management system, the contract terms themselves, and the operator's reporting. The shopper is a market view, not a channel view. It still earns its place for the public price of the destination, the hotel next door, and the retail price your own direct channel shows on the same dates. If you are weighing contract structures, the choice between static or dynamic rates for tour operators and wholesalers is decided by those terms, not by anything on a shopping grid.
Key pointMarket question, not channel question
For a contract-heavy resort the rate shopper answers a market question, not a channel question. Contract performance is read from pickup and contract terms; the shopper only tells you what the public market looks like while those contracts run.
By hand or by tool: how do you decide?
You decide with your own decision log. If the tool would have changed a decision you actually made last month, it earns its place; if not, a fixed weekly read by hand does the same job.
Count the work first: hotels in the set, multiplied by dates, channels and reads per week. A small set read once a week is an hour of work; a large set read daily is not. Then run the test: open last month's decisions and name one that would have come out differently with better price visibility. If you cannot name one, the gap is process, not information. Run the reverse test too: name a decision you made badly because you were reading prices by hand, late or incompletely. That names the cost of staying manual.
Beyond speed, a tool adds history, so you can see when a price moved; consistency in dates and channels; and a record you can put in front of a partner. It does not add judgment, comparability, or any knowledge of why a competitor moved. Those stay with the person reading the grid. The cost side includes the subscription, the time to configure the set and the room mapping, and the risk of reacting to a number nobody normalized. Start small: a fixed weekly read by hand, recorded in one format, tells you within a month whether a tool would change anything. The decision log itself is worth building regardless: see building a weekly revenue meeting with a decision log.
What should you ask before paying, and what should you never do with the data?
Ask what the tool reads, how often, in which currency and tax basis, and whether you can export the history. Never contact competitors about prices, never share your own forward rates, and never let a machine reprice without a person.
ChecklistBefore signing, get written answers to this checklist
- Which sites are covered, and which are not
- How far ahead the date horizon reads
- How often each hotel and date range is read
- Which room type and board basis is recorded, and whether you can change it
- How currency and taxes are normalized
- How long history is kept, and in what form it exports
- Who configures and maintains the competitive set and room mapping
- How sold-out and closed dates are handled
Never contact a competitor about their prices or yours. That is a competition-law question, not a revenue tactic, and it needs advice from counsel on your own case. Never share your own forward rates or pricing plans with competitors, in a group chat or anywhere else. Never let the tool reprice automatically: a rate change is a decision with a reason, and the shopper supplies an input while a person supplies the decision. And never treat a capture as proof of a parity breach until you have checked the product behind it.
What to do next
The pieces fit in one order: define the competitive set, normalize the product before comparing, use captures as evidence in a fixed weekly routine, and accept that contract business sits outside the grid. The single next step is to open last month's decision log and try to name one decision a rate shopper would have changed. If you can name it, the tool has a job. If you cannot, fix the routine first and buy the tool later.
Frequently asked questions
Is a rate shopper the same as a price comparison website?
No. A comparison site is built for travelers to find and book a room. A rate shopper is built for the hotel to record the same public prices over time, across a chosen set and a chosen set of dates, with history and export. They read similar pages for opposite purposes.
Can a rate shopper show a competitor's occupancy or revenue?
No. It reads displayed prices only. Occupancy, revenue and costs are not published by hotels, so any figure claiming to show them is an estimate built on assumptions, not a reading. Treat such figures as a hypothesis to test, never as data.
Is it legal to track competitors' public prices?
Reading prices that anyone can see on a public booking page is ordinary market research. What you do with the information, and any direct contact with competitors about pricing, is where competition law applies. Confirm your own situation with a legal adviser rather than relying on a general answer.
How often should a small hotel shop its competitors?
As often as you change prices, and more closely as arrival approaches, because that is when the decision matters. There is no universal frequency: a fixed weekly read plus a closer look in the final days before arrival covers most small hotels, and the right answer is the one your decision log can justify.
Do I need a rate shopper if most of my business comes through tour operators?
Less for the contract side, because those net rates are never public and the tool cannot see them. More for the retail price of your destination and the price your own direct channel shows. Pair it with pickup and pace reports from your own system, which answer the contract question the shopper cannot.