Updating Prices

A hotel price is the lowest price for a double-occupancy room for the given combination of check-in date and nights of stay (the itinerary).

Overview

The prices you define for hotel/itinerary combinations are central to hotel search results. It is very important that you keep your prices fresh, accurate, and competitive.

Google typically uses prices from its price cache when displaying search results. Whenever you send Google a Transaction message that contains pricing updates, Google caches that data.

Size of pricing updates

When setting prices for a room, you provide advanced booking and length of stay (LOS) values, with prices for each combination of those values and room ID/rate plan ID. The booking and LOS values default to the following:

  • Up to 330 days advanced booking
  • Up to 30-night stays

Based on these general guidelines, a single room's pricing can require up to 9,900 separate entries (330 * 30), one for each combination of the check-in date and number of nights.

The following matrix illustrates part of the itinerary data for a single hotel. Each cell with a price in the matrix represents one itinerary combination of a check-in date and a length of stay; each itinerary represents a separate value that Google requests for the property:

Which hotels and itineraries are repriced

The hotels that Google prices are defined by your Hotel List Feed. Unless they are disabled, all hotels in the Hotel List Feed are repriced with Transaction messages, or, in some cases, Live Queries.

You define "itinerary capabilities" (number of days in advance of check-in and the number of nights of stay) for hotels to reprice in your QueryControl messages.

Repricing process

The general process for updating prices is:

  1. You define the hotels to be priced in the Hotel List Feed (during initial setup and then occasionally).
  2. You define the length of stay and check-in date defaults, as well as overrides, in QueryControl messages (once per day).
  3. (Pull with Hints only) Google sends your server a HintRequest message.
  4. (Pull with Hints only) Your server responds with a Hint Response message that defines which hotel/itinerary combinations should be repriced.
  5. Google sends a Query message to your server. The Query message includes hotel IDs and itineraries that need prices.
  6. Your server responds with a Transaction message that defines the new prices.
  7. Google updates its cache with the pricing data from your response.

For more information about Pull and Pull with Hints, see Choosing a Delivery Mode.

Pricing with Transaction messages

To set prices for a hotel/itinerary (a combination of the check-in date plus the number of nights), use a Transaction message with one <Result> element for each itinerary.

Use the following guidelines when setting prices:

  • Rates: Provide the lowest available double-occupancy rate for each itinerary. Setting rates with the Hotel Prices API that are different from those that are shown on your site can be confusing to users and result in lost bookings.
  • Number of Nights: Specify the total cost of the stay for each itinerary, not simply the per-night rate. Google calculates the per-night rate for you.
  • Policies: Adhere to Google's price accuracy policy when setting rates. This requires that the prices that show up in Google's search results are not markedly different from the final booking price.
  • All-inclusive pricing: To be eligible to appear in the listings for US and Canadian end-users, your hotels must typically break out taxes and fees from the base rate. For more information, see Taxes and Fees Policy.
  • Rounding: Do not round values for prices, taxes, and fees.

For information on removing hotels from your inventory, see Removing Inventory.

Pricing message elements

When using Transaction messages to reprice itineraries, the following child elements of the <Result> element are required:

  • <Property>
  • <Baserate>
  • <Tax>
  • <OtherFees>
  • <Checkin> (itinerary)
  • <Nights> (itinerary)

You can optionally include the following child elements of the <Result> element:

  • <AllowablePointsOfSale>
  • <ChargeCurrency>
  • <Custom[1-5]>
  • <RoomBundle>
  • <RoomID>

For more information about each of these elements, see Transaction messages.

Pricing example

The following example sets the price for a room for 1 through 7 nights with a check-in date of June 6th, 2016:

<?xml version="1.0" encoding="UTF-8"?>
<Transaction timestamp="2015-08-24T20:44:56-04:00" id="42">
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>1</Nights>
    <Baserate currency="USD">209.99</Baserate>
    <Tax currency="USD">25.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>2</Nights>
    <Baserate currency="USD">419.98</Baserate>
    <Tax currency="USD">25.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>3</Nights>
    <Baserate currency="USD">614.97</Baserate>
    <Tax currency="USD">21.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>4</Nights>
    <Baserate currency="USD">819.96</Baserate>
    <Tax currency="USD">21.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>5</Nights>
    <Baserate currency="USD">999.95</Baserate>
    <Tax currency="USD">21.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>6</Nights>
    <Baserate currency="USD">1193.94</Baserate>
    <Tax currency="USD">21.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
  <Result>
    <Property>1234</Property>
    <Checkin>2016-06-07</Checkin>
    <Nights>7</Nights>
    <Baserate currency="USD">1259.93</Baserate>
    <Tax currency="USD">21.12</Tax>
    <OtherFees currency="USD">2.00</OtherFees>
  </Result>
</Transaction>

Each Transaction message can have any number of <Result> elements, as long as the total size of the message does not exceed 100MB.

Frequency of pricing updates

You should plan to update your prices as often as they change. How you do this depends on whether you chose the Pull or Pull with Hints method of updating pricing information. For more information, see Choosing a Delivery Mode.

The frequency and number of Live Queries that Google sends to you is also configurable. For more information, see Using Live Queries.

Using all-inclusive pricing

Depending on the geographic location of your end-users, you might consider using all-inclusive pricing instead of itemized pricing.

All-inclusive pricing includes the total value of the base rate of the room plus the taxes and fees in the <Baserate> element (in the Transaction message). Itemized pricing separates the price into the <Baserate>, <Taxes>, and <OtherFees> elements.

If your end-users are in the US or Canada, you should use itemized pricing where possible. This is because for US and Canadian end-users:

  1. Partners who provide only all-inclusive pricing will only be eligible to appear in the results if all other partners for the same hotel also provide only all-inclusive pricing.
  2. If some partners provide itemized prices and some partners provide all-inclusive prices, then only the partners who provide itemized prices will appear in the results.

These rules do not apply to any end-users outside of the US and Canada where all-inclusive prices are more generally used. For more information, see Price Accuracy Policy.