Product normalization is the process of bringing structure and standard to the unstructured and inconsistently named room-rate information returned from multiple supply sources in Content Services for Lodging.

This allows for a like-for-like comparison of room rates across multiple sources to make more informed and efficient choices during the shopping and booking process.

Without normalization, comparing similar products across multiple sources is not possible due to inconsistently described room-rate details and lack of rich content available through some channels.

Point of sale (POS) systems can integrate the normalized attributes to easily group, sort, filter and compare like-for-like rates across multiple sources during shopping and provide the following benefits.

1. Easy comparison - Group rates under a standardized room type and easily compare them across sources
2. Opportunity to increase revenue – Highlight rate inclusions, meal plans and amenities etc. to upsell and increase conversion
3. Improved performance - Faster selection of products at the initial shopping result, leading to improved performance
4. Traveler satisfaction – Provide best offer matching traveler preference

No. Product normalization is part of Content Services for Lodging offering and normalized attributes are returned within Content Services for Lodging Shopping API responses.  No separate activation is required.

Currently, the following product attributes are identified to be mostly either unstructured or inconsistently named across supplier responses. These attributes are normalized and returned as structured OTA codes and descriptions in the shopping response.

1. Room Type (i.e. Deluxe Room, Suite)
2. Room View (i.e. Mountain View, River View)
3. Bed Types (i.e. King, Queen)
4. Room Amenities (i.e. Minibar, Work Area, Ironing Board)
5. Rateplan Inclusions or Value adds (i.e. Free Internet, Free Parking)
6. Meal Plan (i.e. Free Breakfast, Full Board)

All active versions of the following APIs (SOAP and REST) support product normalization.

1. GetHotelDetailsRQ
2. GetHotelRateInfoRQ
3. HotelPriceCheckRQ

Support for the following APIs will be available in the future.

1. GetHotelAvailRQ
2. GetHotelLeadRateRQ

Yes. We are reviewing additional attributes such as commission, loyalty and # of bedrooms where normalization can add value. As more attributes are added, we will advise via release notes.

Product normalization does primarily two things to structure and standardize shopping responses across sources

1. Structuring the unstructured content
   • Shopping responses from multiple suppliers are parsed out to extract important room-rate level attributes if they are returned in a semi-structured or unstructured(i.e. free text) form.
2. Normalizing product attributes across sources to a common standard
   • Product attributes may be described differently across sources. Example – “King Bed” is described as “Extra Large Bed” from Booking.com.
   • The normalization process ensures product attributes that have the same meaning are mapped to specific Open Travel Alliance(OTA) codes irrespective of how each supplier may describe them.

The normalization happens dynamically after shopping responses are received from multiple supplier systems for an availability request.  The normalization process is very fast, efficient and quickly returns the structured shopping response to the CSL API user and then Point of Sale.

No. It depends on a specific supplier or channel. For example, hotel chains return much of the rate details in free text form as rate name and description. These free texts are processed to extract relevant product attributes before normalizing them to common OTA codes.

Whereas aggregators generally return content in either structured or semi-structured form and free text processing not required for the most part.

Currently, the rate name is used to normalize room type for all inventory sources. For GDS chains, rate text is also used in addition to rate name.

Rate name is returned in ../Rooms/Room/RoomDescription/@Name

Rate text is returned in ../Rooms/Room/RoomDescription/Text

<RoomDescription Name="Premier Room, 2 Double Beds">
   <Text>Premier room with courtyard view,2 Double Bed,  All-inclusive – all meals included for 2 adults, Disability Access, Non-Smoking, free wifi, visual door alert and fire alarm, roll-in shower, air conditioning, seating area and tea/coffee maker</Text>
</RoomDescription>

We continue to evaluate and improve our systems to provide richer, standardized and structured content. We will make necessary modifications to the normalization algorithm in an on-going basis including the processing of additional content as applicable.

CSL API response itself does not differentiate between normalized and unnormalized product attributes. Please refer to developer guidelines for information related to normalized attributes.

The Help tab will be updated if more attributes are normalized in the future.

The chances for potential conflicts or errors are rare and mostly limited to previously unseen or rarely shopped rates.

The normalization algorithm and associated dictionary of phrases to extract information from unstructured content are developed by analyzing millions of availability responses that are processed through Content Services for Lodging every day and tested for high accuracy.

Additionally, we monitor and log information from millions of shopping data processed every day for potential conflicts.  This data is reviewed periodically and corrections are made if needed by updating the dictionary rules of the normalization algorithm.

Please contact Sabre web services support with relevant details and samples. Our teams will review and make the necessary corrections as quickly as possible for genuine errors.

To minimize the potential risk, we recommend displaying original room-rate name and description returned as-is from suppliers before and after making the reservation for clarity of what is being purchased.

