A recommender decides what gets shown first. It needs real interaction history to learn from. It also needs a sensible answer on day one for the visitor who has never clicked and the product that went live an hour ago.
In short: Recommenders rank a catalog per person using interaction history. Two things decide whether the project works: whether that history exists in usable form, and whether the system has an answer for new users and new items. Cold start is where most recommender projects quietly fail, so we design it before anything else.
What goes into the ranking
A recommendation is a sort order. Every item in the catalog gets a score for this person in this moment, and the top few appear on the page. Four kinds of signal feed that score, and a working system usually blends all four rather than betting on one.
Behavioral signals
Views, saves, adds to basket, purchases, watch time, returns. What people did, weighted by how much each action really tells you.
Item similarity
Attributes, descriptions, categories and co-occurrence. This is what keeps a brand new product rankable before anyone has touched it.
Context
Time of day, device, season, what is already in the basket. The same person wants different things on a Tuesday morning and a Friday night.
Business rules
Stock, margin, contractual placement, exclusions. Applied as a layer on top of the ranking, where a merchandiser can change them without retraining.
Cold start decides the project
Every recommender is excellent at the case it was demonstrated on: a long-standing customer with hundreds of events, and a popular product with thousands. Neither of those is the hard case. The hard case is the person who arrived ninety seconds ago and the item that was added to the catalog this morning. On day one, most of your traffic and a good share of your stock look exactly like that.
This is where recommender projects quietly fail. The model works, the offline numbers look fine, and then new arrivals sit invisible at the bottom of every list because nothing has interacted with them, so nothing can. They never accumulate the data they would need to rise. Meanwhile first-time visitors get a page assembled from nothing.
The answers are not exotic, but they have to be designed in rather than patched on. Attribute-based similarity so a new item inherits a position from things it resembles. A deliberate exploration slot so unproven items get shown enough to earn a signal. Sensible defaults driven by context and popularity for the anonymous visitor, replaced within a session as soon as they click anything. We build these first, then the personalized model, because the reverse order leaves gaps that only show up in production.
Clicks are not the only thing you want
Optimize purely for click-through and you get a system that keeps showing the same handful of proven winners. It works, briefly. The loop tightens: shown more, clicked more, learned from more, shown more still. The rest of the catalog starves for lack of exposure, and customers stop encountering anything they did not already know about.
Most businesses want the opposite of that. They want people finding the second and third thing, the range they invested in, the item with better margin than the bestseller. So we agree a discovery measure at the start — catalog coverage, how many distinct items get surfaced, how deep into the range a typical session reaches — and report it beside engagement every week. What gets measured is what survives the next round of tuning.
Measuring it without fooling yourself
Offline scoring on held-out history is how we compare approaches cheaply, and it comes with a baseline: a plain list of the most popular items. That list is stronger than people expect. A personalized system that cannot beat it is not earning the infrastructure it runs on, and we would rather find that out in week two than after launch.
Real proof is a live test against the ranking you have now, run long enough to survive a weekend and a payday. That needs event tracking you can trust, which is often the first piece of work: sorting out what gets recorded and where it lands through your data integration layer. Once it is live, behavior keeps moving, so ranking quality gets watched continuously rather than checked at launch and forgotten.
What we won’t do
We won’t build a recommender without interaction history
With no record of what people actually did, there is nothing to learn from. Where the history is thin, the honest first step is fixing the tracking and running a rule-based ranking in the meantime.
We won’t optimize for clicks alone
A click-maximizing ranker narrows what your customers ever see, and the damage takes months to become visible. A discovery measure gets agreed up front and reported beside the engagement numbers.
We won’t leave cold start until after launch
How a brand new visitor and a brand new product get ranked is designed in the first week. Patching it once the empty slots appear in production costs more and works less well.
What does your catalog show a first-time visitor?
Tell us what interaction data you record and how often new items arrive. We will start with the cold-start answer, because that is what decides whether the rest is worth building.
Enough that most items have been touched by more than a handful of people and most active users have more than a few events. Very sparse data produces confident nonsense that looks fine in a demo. We check the density of your event data before proposing an approach, and sometimes the first project is fixing what gets recorded.
What happens with a brand new product?
It gets ranked on its attributes and its similarity to existing items until real interactions accumulate, usually with a deliberate exploration slot so it is seen at all. Without that, new stock stays invisible and never earns the data it would need to rise. This is designed before the personalized model, not after.
How do you stop it showing the same few things?
By measuring catalog coverage and item diversity alongside click rate, and by reserving part of each result set for exploration. A ranker tuned only on engagement narrows the catalog over months, so the discovery metric goes into the weekly report from the first week and stays there.
Can we override what the model recommends?
Yes, and you should be able to. Stock levels, margin, contractual placement and exclusions belong in a rules layer sitting on top of the model, where a merchandiser can change them the same day. Baking commercial rules into the model itself means every change becomes a retraining cycle.
