Skip to main content

Product Normalization

Introduction

CSL APIs provide multi-source and source agnostic lodging content via a suite of orchestrated and granular APIs, providing more than a million unique properties with richer content for travel buyers globally.

As room-rates from multiple sources are brought together into a single display, agencies, corporations, and other travel partners need to easily compare similar products (room-rates) across sources.

Content Fragmentation

Lodging distribution is highly fragmented and overly complex, leading to inconsistently named product attributes (i.e. Room Type) across different suppliers.

Each supplier or channel partner may describe the same product differently, enforce different naming conventions and standards for various room and rate level attributes such as room type, bed types, amenities, inclusions and meal plan etc.

There is also a variation in the depth of content available through different channels, making it nearly impossible to compare like-for-like products across inventory sources.

Product Normalization

Product normalization in CSL solves this problem by structuring and normalizing product attributes across sources to a common standard.

CSL APIs bring the power of industry-leading normalization at room and rate level to compare like-for-like products across sources.

How It Works

The inconsistently named and unstructured product information from hotel supplier responses are parsed out dynamically, normalized and returned as structured Open Travel Alliance (OTA) codes and descriptions in CSL API responses.

Point of sale (POS) systems can integrate these normalized and standardized attributes to enable customers to easily group, filter, sort and compare like-for-like products across suppliers during shopping.

Normalized content brings 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

Technical Details

Overview

Currently, the following product attributes are identified to be mostly either unstructured or inconsistently named from multiple supplier responses. These attributes are normalized and returned as structured OTA codes and descriptions in the CSL 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)
  7. Taxes & Fees (i.e., Resort Fees, City Tax, VAT)

These normalized product attributes are returned in specific elements and attributes within the shopping API response as mentioned below.

Product Attribute

OTA Code List*

Xpath

Room Type

GRI

../Rooms/Room/@GuestRoominfo

Room View

RVT

../Rooms/Room/@RoomViewCode

Bed Type

BED

../Rooms/Room/BedTypes

Room Amenities

RMA

../Rooms/Room/Amenities

Rateplan Inclusions

HAC

../Rooms/Room/RatePlans/RatePlan/RatePlanInclusions

MealPlan

MPT

../Rooms/Room/RatePlans/RatePlan/MealsIncluded

Taxes & Fees FTT

../Rooms/Room/RatePlans/RatePlan/RateInfo/Taxes/TaxGroups/TaxGroup/@Code

../Rooms/Room/RatePlans/RatePlan/RateInfo/Fees/FeeGroups/FeeGroup/@code

* If specific codes are not available in OTA list, Sabre defines custom codes to support them in CSL. Refer API reference data for a full list of codes (including Sabre codes) for each normalized attribute.

List of 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

Developers must use this document in conjunction with the API reference data (refer sheet name “Normalized Product Attributes”) for integrating normalized codes/descriptions in the point sale application.

Note: As new codes or attributes are normalized in future, the changes will be communicated through release notes and the API reference data will be updated in Sabre Dev Studio.

Normalized Product Attributes

Room Type

Room Type is normalized and mapped to OTA type “Guest Room Info (GRI)” and returned in ../Rooms/Room/@GuestRoominfo attribute.

Developers must use the CSL API reference data (link above) to match the room type description for the OTA code returned.

Room View

Room view is normalized and mapped to OTA type “Room View Type (RVT)” and returned in ../Rooms/Room/@RoomViewCode attribute.

Developers must use the CSL API reference data (link above) to match the room view description for the OTA code returned.

Bed Types

Bed Types are normalized and mapped to OTA type “Bed Type (BED)” and returned in ../Rooms/Room/BedTypes element.

  1. Both Bed Type and the number of beds (count) are returned (if returned by supplier). i.e. 2 Double Beds

SOAP - 

<BedTypes>
   <BedType Code="1" Count="2"/>
</BedTypes>

REST - 

"BedTypeOptions":{
    "BedTypes":[
        {
           "BedType":[
              {
                 "Code":1,
                 "Description":"Double",
                 "Count":2
              }
           ]
        }
    ]
}
  1. Currently, only a single Bed Type configuration is supported. i.e.  1 King and 1 Queen Bed

SOAP - 

<BedTypes>
   <BedType Code="3" Count="1"/>
   <BedType Code="5" Count="1"/>
</BedTypes>

REST - 

"BedTypeOptions":{
    "BedTypes":[
        {
           "BedType":[
              {
                 "Code":3,
                 "Description":"King Bed",
                 "Count":1

                 "Code":5,
                 "Description":"Queen Bed",
                 "Count":1
              }
           ]
        }
    ]
}
  1. Multiple Bed Type configuration will be supported in a future release. i.e. 2 King Beds or Queen Beds.

Developers must use the CSL API reference data (link above) to match the bed type description for the OTA code returned.

Room Amenities

Room facilities are normalized and mapped to OTA type “Room Amenity Type (RMA)” and returned in ../Rooms/Room/Amenities element.

SOAP - 

<Amenities>
   <Amenity Code="19" Description="Coffee/Tea maker"/>
