CASE STUDY
retrieval latency
Booking-optimized discovery engine with sub-50ms search
retrieval latency
prediction heads
embedding search
A booking-optimised discovery engine with sub-50ms semantic search, ranking properties against completed bookings rather than clicks — because a ranking change that lifts click-through and raises cancellations has made the business worse.
A discovery product needed ranking that optimized actual bookings — not clicks — and search that understood “date night in Glasgow”, not just keywords.
We built a GRU-based event encoder with task-conditioned gating across 9 prediction heads, with loss weighting prioritizing booking (3.0–4.0) and verified attendance (5.0).
Semantic search runs on BGE embeddings through a real-time vector store at sub-50ms retrieval, while QR-verified attendance captures earn a trust multiplier — a ranking signal competitors cannot copy.
The full MLOps loop — offline training assembly, managed training and registry, quantized inference — ships as one production system.
What made this hard
Availability changes constantly
A recommendation computed an hour ago may be for something already booked. Availability had to be a ranking input rather than a filter applied too late.
Clicks are the wrong objective
The easiest metric to move and the least connected to revenue. Optimising it reliably produces more browsing and no more bookings.
Cold start is most of the catalogue
New listings have no behavioural history, and a system that cannot rank them suppresses new supply — which is the opposite of what a marketplace needs.
Latency is a conversion feature
Search that takes a second loses people before the results matter, so sub-50ms retrieval was a requirement rather than an optimisation.
How we built it
Objective first
Ranking defined against completed bookings, with browsing metrics kept as guardrails rather than targets.
Vector retrieval
Semantic search returning candidates in under 50ms at production volume.
Ranking with explicit rules
Business logic — availability, position, commercial arrangements — applied visibly rather than smuggled into the model.
Cold-start handling
Content and attribute signals carrying new listings until behavioural data accumulates.
The stack
What should you take from this?
- The objective is a commercial decision, not a technical one, and getting it wrong means better modelling accelerates the damage.
- Availability belongs in ranking, not in a post-filter. Recommending something unavailable converts nothing and costs trust.
- Below a few thousand items and users, good heuristics compete well with a learned system and cost far less to operate.
Frequently asked questions
Why rank on bookings rather than clicks?
Because clicks are the easiest metric to move and the least connected to revenue. A model that lifts click-through while raising cancellations has made the business worse, and the reporting will not show it.
How do you handle new listings?
Content and attribute signals rank them until behavioural data exists. Without that, a system quietly suppresses new supply — which for a marketplace is the wrong failure to have.
How fast does search need to be?
Fast enough that nobody notices it. Sub-50ms retrieval was the requirement here, because latency in discovery is a conversion problem rather than a technical nicety.
Related service: AI Recommendation & Search Engines
Build something at this level
Tell us what you are building. We reply within one business day.