SaaS & technology
Real-time recommendations for anonymous sessions
Two-stage recommenders that personalise from the current session alone — the case that matters, because most traffic is not logged in.
This page describes a problem class and the architecture we deploy for it, written against a named public benchmark — the open dataset or competition where the world's data scientists have tested approaches to this exact problem against a hard metric. It is not a client engagement, and the benchmark's results, prizes and rankings belong to its host and participants, not to us. Client work is confidential and is only ever published with written permission.
The problem
What it costs when this goes unsolved.
Most e-commerce and content traffic is anonymous, so recommenders built on customer histories personalise for the minority who least need it. The revenue case is the first-time visitor: inferring intent from a handful of in-session actions, fast enough to change what the next page shows, across a catalogue too large to score exhaustively.
Session data is an event stream — clicks, cart-adds, orders — at a scale where the engineering is half the problem: the reference benchmark for this class runs to twelve million sessions and 220 million events. The objectives conflict (clicks are plentiful, orders are what pay), and offline metrics reward popularity bias unless candidate generation is evaluated separately from ranking.
How we build it
The architecture, stage by stage.
01
Two stages: retrieve cheaply, rank expensively
Co-visitation structures and embedding similarity produce a few hundred candidates in milliseconds; a learned ranker then spends its compute only on those — the architecture every production recommender converges on.
02
Multi-objective ranking
Click, cart and order likelihoods modelled jointly with weights set by their economics, not by whichever metric is easiest.
03
Session encoders where they pay
Sequence models over the live session capture intent shift mid-visit — added where measured lift justifies the latency, not by default.
04
GPU data engineering
Event streams at this scale are made tractable with GPU dataframe pipelines, keeping experiment cycles in hours rather than weeks.
Model families on this problem class: Candidate generation + re-rank · GBDT rankers · Session transformers / GRUs · RAPIDS GPU pipelines.
What you get
What an engagement hands over.
Everything below goes in the scope document before you sign it, with a fixed price or a rate with a ceiling — the same terms as every other engagement in the catalogue.
- A candidate-generation and re-ranking service behind your existing API
- Latency budget met and documented — recommendations that arrive after the page has rendered are decoration
- An offline evaluation harness that separates retrieval quality from ranking quality
- An A/B design measuring revenue per session, the number that matters
Provenance
The benchmark behind this page.
OTTO Multi-Objective Recommender System, run by OTTO, is the public proving ground for this problem class. The figures below are the host's, cited as context for how seriously this problem is tested in the open — they are not our results and we do not claim them.
How to buy this
The services this build draws on.
More proof
Next step
Thirty minutes on whether this fits your problem.
Bring the constraint — the regulator, the data boundary, the latency budget. If your data cannot support this build yet, the call will conclude with what to fix first, not with a proposal.