Learn how to format the conversation ID to track shop-to-book conversions.
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
<eb:MessageHeader SOAP-ENV:mustUnderstand="1 eb:version="2.0">
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/12/utility">`
<wsse:BinarySecurityToken valueType="String" EncodingType="wsse:Base64Binary">Shared/IDL:IceSess\/SessMgr:1\.0.IDL/….</wsse:BinarySecurityToken>`
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.
Format of the field
ConversationId attribute is used to pass
RefToTrxId values, where
SessionIdis unique for a logical end user session.
TrxIdis unique for each transaction.
RefToTrxIdis not used in Shopping transactions, but in Booking transaction to designate the Shopping transaction that returned the itinerary we are trying to book.
SessionIdis not associated in anyway with the technical Sabre Web Services session.
The format of the
Version+”@”+SessionId+”@”+TrxId+”@”+ RefToTrxId - where all the components are optional.
Version is to be set to
TrxId are generated by agency, and
TrxId should be unique across all agency requests, not just within the session.
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.
Traveler A shops on OTA; OTA sends two BFM requests to Sabre.
ShoppingReq2(SessionId =1, TrxId=2)
Itin1: we need to send
Itin4: we need to send
Itin2: we can send
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.
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)
These three itineraries are stored into the cache.
Traveler A stops shopping on OTA; Traveler B starts its session:
ShoppingReq2(SessionId =B, TrxId=2)
Then he executes the shop that returns
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.
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
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)