Pricing Delivery Modes

The delivery mode determines how you send pricing updates to Google for hotel and itinerary combinations. You and your Technical Account Manager (TAM) work together during your initial configuration to set up your delivery mode.

Overview of delivery modes

As a default, a hotel can be queried for up to 330 days in advance of room availability and up to 30 nights of stay, but you can determine the maximum number of itineraries (combination of check-in date and length of stay).

The more itineraries that you support, the more auctions you will participate in. However, the more itineraries you support, the more data you must send to Google to keep your pricing data accurate.

The typical methods of updating prices use Transaction messages in one of the following ways:

  • ARI (Push): A pricing delivery feed that utilizes rate plans, availability, and hotel metadata to set predefined pricing strategies for your properties. Unlike Pull and Changed Pricing, ARI feeds don't query for specific prices or itineraries. Instead, you push messages containing a subset of information that represent a pricing model for your properties based on various rate details, restrictions, and availability. ARI feeds uses the OTA XML specification (OTA_HotelRateAmountNotifRQ and OTA_HotelAvailNotifRQ) to define availability and pricing. Contact your account manager to learn more about the ARI delivery mode and to determine if this feed type would be best suited for your account. For more information, see Using ARI.

  • Pull: Google queries your service on a regular basis to refresh its cache of pricing and availability data. In this model, Google sends a request to your server, and your server responds with updated data. This model is best if you don't know exactly when pricing information changes, or if pricing information changes irregularly throughout the day. Prices stay in the cache until Google's algorithms determine that prices have become stale, based on partner-specific previous price change history. For more information, see Using the Pull Delivery Mode.

  • Changed Pricing (formerly Pull with Hints): Similar to Pull, except that Google only requests data for a subset of properties, not all properties. This mode can significantly reduce the amount of network traffic when updating prices and availability for your properties. Prices stay in the cache indefinitely until updated. For more information, see Using Changed Pricing.

In addition to updating prices, you can use Transaction messages to remove properties from your inventory. For more information, refer to Removing Inventory.

For more information about providing pricing updates, including examples of Transaction messages, refer to Updating Prices.

Live Pricing Queries

Google can also request some price updates at auction time with Live Pricing Queries. Live Pricing Queries are pricing requests from Google for a current auction. If you respond within the specified timeframe, then your ad should appear in the auction.

Google stores the response to a Live Pricing Query just as it does with any other Transaction message. As a result, Google can serve the price from its cache rather than send out another Live Pricing Query in the future.

For more information, refer to Live Pricing Queries.

Context

Pull and Changed Pricing queries generally don't specify information about the user since Google is using your responses to fill a cache which might be used to serve a variety of different users.

Since it could be expensive for you to return prices corresponding to a full set of possible user context, a feature is being tested where popular user contexts is specified as part of the query. The user contexts are based on user requests where you had an opportunity to show a price and are calculated to cover the vast majority of user requests. You might see a large number of user contexts for very popular properties or itineraries, but the average number of user contexts should be less than 10. You can return additional prices or ignore specified user contexts—it's up to you to decide what prices to return for a given query. However, ignoring a suggested user context could result in lower traffic.

ARI Push delivery mode

With the ARI Push delivery mode, you send incremental updates to Google whenever nightly rates, availability, inventory counts, or other restrictions change. Unlike Pull or Changed Pricing, ARI Push lets you to use a different pricing model to efficiently update various components of pricing information to Google.

The following diagram shows the request and response flow for the ARI Push delivery mode:

fig1

Step 1: Send ARI Push messages to Google

To update your data with ARI Push, send an ARI request message whenever your data changes. The ARI Push delivery mode supports various message types and pricing strategies. For detailed information about pushing messages, refer to Using ARI.

Your prices should be served by Google and visible to users within 15 to 20 minutes after a message has been received.

Step 2: Confirm data is successfully cached by Google

For each ARI Push message received, Google responds with the HTTP connection status and the ARI processing results. Google responds with an HTTP 200 OK if the connection to the server succeeds. It also includes a body with a response message indicating whether the updates were applied successfully or that it encountered delivery mode warnings or errors.

Allowlist IP Addresses

To allowlist any IP addresses that you use to push ARI messages to Google, use the Hotel Center ARI price settings page. Learn how to update your price settings in Hotel Center.

