In the traditional world of airline distribution, caching refers to the method where fares are stored by the technical intermediaries (usually the Global Distribution System) and reused, for a defined amount of time, for subsequent search requests.
A Must-Have for Online Travel
Fare caching became an essential component of established distribution systems, as OTAs and flight search engines sought to provide the widest possible selection of fares across large date ranges, in a way that would limit the number of Availability requests to airlines and enable fast response time. The fact that fares are filed by airlines in industry databases (ATPCO) and disconnected from the actual checkout process made it easier for those systems to build fare caching solutions and deploy them at scale.
The Old Recipe No Longer Works
In the new and growing DirectConnect world, airlines are responsible for putting together Offers, i.e. the combination of schedule, availability and fare families information, not the technical intermediaries. When a traveler selects one of these offers, it becomes an Order which relies on the OfferID as a reference to the airline that will confirm the order.
Given the fact that these Offers are created by airlines in response to real-time search requests, it makes the known and proven fare caching method obsolete. Meanwhile, the requirement to find ways to minimize the number of Search requests sent to airlines remains since most airline API won’t cope with real-time search traffic generated by online travel players. Hence, the often restrictive look-to-book ratio currently imposed by airlines in relation to the use of their APIs.
First Step Into Search Results Caching
During the past couple of months, we have been looking at how we could meet that challenge, and started building into our Airline DirectConnect Platform the first iteration of a Search Results caching solution.
This first iteration relies on the following logic:
First, our platform records all search requests data originating from our connected channels (sellers) and all search results built from the Offers returned by the airlines, within the time limits associated with each offer; it would then reuses relevant search results for any subsequent search requests that meet the exact same search request data;
Under the same principle, our platform would also build search results by grouping and ordering passenger type-specific Offers returned by airlines from separate search requests originating from our connected channels. Let’s say our platform receives a search request for one Adult and two Children; it will look at the Offers for Adult and Child in previous and separate search results and build and return one new Search result using the stored data (again with the time limits associated with the stored Offers).
By being able to dynamically combine Offers from past search results, our platform will not only minimise greatly the impact of excessive search traffic to airlines; it has the potential to deliver new and unique search experience to sales channels and to travellers.
Interested in Learning More?
We are looking for sales channels to discuss and experiment our Search Results Caching solution; if you’re an Online Travel Agency or a flight metasearch engine and seek an efficient solution to meet your airline direct integration needs, please give us a shout at firstname.lastname@example.org