A guide for merchandisers: what personalized sorting does, how it decides what to move
up, and how to switch it on.
What it does
Two shoppers search for "dress" on your site. One has spent the last ten minutes looking
at navy dresses; the other has been browsing red. Today they both see the same list in
the same order.
With personalized sorting on, they see the same products — but the navy shopper sees
navy dresses nearer the top, and the red shopper sees red ones. Nobody's results are
filtered, hidden, or added to. The list is simply ordered to reflect what each shopper
has shown interest in.
You decide which product attributes count (colour, brand, material, and so on) and how
strongly each one pulls. Everything else is automatic.
How it works
1. We watch what shoppers engage with
Three kinds of activity feed personalization:
| Action | How much it counts |
|---|---|
| Viewing a product | Baseline |
| Adding to cart | Roughly twice a view |
| Purchasing | Roughly three times a view |
Only the shopper's most recent activity is considered — up to 30 actions by default,
across all three types together. More recent actions carry more weight than older ones,
so a shopper who spent last week on coats and today on boots is treated as a boots
shopper.
Because it's a single rolling window, old behaviour ages out naturally. A purchase from
months ago doesn't keep steering results forever while the shopper's tastes move on.
2. We work out what they like
For each attribute you've made eligible, we look at the products behind those actions and
tally up which values keep coming back. A shopper who viewed five navy items and one
black one has a strong navy preference and a weak black one.
Preferences are scored relative to the shopper's own strongest signal, so the scale means
the same thing for a casual browser and a heavy shopper.
Confidence matters. A single product view is not evidence of a preference, and it
isn't treated as one. It takes roughly ten views of the same value (or four add-to-carts,
or three purchases) before that value earns the full boost. Below that, the boost is
scaled down in proportion to the evidence behind it.
3. We nudge matching products up
Products matching the shopper's preferred values get a boost in the ranking, sized by the
strength you set for that attribute.
The important part: the boost amplifies relevance, it doesn't override it. A product
that barely matches the search can't jump ahead of a strong match just because it's the
right colour. What you'll see is reordering within groups of similarly relevant
products — which is exactly where a shopper's preference should be the tiebreaker.
What it does not do
- It doesn't filter anything. Every shopper sees the same products and the same
number of results. - It doesn't change your filters or facet counts. "Colour: Navy (24)" reads 24 for
everyone. - It doesn't override merchandising. Pinned products stay pinned. Boost and bury
rules still apply, and personalization simply adds alongside them. - It doesn't affect first-time shoppers. Someone with no history on your site gets
exactly today's ordering. Personalization is a bonus for returning shoppers, never a
penalty for new ones.
Where it applies
| Surface | Personalized? |
|---|---|
| Keyword search results | ✅ |
| Category and browse pages | ✅ |
| Facet and filter counts | ❌ |
One more condition: personalization applies when the engine ranks using its sorting
recipe. If an engine is set to sort by something else instead — bestsellers,
most-viewed, or a merchandising rule — that sort takes over the ordering and
personalization doesn't apply there. Those sorts are alternatives to recipe-based
ranking, not layers on top of it.
Category and browse pages are where the effect is most visible. Search results are
already ranked by how well each product matches the query, which leaves less room to
move; on a browse page, everything is equally relevant and preference does more work.
Setting it up
Three pieces, all configured in the platform. No release or code change is needed, and
changes take effect within a few minutes.
Step 1 — Choose which attributes can be personalized
Pick up to five product attributes that personalization is allowed to use. This is
the guardrail: nothing outside this list can ever be used to reorder results, no matter
how a sorting recipe is configured later.
.png)
Choosing well matters more than choosing many. A good attribute is one where:
- shoppers genuinely have preferences (colour, brand, material, fit, style);
- values repeat across many products, so a preference can be learned from a few actions;
- the value means the same thing catalogue-wide.
Attributes to avoid:
- anything close to unique per product (product name, SKU, exact price) — a shopper can
never build up enough evidence for it to matter; - anything nearly everyone shares (a season tag applied to the whole catalogue) — it
boosts everything equally, which is the same as boosting nothing; - attributes stored as lists rather than a single value (a product tagged both "navy" and
"blue"), which are skipped.
Starting with two or three strong attributes beats filling all five.
Step 2 — Turn personalization on for a sorting recipe
Switch affinity boosting on for the sorting recipe you want to personalize, then set how
hard each attribute pulls. Each attribute gets a strength from 0 to 20, where 20 is
the strongest.
.png)
Guidance on strength:
| Strength | Effect |
|---|---|
| 5 | Subtle. Breaks ties between closely matched products |
| 10–12 | Noticeable. A clear preference moves products up a row or two |
| 20 | Strong. The shopper's preferred values lead wherever relevance allows |
Only attributes from Step 1 can be used here. If you try to personalize by something that
isn't on that list, the recipe won't save — it tells you which attribute is the problem.
A practical approach: start at 20 on a single attribute so you can see clearly what
personalization is doing, then dial back to something you're happy shipping. Turning it
off later never loses your tuning; the settings stay on the recipe.
Step 3 — Attach the sorting recipe to your engine
Set the engine's sort to use your sorting recipe, and make sure the engine is attached to
the deployment serving the storefront.
.png)
.png)
The chain has to be complete end to end:
deployment → engine → sorting recipe → personalization on
If any link is missing, search keeps working normally — shoppers just won't see
personalized ordering. It fails quietly rather than breaking the storefront.
Tuning it
You have four knobs. In rough order of how often you'll reach for them:
Strength per attribute (0–20). The main dial. How hard a matched value pulls.
Which attributes are eligible. Adding a fourth attribute usually does less than
raising the strength on the one shoppers actually care about.
How much history to use (up to 30 recent actions). A shorter window makes
personalization react faster to a change in what a shopper is browsing, but makes it
jumpier. A longer window is steadier and slower to turn.
How much evidence earns full strength (about ten views of the same value by default).
Lower it if you want personalization to kick in sooner for casual browsers; raise it if
you'd rather wait for a clearer signal.
One thing that catches people out: the relative weighting of views, add-to-carts and
purchases only matters as a ratio. Scaling all three down doesn't make personalization
gentler — it changes nothing at all. If you want a softer effect, lower the strength in
Step 2.
Frequently asked questions
Will shoppers see fewer products?
No. The result set is identical for every shopper. Only the order changes.
What about a shopper who's never visited before?
They see standard ordering. Personalization needs recent activity to work from, and with
none it stays out of the way.
How quickly does it respond to a shopper's behaviour?
Immediately. The next search after a shopper views a product already reflects it.
How far back does it look?
It counts actions rather than days: the shopper's most recent 30 or so, newest weighted
most. For an active shopper that might be a single session; for an occasional one it can
stretch back weeks. Stored activity is kept for about a month.
Does it work across devices?
It follows however your storefront identifies the shopper using the user_id. Where that identity carries
across devices — a signed-in account, for instance — so does personalization. Where it
doesn't, each browser is personalized on its own.
Does it interfere with promotions or merchandising rules?
No. Pinned products stay pinned, and boost and bury rules keep applying — personalization
adds alongside them, inside the room they leave. Where an engine sorts by bestsellers,
most-viewed, or a merchandising rule instead of its sorting recipe, that sort decides the
order and personalization stands aside.
Can a shopper get stuck in a bubble?
Two things prevent it. Preferences are always capped relative to relevance, so
personalization can't push an unrelated product to the top; and old activity ages out of
the window as the shopper keeps browsing.
Could a shopper ever see a product repeat across pages?
Rarely, and only if they act on products mid-session: each page is ranked when it's
requested, so if a shopper opens a product and then clicks through to page 2, their
preferences have moved slightly and the ranking moves with them. Browsing without acting
doesn't cause it.
Can I try it on part of the site first?
Yes. Personalization is configured per sorting recipe, so you can enable it for one
engine or one deployment and compare against the rest.
How do I turn it off?
Switch it off on the sorting recipe. Ordering returns to standard immediately, and your
configured attributes and strengths are kept for whenever you want it back.
Glossary
| Term | Meaning |
|---|---|
| Attribute | A product field such as colour, brand, or material |
| Sorting recipe | The reusable set of ranking rules an engine applies |
| Engine | The search configuration behind a storefront experience |
| Deployment | What connects an engine to a live storefront |
| Affinity | A shopper's measured preference for a particular attribute value |
| Boost strength | How hard a matched attribute value pulls a product up, 0–20 |