Update Room and Package metadata with ARI Push

Use the Transaction (Property Data) message type to define the active room types and rate plans (packages) for each property. You should push updates whenever room types or rate plans are added, removed, or modified. In this case, you send an XML message with the new information in the <RoomData> and <PackageData> elements. These elements are children of the <PropertyDataSet> element.

Connection or Content errors

If you receive a delivery mode error due to the XML being malformed or incorrect, find the recommended resolution in Feed Status Error Messages.

If you receive an HTTP connection error when sending an ARI message to Google, retry the request at 1, 5, and 20 minute intervals. If the problem persists after 3 retries, stop sending messages and contact Google support.

Pull delivery mode

With the Pull delivery mode, Google periodically sends Query messages to your server to request price updates. Your server responds to those messages with Transaction messages that contain updated pricing and availability data.

The following diagram shows the request/response flow of Pull:

fig2

After receiving the price updates, Google typically processes the new pricing and availability data within approximately 5 minutes.

The following sections describe each of these steps in more detail.

Step 1: Query message

By default, Google sends Query messages for all properties defined in your Hotel List. This could mean you should be receiving multiple Query messages during the repricing processes.

The pricing Query messages that Google sends to your server have the following characteristics:

  • The root element is <Query>.
  • Sent to the endpoint defined during your initial configuration. For more information, contact your Technical Account Manager (TAM).
  • Uses the HTTP POST method. (If you are using HTTPS, you need to get the domain signed by an official certificate authority.)
  • The Content-Type header is set to application/xml.
  • Each message includes up to 100 properties for which Google requests pricing and availability data.
  • The User-Agent header is set to Google-HotelAdsPrices.

Step 2: Transaction message

When your server receives a Query message, it must respond with a Transaction message that contains pricing information for the requested itineraries.

The root element of a Transaction message is <Transaction>. For more information, refer to Transaction Messages and Updating Prices.

Update Room and Package metadata

In addition to updating pricing data with Pull, you can also use Transaction messages to update your room and package metadata. For more information, refer to Defining room and package metadata.

Changed Pricing delivery mode

Changed Pricing helps reduce the size and quantity of Query and Transaction messages for pricing updates. When you use Changed Pricing, you send Google a list of properties that have updated prices. Google responds with a Query message that asks only for those properties' prices.

To configure the endpoint that Google sends Hint Request messages to, consult your Technical Account Manager (TAM). You would have set this up during initial configuration.

The following diagram shows the request and response flow for Changed Pricing:

fig3

The following sections describe each of the steps in this flow.

Step 1: Hint Request message

The Hint Request messages that Google sends to your server have the following characteristics:

  • Root element is <HintRequest>.
  • Sent to the endpoint defined during your initial configuration. For more information, contact your Technical Account Manager (TAM).
  • Use the HTTP POST method. (If you are using HTTPS, you will need to get the domain signed by an official certificate authority.)
  • The Content-Type header is set to application/xml.
  • At a specified frequency, Google sends a timestamp to your server that defines the last time you responded to a Hint Request message.
  • The User-Agent header is set to Google-HotelAdsPrices.

We recommend that you set the frequency to 5 minutes. To set or modify the frequency of Hint Request messages, contact us.

When you receive a Hint Request message from Google, you respond with all prices that have been updated since that timestamp. For more information, refer to Hint Request messages.

Step 2: Hint Response message

Your server responds to a Hint Request message with a Hint Response message. This message includes the hotel IDs and itineraries for properties whose prices have changed since the last time you received and responded to a Hint Request message.

The root element of a Hint Response message is <Hint>. For more information, refer to Hint Response Messages.

Step 3: Query message

Google receives the Hint Response message and responds with a Query message, just as with the standard Pull mode. The difference is that the Query message now contains only the hotel IDs and itineraries for the properties that you specified in the Hint Response message. The root element of a Query message is <Query>.

When determining which hotel IDs to request prices for with Changed Pricing, Google ignores the contents of your Hotel List Feed. This greatly reduces the size of the Query message that you receive from Google and the size of the Transaction message of your response.

Step 4: Transaction message

You send a Transaction message with a pricing update as a response to Google's Query messages. The root element of a Transaction message is <Transaction>. For more information, refer to Pull delivery mode.