Proxies for Hotel Rate Monitoring: Seeing the Prices Your Guests See

A revenue manager opens Booking.com on a Tuesday morning, types in the three hotels down the street, and writes their rates for the next 90 nights into a spreadsheet. That number is real, and it is also incomplete: it is the price Booking.com shows a logged-out visitor on a desktop in the hotel's own city, which is not the price the German family, the Korean tour group or the guest on the app is being shown for the same room. Proxies for hotel rate monitoring exist to close that gap. They let a hotel, a hotel group or the vendor that shops rates for them read each booking channel from the countries their guests actually book from, on the kind of connection guests use, at a volume the channels tolerate.

We are a proxy provider, and hotel rate monitoring is one of the older reasons people buy residential IPs from us. This page is written for the business side: what rate shopping is, why the market changed under it in the last two years, what your own office connection cannot see, how the collection scales, and what to ask any vendor who does it for you. For the technical treatment of the individual sites, we have separate pages on Booking.com, Expedia, Agoda, Hotels.com, Trivago and Marriott, and the general retail version in price monitoring.

Rate shopping, comp sets and parity, in plain words

Rate shopping is collecting the public prices of a chosen set of competitor hotels, across booking channels and future dates, on a schedule, and comparing them with your own. The set is your comp set: the 5 to 10 properties a guest would consider instead of yours. The channels are the places guests buy: Booking.com, Expedia and its brands, Agoda, the metasearch sites (Google Hotels, Trivago, Kayak) and each hotel's own website.

Parity monitoring uses the same machinery pointed at yourself: is the rate on your own website the same as, or better than, the rate every channel shows for your rooms? The industry's rate-shopping tools do both. The largest, Lighthouse (OTA Insight until its rebrand on 9 November 2023), reports serving more than 65,000 hotels in 185 countries and holding data on over 725,000 hotels and 19 million short-term rentals (Hospitality Net); RateGain sells a dedicated parity tool (RateGain). Every one of them is, underneath the dashboard, a large scraping operation that reads booking sites from many places, which is exactly the job proxies do.

Why the job got bigger: parity clauses fell, and Google started grading

For a decade the gap between a hotel's own price and its price on an online travel agency was contractually pinned. Parity clauses required a hotel to give the OTA a rate as good as any other channel. In their broad form they stopped a hotel from selling cheaper anywhere; in the narrow form they still stopped it from undercutting the OTA on its own website (Lighthouse, the decline of rate parity clauses).

That pin has been pulled out market by market. France made parity clauses void under the Loi Macron in 2015, Austria banned them in 2016, Italy in 2017 and Belgium in 2018 (ESHTE, Competition Law in Tourism). Then the European Commission designated Booking a gatekeeper under the Digital Markets Act on 13 May 2024 (European Commission), and Booking.com removed its parity requirements for properties in the European Economic Area from 2 December 2024 (Tourism Review). A hotel in Lisbon can now sell its own website cheaper than Booking.com, legally and by contract. Which means the direct-versus-OTA gap, for you and for every competitor, is a live number that moves daily, and the only way to know it is to measure it.

The pressure from the other direction comes from Google. Hotel Center scores each partner's price accuracy from Excellent to Failed by checking that the total price on the booking page is the same as the total price displayed on Google, mandatory taxes and fees included. Poor scores cost auction position, and a Failed score means your ads and free booking links are turned off (Google Hotel Center, Price Accuracy Policy). A rate that drifts between your channel manager, your booking engine and Google is no longer a small leak. It switches off a sales channel.

Underneath both is the reason hotels care about OTAs at all: the commission. Guides for hosts put Booking.com's standard commission at around 15 percent, in a range of 10 to 25 percent depending on country and property type (Wise). Every booking moved to the direct channel keeps that margin, and the billboard effect, which Cornell's Chris Anderson measured in 2009 by listing and delisting hotels on Expedia in alternate weeks and confirmed in 2017 as still alive, is the reason a hotel stays on the OTA anyway: the listing drives direct bookings too (Cornell eCommons). Managing that balance is a pricing decision, and it needs accurate prices.

What your office connection cannot see

The core problem is simple to state. Booking sites show different prices to different visitors, and the office sees exactly one visitor's version.

Booking.com's Country Rates are the clearest case. They are targeted discounts a hotel offers to guests from chosen countries, and in Booking.com's partner documentation they are only visible to guests using Booking.com from an IP address matching the targeted country (Booking.com for Partners, Country Rates). If your competitor across the road is giving Dutch guests 10 percent off all year, your spreadsheet, filled in from your own city, will never show it. You will read their rate as higher than it is for the guests you are both competing for.

Currency follows the visitor's location on every major OTA. Genius, Expedia's member prices and the equivalents elsewhere appear only when logged in. Mobile Rates on Booking.com are shown to guests on the app or mobile site. Metasearch results on Google Hotels and Trivago are localized to the visitor's country and currency. Each of these is a version of the market you can only see by being the visitor it is meant for.

There is a second, quieter problem. The office connection is one address, and it comes back every day at the same hour asking the same questions. That is the most recognisable pattern a booking site's bot management sees, and the sites answer it with rate limits, challenges and eventually blocks. A hotel that shops its comp set from its own line will, at some point, find the line throttled on the very site it also sells through.