Rate name is returned in ../Rooms/Room/RoomDescription/@Name

Rate text is returned in ../Rooms/Room/RoomDescription/Text

<RoomDescription Name="Premier Room, 2 Double Beds">
   <Text>Premier room with courtyard view,2 Double Bed,  All-inclusive – all meals included for 2 adults, Disability Access, Non-Smoking, free wifi, visual door alert and fire alarm, roll-in shower, air conditioning, seating area and tea/coffee maker</Text>
</RoomDescription>

There is no globally accepted list of standard room type definitions that are followed in the industry. Different naming conventions exist across suppliers. CSL supports those which are most common and used by the majority of the hoteliers.

Hoteliers often include promotional offers, inclusions and booking conditions as part of the room type or rate name and they frequently change. Many hoteliers use non-standard room type names to merchandise different product offerings and drive conversion, e.g. “Wonderful Sky Room”.

Most of the hotel rooms can be mapped to one of the common room types even if they are described differently by different suppliers, e.g. “Club Tower Suite” is mapped to “Executive/Club Suite”.

When this is not possible, we work with suppliers to understand the unique characteristics of the room and create a new room type name if needed.

We have automated and manual verification processes to measure the accuracy of our algorithm on an ongoing basis. The test results are measured across all four classification variables in the confusion matrix as below.

1. True Positive
   • Attribute present in supplier response, correctly recognized as available and returned in CSL response.
   • Ex. Deluxe Room is correctly normalized and returned in CSL response.
2. True Negative
   • Attribute not present in supplier response, correctly recognized as not available and not returned in CSL response.
   • Ex. Room does not have a view and no view is returned in CSL response.
3. False Positive
   • Attribute may or may not be present in supplier response, but incorrectly recognized as available and returned in CSL response
   • Ex. Deluxe Room normalized as Standard Room and returned in CSL response.
4. False Negative
   • Attribute present in supplier response, but incorrectly recognized as not available and not returned in CSL response
   • Ex. Deluxe Room not normalized, and no room type returned in CSL response.

The algorithm is frequently evaluated to meet the following threshold of metrics to provide accurate content and deliver a better user experience.

1. Accuracy > 97%
   • Normalization is accurate when it is either True positive or True Negative.
   • Accuracy = ((True Positive + True Negative) / Total Predictions) * 100
2. Precision > 99%
   • Precision = (True Positive / (True Positive + False Positive)) * 100

We continue to enhance our solution to improve accuracy and precision.

The normalization process relies on the availability response returned from suppliers to normalize the content.

The depth of content returned in availability responses across suppliers may vary and it will have a consequent impact on what we can normalize. If you have feedback on a specific property or chain, please report the issue directly to the property in addition to sending it to Sabre.

You can build a bespoke shopping experience for your customers by integrating normalized attributes in the shopping workflow.

Some use cases are highlighted below.

1. Group rates from multiple suppliers under a standardized room type
2. Provide full clarity on available room types and price range for each room
3. Use structured data to highlight inclusions and meal plans to differentiate offers
4. Display rates at various price points for easier comparison & selection.
   1. i.e. lowest refundable rate, lowest rate with breakfast included
   2. Promote rates offering best value and commission
5. Sort and filter for a specific room and rate using structured content
   1. Ex. Filter for Room Type, Bed Type, Room View, Amenities etc.
   2. Ex. Filter for Breakfast rates, flexible rates, prepaid vs postpaid, value-adds, Loyalty etc.
   3. Ex. Sort rates based on price, commission etc.

A list of all relevant OTA codes and descriptions for the normalized values are provided in the CSL API reference data available in Dev Studio (link below).

 https://developer.sabre.com/guides/travel-agency/content-services-for-lodging-api-support

Developer guidelines for product normalization must be used in conjunction with the API reference data (refer sheet name “Normalized Product Attributes”) for integrating normalized codes/descriptions in the point sale application.

The normalization algorithm and mapping logic are proprietary of Sabre.

No. Sabre defined codes are used whenever appropriate OTA codes are not identified for specific values. Sabre defined codes are designed to complement the existing OTA codes for the specific attribute type.

CSL API reference data list includes both OTA and Sabre defined codes for all normalized attributes.

2017B version 1.

No.

The current list of mappings and values are generated by processing millions of shopping responses that are processed through our platform every day. Although these mappings cover most of the values we have seen so far for different product attributes, new values may be discovered in future as new properties and rates become available.

We frequently monitor the performance of the normalization algorithm and have automated systems to identify unmapped values. Once identified, these new values are processed and made available in shopping responses.

Updates on new codes, attributes or any changes will be communicated through release notes and CSL API reference data will be updated in Sabre Dev Studio as well.

https://developer.sabre.com/release_notes

https://developer.sabre.com/guides/travel-agency/content-services-for-lodging-api-support