Conversation IDs

Learn how to format the conversation ID to track shop-to-book conversions.

Introduction

A conversation ID allows you to identify the number of shops that result in a booking. If you specify this conversation ID throughout your workflow, we can match shop-to-book conversions.

We recommend you create an in-house programming logic to create a unique conversation ID using the following best practices.

Best practices in SOAP APIs

ConversationId is a field in the SOAP header that is meant to tie together the messages within the context of the same “conversation” – a logical user session.

Here is an example of a message header with the field ConversationId.

Until now, Sabre was not enforcing nor using ConversationId value in any special way, leaving the decision on using the field to the to API users.

As an attempt to standardize and improve the internal analytical capabilities, Sabre is proposing a particular design pattern for the usage of ConversationId - it is a part of a SOAP header and should be sent together with all the Sabre Web Services requests within a customer session (Shopping, Booking, Pricing, Reservation Management, etc.).

The remaining part of the document contains usage suggestions that need to be implemented on the API consumer part.

Typical usage scenarios

In a typical interaction, end customer opens an agency Web page and is assigned a Web application session. Within that Web application session, he/she makes multiple Shopping requests followed by Booking request of one of the returned itineraries. Within the same session, there might be subsequent Sabre Web Services requests (e.g. AddRemarks or AddPsgDetails).

Format of the field

ConversationId attribute is used to pass SessionId, TrxId and RefToTrxId values, where

• SessionId is unique for a logical end user session.
• TrxId is unique for each transaction.
• RefToTrxId is not used in Shopping transactions, but in Booking transaction to designate the Shopping transaction that returned the itinerary we are trying to book.

SessionId is not associated in anyway with the technical Sabre Web Services session.

The format of the ConversationId is Version+”@”+SessionId+”@”+TrxId+”@”+ RefToTrxId - where all the components are optional. Version is to be set to V1 currently. SessionId and TrxId are generated by agency, and TrxId should be unique across all agency requests, not just within the session.

Examples:

V1@280b16ec-5eac-46c0-893f-c88f8e8cb632@310b16ec-5dad-46c0-893f-c88f8e8cb643@ V1@280b16ec-5eac-46c0-893f-c88f8e8cb632@310b16ec-5dad-46c0-893f-c88f8e8cb643@780b16ec-5eac-46c0-893f-c88f8e8cb699

Additional considerations

Multiple shopping requests for single customer shop

When an OTA sends multiple BargainFinderMax (BFM) requests triggered by single-end traveler requests, and if those requests return overlapping itineraries, the subsequent booking request might use any of the TrxId for booking the itinerary that is shared between the responses.

Scenario:

Traveler A shops on OTA; OTA sends two BFM requests to Sabre.

ShoppingReq1(SessionId=1, TrxId=1)

Returns: Itin1, Itin2, Itin3

ShoppingReq2(SessionId =1, TrxId=2)

Returns: Itin2, Itin4

To book

• Itin1: we need to send BookingReq(SessionId =1,TrxId=3,RefToTrxId=1)
• Itin4: we need to send BookingReq(SessionId =1,TrxId=3,RefToTrxId=2)
• Itin2: we can send BookingReq(SessionId =1,TrxId=3,RefToTrxId=2) or BookingReq(SessionId =1,TrxId=3,RefToTrxId=1)

Caching on agency side

Within OTA cache, there is a need to store the TrxId of the shopping request that populated the cache and use it on the subsequent Booking transaction.

Scenario:

Traveler A charges the cache with his Shopping transaction. The cached results are later used by Traveler B to perform the booking.

Traveler A shops:

ShoppingReq1(SessionId =A, TrxId=1)

Returns: Itin1, Itin2, Itin3

These three itineraries are stored into the cache.

Traveler A stops shopping on OTA; Traveler B starts its session:

ShoppingReq2(SessionId =B, TrxId=2)

Returns: Itin4, Itin5, Itin6

Then he executes the shop that returns Itin1, Itin2, and Itin3 from the OTA cache.

When Traveler B wants to book

• Itin1: we need to send BookingReq1(SessionId =B, TrxId=3,RefToTrxId=1)
• Itin4: we need to send BookingReq2(SessionId =B, TrxId=4,RefToTrxId=2)

Usage of Sabre Shopping Cache is not impacting the way ConversationId is to be used – the customer using Sabre Cache should treat such requests as a standard BFM request in this context.

Working with Meta search sites

If OTA is able to associate redirected customers with initial meta search, it will be beneficial to use the same SessionId on both Meta initiated request and the request that are sent after the redirect. If such an association is not possible, keeping separate SessionIds or not using SessionId on Meta requests is acceptable.

The following diagram assumes meta requests cannot be identified as belonging to the same traveler session. The alternative situation will allow OTA to combine XYZ and ABC sessions into one.

Long running customer sessions

For OTA WebApp session spanning longer periods (e.g. days), there is no need to maintain the same SessionId on Shopping transactions across multiple days.

Blind sells

For blind sells, we might or might not have a SessionId; but we will not have RefToTrxId, so the Booking transaction will be executed with an empty RefToTrxId attribute.

Benefits

Enhancing OTA’s end-to-end flow by adding ConversationId will benefit both customers and Sabre.

The key benefit for customers includes improvement in conversion management by

• Intelligent airline polling control
• Support in customer A/B testing capabilities
• Analyzing conversion parameters per product/service
• Shopping Cache fine tuning
• Accurate failure rate management (identifying blind sells/cache issues)