How proxies fit, by who is doing the shopping

If you use a rate-shopping vendor, you do not run proxies. Your vendor does, and the quality of what you see is decided by how. The questions to ask are short: from which countries do you shop, and can I choose my feeder markets? On what kind of connection: datacenter or residential? How often per day, and is the near-term window shopped more often than far dates? Do you shop member rates and mobile rates as separate lines? Do you read the total price with taxes, the way Google scores it? A vendor that shops every market from one datacenter is shopping the office's version of the market at scale.

If you are a hotel group or a vendor building the collection, the setup mirrors what we describe for each site. Rotating residential proxies, pinned to each source market, for the public rates on the OTAs and metasearch, because those sites localize by the visitor's IP and challenge datacenter ranges. A static residential (ISP) exit for any logged-in shop, because a member session has to stay on one address. A mobile exit and a mobile user agent when you want the mobile-only layer. Plain datacenter for your own website and for any open feed. The per-site detail (URL parameters, session handling, page weight) is in the pages linked above, and the request hygiene that applies to all of them is in avoiding IP bans while scraping.

Use the sanctioned data where you can. Your own rates are in your channel manager and your Hotel Center price accuracy report; you never need to scrape yourself. Booking.com's Demand API and Expedia Group's Rapid API exist for partners who send those platforms bookings, and where a rate-shopping business qualifies, an API removes a whole site from the scraping problem. What the APIs do not give you is the competitor's Country Rate as a German guest sees it, which is why residential exits in feeder markets remain the core of the job.

The arithmetic: why this is a volume problem

Rate shopping looks small until you multiply it out. Take one property with a comp set of 8 hotels, shopped on 4 channels, across 90 arrival dates, twice a day, from 3 source markets.

Seventeen thousand reads a day, for one hotel, is a monitor's signature from a single address and an unremarkable trickle across a residential pool. A 60-property group is over a million reads a day. Sizing therefore starts from shops per day and page weight, not from a count of addresses. On a pay-as-you-go plan the bill is gigabytes: request the HTML, skip images and scripts, cache what does not change between passes, and the cost per read falls to a fraction of a cent. Shop near-term dates twice a day and far dates once, because that is where the movement is, and the volume halves again.

Sizing (rotating residential, one property):
  reads/day  = comp set x channels x dates x passes x markets
             = 8 x 4 x 90 x 2 x 3 = 17,280
  bandwidth  = reads x page weight after trimming
             = 17,280 x ~150 KB (HTML only)  ~ 2.6 GB/day
             = 17,280 x ~1.5 MB (full pages) ~ 26 GB/day

Trim the pages first. The address count takes care of itself:
  the pool spreads 17,280 reads so no exit looks like a monitor.

Our pricing is per gigabyte with no monthly minimum and a balance that does not expire, which suits a job whose volume changes with the season.

What to shop, so the comparison means something

Proxies get you to the page. The comparison is still a data problem, and most bad rate-shopping decisions come from comparing the wrong things.

• The same room, the same terms. Lowest available public rate, same room category, same occupancy, same cancellation policy, same inclusions. A refundable king with breakfast against a non-refundable double is not a price difference.
• Total price, taxes in. Google grades on the total, and guests decide on it. Read the price the way the guest reads it at the last step.
• Each layer as its own line. Public rate, member rate, mobile rate, Country Rate per feeder market. Averaging them hides the discount your competitor is actually selling.
• Your feeder markets, not every market. Your property management system tells you where your guests come from. Shop from those three or five countries and skip the rest.
• Frequency by distance. Near-term dates move several times a day; dates three months out move weekly. Shop accordingly, and your volume and your bill both drop.

The limits worth knowing

Proxies solve two things for hotel rate monitoring: they let each read come from the market whose price you want, on a connection that market's guests use, and they spread a daily shop wide enough that no booking site sees a monitor. They do not solve room mapping, they do not reveal the hotel behind an opaque deal, they do not give you a member rate without a member account, and they do not change the terms of service of the sites you read. Scraping an OTA runs against its terms whether or not you use a proxy, and the DMA obligations on Booking are about Booking's conduct toward hotels, not a licence to scrape it. Where an API or your own channel data covers a need, use it first.

What good proxies give a hotel is the market as its guests see it, from every country that matters, every day, without the office line being throttled for asking. For a first look, our free proxy list and proxy checker cost nothing. For a shop that runs on a schedule, rotating residential at $0.44/GB pay-as-you-go, pinned to your feeder markets, is the setup underneath every serious rate-shopping product, and it is available to a 40-room hotel on the same terms as to a group.

Sources

• Hospitality Net, OTA Insight rebrands as Lighthouse, 9 November 2023, on hotels served and data coverage.
• RateGain, rate parity management.
• Lighthouse, the decline of rate parity clauses and what this means for hotels, on broad and narrow parity.
• ESHTE, Competition Law in Tourism, on the French, Austrian, Italian and Belgian bans.
• European Commission, Booking must now comply with the Digital Markets Act.
• Tourism Review, parity clauses removed by Booking, 2 December 2024.
• Google Hotel Center, Price Accuracy Policy.
• Booking.com for Partners, Country Rates.
• Wise, Booking.com commission percentage.
• Cornell eCommons, The Billboard Effect: Still Alive and Well, Chris Anderson.