The problem
Search in e-commerce is a solved problem if you only care about keyword matching. Plug in Elasticsearch or Algolia and you get fast, scalable retrieval that knows how to handle typos, plurals, and stemming. What those tools do not do is rank results by what this specific user is likely to buy.
The persona-conditioned ranking is the differentiator that matters for conversion. A search for "milk" from a lactose-intolerant customer should return lactose-free milk first. A search for "shampoo" from a parent should return family-size bottles. A search for "router" in a small-office segment should return SMB-grade hardware, not consumer wifi. The data has the answer — purchase history, browse history, segment membership — but most search stacks do not have a clean way to use it.
Smart Search adds the conditional ranking layer on top of the keyword match. The retrieval is still fast and scalable; the ordering of the results is conditioned on what the system has learned about this user.
How it works
In the demo's Shop, _search over the product names, ordered by $similarity, picks the products the words name. _recommend then ranks those products for this shopper with the context the Shop's grid uses: declared pets, the month, the cart and the shopper's own history, with the goal set to a purchase. The order is the purchase probability times the text match. Evidence › Personalised search scores this ranking against BM25 on held-out search sessions.
The re-ranking signal is not a curated rule. It is the same conditional probability that drives prediction elsewhere — P(purchase | shopper context, product), learned from impressions and purchases. A shopper with no orders is still ranked by the household and the month.
{
"from": "impressions",
"where": {
"context.customer.pets": {
"$and": [
{
"$match": "small_animal"
}
]
},
"context.month": "2026-04",
"context.customer": "CUST-00922",
"just_bought": false,
"product_sku": {
"$or": [
"SKU-PT-0242",
"SKU-PT-0195",
"SKU-PT-0196",
"SKU-PT-0243",
"SKU-PT-0199"
]
}
},
"recommend": "product_sku",
"goal": {
"purchased": true
},
"select": [
"sku",
"$p"
],
"limit": 24
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
Frequently asked
How does this compare to Algolia + a separate personalization layer?
Algolia and similar tools do the retrieval brilliantly; the personalization is usually added with a separate ranking model that the team has to train and maintain. Smart Search collapses retrieval and personalization into one pair of queries — no separate model, no separate pipeline. On raw text-matching, Algolia is often faster; the gain is that the personalised ranking needs no pipeline of its own.
What about new visitors with no history?
A shopper with no orders is still ranked by what the shop knows: the declared pets and the month. The demo's held-out search check slices the sessions by the shopper's prior orders, including those with none, so the cold-start case is measured rather than assumed.
How quickly does the re-ranking adapt to new patterns?
Every impression and click enters the index immediately; the next query reflects it. No retraining schedule, no batch update. Seasonal patterns, trend shifts, new product launches — all visible in the ranking within seconds of the supporting data being recorded.
Can we control the balance between text-match relevance and personalization?
Yes. A pure keyword query returns text-match order; a pure recommend query returns user-conditional order without text constraints. The demo multiplies the purchase probability by the text lift, with the weight of the text match (theta) as a setting. The balance between keyword match and personalization is a setting to tune on your own click data, not a fixed ratio.
Does this work for catalog search inside enterprise SaaS (not just e-commerce)?
Yes. The pattern is "retrieve text matches, re-rank by user-conditional probability." It applies anywhere a user searches a catalog — knowledge bases, ticket systems, document repositories, partner directories. The retrieval is the same; the conditional ranking differs by what "preferred result" means in each domain.