</Amenities>

REST  - 

"Amenities": {
    "Amenity": [{
           "Code": 19,
           "Description": "Coffee/Tea maker"
         },
         {
           "Code": 144,
           "Description": "Soundproofed room"
         }
     ]
}

Both OTA code and description for each amenity are returned in the response.

Rateplan Inclusions

Value adds are normalized and mapped to OTA type “Hotel Amenity Code (HAC)” and returned in ../Rooms/Room/RatePlans/RatePlan/RatePlanInclusions element.

SOAP - 

<RatePlanInclusions>
   <RatePlanInclusionDesciption Name="Free Internet" Code="222"/>
</RatePlanInclusions>

REST - 

"RatePlanInclusions": {
   "RatePlanInclusion": [{
       "Description": "Free high speed internet connection",
       "Code": 222
    }]
}

Both OTA code and description for each value add are returned in the response.

Meal Plan

Meal plan information is normalized and mapped to OTA type “Meal Plan Type (MPT)” and returned in ../Rooms/Room/RatePlans/RatePlan/MealsIncluded element.

SOAP - 

<MealsIncluded MealPlanIndicator="true" MealPlanCode="4"/>

REST  - 

"MealsIncluded": {
     "Breakfast": true,
     "MealPlanIndicator": true,
     "MealPlanCode": 4,
     "MealPlanDescription": "Buffet Breakfast"
}

Developers must use the CSL API reference data (link above) to match the meal plan description for the OTA code returned.

Taxes and Fees

Taxes and Fees information is normalized and mapped to OTA type “Fee Tax Type (FTT)” and returned in ../Rooms/Room/RatePlans/RatePlan/RateInfo/Taxes/TaxGroups/TaxGroup/@Code  & ../Rooms/Room/RatePlans/RatePlan/RateInfo/Fees/FeeGroups/FeeGroup/@code element.

SOAP  -

<TaxGroups>
        <TaxGroup Amount="45.49" Code="36" CurrencyCode="EUR" Description="Value Added Tax (VAT)">
        <TaxDescription>
        <Text>VAT</Text>
        </TaxDescription>
        </TaxGroup>
</TaxGroups>

REST  - 

"TaxGroups": {
    "TaxGroup": [{
        "Code": 36,
        "Description": "Value Added Tax (VAT)",
        "Amount": "50",
        "CurrencyCode": "AUD",
        "TaxDescription": {
             "Text": [
                 "VAT"
             ]
        }
    }]
}

SOAP - 

<FeeGroups>
       <FeeGroup Amount="10.00" Code="12" CurrencyCode="EUR" Description="Resort Fee">
       <FeeDescription>
       <Text>Resort Fee</Text>
       </FeeDescription>
       </FeeGroup>
</FeeGroups>

REST  - 

"FeeGroups": {
     "FeeGroup": [{
              "Code": 3,
              "Description": "City / Municipal Tax",
              "Amount": "39",
              "CurrencyCode": "AUD",
              "FeeDescription": {
                   "Text": [
                       "City tax"
                   ]
              }
          }

      ]
}

Notes:

  •  “GuestCount” attribute present in schema will be supported in future.
  • “MealPlanIndicator” will return false for room only and self-catering rate plans.

Additional Information

Room-rate Name and Description

Rate name and description are returned as-is from supplier responses. It is recommended that POS applications display this information prominently during shopping, price validation and booking processes to ensure travel agents and travelers have full clarity on what is being purchased.

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

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

SOAP - 

<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>

REST - 

"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."
     ]
}

Developers must use the CSL API reference data (link above) to match the Fee Tax Type description for the OTA code returned.

FAQs

  • What is product normalization?

    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.

  • How does it benefit my customers/business?

    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
  • Do I have to sign-up separately for product normalization?

    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.

  • What attributes are normalized?

    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)
  • Will more attributes be normalized in the future?

    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.

  • How does product normalization work?

    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.

  • Do all suppliers return rate details in an unstructured format requiring free text processing?

    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.

  • Which part of unstructured content from availability response is normalized?

    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>
  • Will Sabre process or use additional content for normalization purposes in the future?

    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.

  • How do I know which attributes are normalized and which are returned as-is from supplier responses?

    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.

  • Can there be a conflict between the normalized attribute and the room description?

    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.

  • What to do if I see conflicting or incorrect normalized information?

    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>
  • Is there a list of standard room type name definitions defined and supported by hoteliers?

    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.

  • What are some examples of non-standard room type names and how they are normalized?

    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.

  • How accurate is the normalized content?

    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.

  • Why do I see some properties return better-normalized content than others?

    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.

  • How can I use the normalized attributes in my point of sale application (POS)?

    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.
  • How do I know the list of all possible OTA codes for normalized product attributes?

    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.

  • Who determines relevant OTA codes for each value of a normalized attribute?

    The normalization algorithm and mapping logic are proprietary of Sabre.

  • Are all normalized codes OTA standard codes?

    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.

  • Which version of OTA standard is used?

    2017B version 1.

  • Are the codes provided in CSL API reference data final?

    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.