Using Anomaly Detection as a smarter way to spot those inventory issues that leak revenue opportunities

The importance of keeping an eye on your performance

If all the hard work of setting up the booking platform, optimising its performance, and forging distribution contracts with clients is going to pay dividends, then it's vital to have a good supply of products and services (such as room types and locations) to be able to respond with when the hard won search traffic hits the API. We have a 4 pillars model that reflects the key drivers of conversion which all need to be covered - it doesn't work if any one of the areas of performance, price, relevance or availability is not up to scratch at the right moment.

Anomaly Detection is designed 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 'collective' searches and the second is responding to 'individual' or 'list' based product searches. In hotel distribution, 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 but relevant alternatives in those cases where inventory lacks 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?

Anomaly Detection can also be applied from a 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.

The full white paper: "Anomaly Detection in Search and Booking Data" is available here.
An adaptation of this article was first published as a Blog on the Triometric website.

Information Technology Revenue Management Innovation Big Data