curatedProducts · personalized by contextSKUs — past-clicked ids ride along, no stored profile
Curated Products.
The feed, re-ranked for the shopper in front of it.
Open one product and a small product feed comes back — a mini listing that mixes the category the shopper opened with the categories that go with it. Open the T-shirt below: it returns tees and the jeans, jackets, shoes, bags and belts that complete them. What re-orders that feed between two shoppers is contextSKUs — the handful of product ids this browser has been opening. No login, no tracking script, no stored profile. It is the same mechanic behind every curated surface.
What it returns is a product feed, not a worn look — the on-model looks live on Curated Inspiration.
One product opens → a mixed mini-PLP comes back.
A shopper opens a single T-shirt. curatedProducts returns a small product listing built around it — more tees, and the jeans, jackets, shoes, bags and belts the engine reads as going with it. Not one suggestion, not a worn photo: a genuine mixed product feed, in the engine’s own order.
opened
This one tee returns a 24-product feed, mixed across 6 categories. More tees lead; the pieces that complete them follow, in the engine’s own order.
This is curatedProducts’ own feed for this T-shirt. The products, the categories and the order are exact result rows from the recommendation tables (feature_database 9464, store 78). It is reconstructed offline over our demo catalog, never a live call; the relative order is the engine’s, the absolute scores illustrative. Every piece is a real catalog packshot.
bunsarcurated productsthe engine’s own feed · 6 categoriesreconstructed offline — not a live call
Same product. One shopper clicked denim first.
Two shoppers open the same T-shirt. The only thing that differs is contextSKUs — the pieces each browser had been opening. Shopper B had clicked three pairs of jeans first, so the denim-carrying looks score higher and their pieces surface earlier. Same feed, one query parameter, a different order.
Classic High-Rise Straight Leg Jeans
Ripped Flare Mid-Rise Jeans
High-Rise Wide-Leg Jeanssame call, same product — only this differscontextSKUs = 584443613 · 584443778 · 584443688
The 24-card feed above is Shopper A’s — no context, the catalog’s own order. Held against Shopper B’s, card for card:
Cards 1–18 are identical in both feeds — same products, same positions. They are drawn small here because none of them moved; each one is full size in the feed above.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
the two feeds separate at card 19
drops out of the visible 24
drops out of the visible 24
drops out of the visible 24
↓ moves to 19
↓ moves to 20
↓ moves to 21
↑ up from 22
↑ up from 23
↑ up from 24
new to this feed
new to this feed
new to this feed
- 18cards hold their exact position
- 3climb into view, from 22, 23 and 24
- 3enter that Shopper A never sees
- 3fall out of the visible 24
This T-shirt’s own lead look already carries jeans, so the denim clicks mostly confirm what was already at the top — the visible movement sits further down. Within the 24 you can see, 3 products enter (marked new) and 3 climb (marked up from): the pieces of a denim-carrying look the clicks lifted. Three others drop out of view. Go out to the engine’s default depth of 50 and it widens — 7 products enter, more jeans among them, and 25 positions change. Underneath, denim re-ranks the 357 candidate looks; over the top-20, 11 change rank — then the flatten reshuffles the feed you scroll.
bunsarcontextSKUs · one query parameterthe engine’s own re-rankreconstructed offline — not a live call
No profile to defend
Personalization with nothing to collect, store, or defend.
The shopper’s context is the list of product ids open in their own browser, handed back on the next call and used for that one answer. There is no shopper profile in our data model — so there is no CDP to integrate, no consent surface to maintain, and no tracking script on the page.
- Deletes a CDP dependency — nothing to sync, nothing to reconcile
- Deletes a consent surface — no cross-site identifier to disclose
- Deletes a tracking script — the list lives in the shopper’s browser
- No shopper profile in the data model — a breach of one cannot happen
a piece from the feed — real catalog producta piece from the feed — real catalog productFirst visit = hundredth visit
No cold start. A first-time shopper gets a full feed on the spot.
Recommenders that lean on a history need a warm-up window — the first session is the worst one they ever give. Here, a brand-new shopper gets exactly the same mixed feed as a returning one, because neither has a file. The one product they just opened is enough to build the whole listing.
- No warm-up window — the opened product is the input
- Someone on their first visit and someone on their hundredth are read the same way
- Nothing to back-fill, nothing to migrate when a catalog changes
- Works from the very first product the shopper opens
Here, then gone
The context is only what the shopper has open right now.
contextSKUs is the small set of products the shopper has opened this visit — not a dossier assembled over months. It steers the feed while they are on it and is forgotten when they leave. The listing re-orders around what the session touches; everything it doesn’t keeps your catalog’s own order.
- The context is a handful of live product ids, not a lifetime record
- It moves only what the session actually touches
- Untouched pieces keep the order you would ship without us
- Nothing to age out, nothing to expire
a piece from the feed — real catalog productHow it works
One list. One formula. The whole feed re-ordered.
- The browser keeps the list. contextSKUs is the list of product ids this shopper has opened, and it comes back to us on the next call. No id we issue, no record we hold.
- The engine scores every look against it. A look scores by how many of the products the shopper has been opening it carries — either the product itself, or a close match to it from the engine’s own similar products. The looks then flatten into a single product feed with no repeats.
- The same list is sent to all three surfaces. One contextSKUs list goes to the outfit shelf, the inspiration looks and the product feed alike — so one session context can re-order the whole page, not a single widget. Here we show it re-order the product feed.
How this is measured — the exact formula is the scoring rule above, and the result rows are the feed below, in the order the engine returned them.
bunsarcurated productssession context · the engine’s own formulareconstructed offline — not a live call
This is the engine’s own feed and scoring rule recomputed over our demo catalog — a reconstruction, never a live session. Which products are in the feed, and the order they come in, are the engine’s result rows; only the absolute scores are illustrative, and only the session context changes between the two runs.
Said plainly: we keep no shopper profile. That is a claim about our data model, not about server logs — the session ids ride on the request like ordinary web traffic, and can appear in a routine log like any other request does.
Where a vendor puts a lift chart, we put the shift itself.
No borrowed benchmark — no lift figure, no conversion claim, no session count, no logo wall. The proof is the feed moving: the same product, the same feed, re-sequenced by the one thing that changed between the two shoppers — the pieces each had been opening.
And the same engine is honest about the shopper it cannot read yet: a cold session — no pieces opened — gets the catalog’s own feed order, byte-for-byte identical for everyone. The feed re-orders when there is a session to read; until then it is the listing you would ship without us. See what the same engine builds →
Point it at your own range and watch the feed re-order for two shoppers who opened the same product — no profile to build.
Book a demo