Business Problem & Solution

A catalog of a thousand-plus properties is useless if every guest sees the same generic grid. The job is to put the handful of stays a particular guest is most likely to want at the top of a short rail — on the home page, in results, and beside a property they're viewing — and to do it for a brand-new guest with no history as well as for a returning one. Get it right and browsing converts; get it wrong (or show one city's stays over and over) and the guest bounces.

The Hotel Recommendation Engine fills those rails. It ranks the catalog from the guest's own behaviour and profile, explains why each stay made the cut, and diversifies the result so no single region dominates.

It proves an explainable, behaviour-aware ranker that degrades gracefully: real browsing signals (views, saves, bookings) reorder the rail; with no signals it falls back to rating + popularity so a fresh guest still gets a full, reasoned rail; and a ≤2-per-region cap keeps the top 6 diverse. Every card carries a human-readable reason ("More in Goa, where you've been looking", "Highly rated by guests", "Matches your interest in spa").

It simplifies the model: the ranking is a transparent deterministic blend, not a learned model, and it runs at $0 in both modes. The single place a model is even optional is the natural-language "why these are picked" explanation — and that explanation is never required to render the rail.

Synthetic catalog + synthetic behaviour only — invented properties, generated facilities/ratings/popularity, and a behaviour log built from the demo session. No real brands, customers or PII. Ranking weights and any figures shown are representative and owner-tunable.