This is the third article in a 3-part series discussing how anomaly detection capability as part of an API analytics platform can help travel distributor and supplier organisations detect when and how their APIs leak revenue or miss opportunities.
NB: This is an article from Triometric
This third article looks at using Anomaly Detection as a smarter way to alerting on potential revenue leakages due to poor product inventory, shortfalls in capacity and other causes of low availability.
The importance of keeping an eye on your performance
“You have to be in it to win it” is a great way of characterising this challenge. If all the hard work of setting up the platform, optimising its performance, forging distribution contracts with clients is going to pay off then it’s vital to have a good supply of products and services to be able to respond with when the hard won search traffic hits the API. Triometric often refers to its 4 pillars model because it reflects the key drivers of conversion which all need to be covered – it doesn’t work if you come up short in any of areas.
The idea of Anomaly Detection is to track the normal variation and flag the unexpected events. So in the world of availability tracking, what could possibly go wrong? Whilst this article isn’t about the mechanics of tracking searches, there are two specific categories that tend to be tracked and their importance will vary depending on how the API is configured or where your organisation is in the supply chain. The first category is responding to what can be described as collective searches and the second as individual or list based product searches. In the hospitality sector, these categories would correspond to city and specific property searches. In flight, it would be route or carrier specific searches.
With individual searches, the API can respond with either an offer of a product, so zero or more rooms in the simplest case, and typically I would be interested in the percentage of responses that have and don’t have offers e.g. %Availability or %No Availability. If the booking platform is more sophisticated then I can take the Amazon shopping approach of “other customers looked at….” and offer similar alternates when I lack availability of the requested item.
With collective searches, the API can respond with a list of offers based on the collective criteria, for example a set of hotel rooms for Paris. On some occasions, this may be “no rates available” type list which the API may flag as an error rather than send back an empty list, or it may contain a reasonable number of room offers. The question is then what constitutes reasonable and does that vary over time?
For example, an API platform might normally offer 200 rooms in Paris but when this drops down to 50, this translates into a more limited choice for prospective travellers. At the same time 50 room offers might be amazing to travellers for Tierra del Fuego. It could be that a major event in Paris means many rooms are sold out so the 50 rooms offer could be viewed as reasonable given that context. Understanding what constitutes reasonable for which destinations at any given time is the challenge and solving it means that we can view drops in room counts as predictive.
In these scenarios, hard and fast rules, even per destination, would likely produce a lot of false positives alerts. The alerting system needs to appreciate that there may be new even temporary levels that constitute a new normal.
All of these individual and collective searches are examples of product centric tracking. In other words Anomaly Detection being deployed to adjust to what constitutes a “normal value” and react to any changes from that normal which is established for a destination or individual property but also combined with the dates of stay.
Detecting the availability anomalies in search responses is only the start of the fix process which demands significant additional detail to diagnose the issue. I would expect to bring in supporting data that might include:
- Mapping errors where product has been wrongly listed on the API platform
- Inventory pricing buckets not yet ready for allocation
- Poor or incorrect availability allocations by channel
- Supply issue with contracted third parties
- Inventory exhausted – sold out – good news?
The second article in this series considered Anomaly Detection with regard to Client Management examples, so largely from the client behaviour and traffic viewpoint including areas such as Look-to-book, booking counts and booking rates. It equally makes a lot of sense to consider using Anomaly Detection for Availability being offered to clients too.
In this case, the Anomaly Detection is used to track the %Availability levels being offered in search responses to the traffic being driven by individual clients. Tracking this will identify significant changes in availability and deliver intelligence on when clients search patterns are diverging from what you have on offer or their contractual commitment, say specific destinations. In this case the underlying causes could be due to the Client:
- Exceeding allocated availability
- Searching for products not being offered
- Has mapping data issues of their own
Depending on role in the supply chain, the remedial actions in most of the above cases revolve around simply fixing a mapping problem, talking to the client or liaising with a supplier to allocate more inventory. In short, the fixes are often very actionable, which is the key to driving a return on any investment in analytics.
As a final comment, exhausting availability isn’t necessarily good news if the underlying cause is a pricing error. Two recent examples of unwelcome anomalies are those of British Airways and Cathay Pacific, who found have both themselves selling normally expensive tickets at erroneous bargain basement prices.
