E-Commerce Recommendations
Recommendations that account for what the shopper told you
Combine durable memory of stated constraints and preferences with your catalogue, so recommendations reflect the conversation rather than click history alone.
The problem
Recommendation systems infer intent from behaviour, which misses everything a shopper says outright. A customer who states a budget, an allergy, or that they are buying a gift gets recommendations built from clicks — and the constraint they explicitly stated is the one that gets violated.
With MemorySync
MemorySync stores stated constraints and preferences as durable facts scoped to that shopper. Retrieved before recommendations are generated, they filter and shape the result so an explicit constraint is never contradicted.
How it works
- 1
Listen
Constraints and preferences stated in conversation become durable facts.
- 2
Scope
Memories bind to a stable opaque shopper identifier.
- 3
Retrieve
Relevant constraints are fetched before recommendations are generated.
- 4
Recommend
Catalogue results are filtered and ordered against those constraints.
Behavioural signals miss stated intent
Collaborative filtering is good at what shoppers like people who bought this. It has no channel for what this shopper just said.
When someone states a budget ceiling, a material they cannot wear, or that this purchase is a gift for someone else, that is far stronger signal than a click. Ignoring it produces recommendations that read as not listening — and in the allergy case, as unsafe.
Constraints and preferences behave differently
Worth separating, because they should be treated differently at generation time:
- Hard constraints must never be violated. Allergies, budget ceilings, size, incompatibilities. These filter the result set.
- Soft preferences shape ordering. Style, brand affinity, colour.
- Situational context expires. Buying a gift applies to this session, not the next.
Conflating hard constraints with soft preferences is how a system recommends something a shopper explicitly ruled out.
A recommendation that violates a stated constraint costs more trust than ten mediocre recommendations.
Situational context must expire
Some context is deliberately temporary. Shopping for a gift should not permanently reshape someone's recommendations.
Recency weighting and supersession in MemorySync let situational facts fade while durable constraints persist, so a one-off purchase does not distort the profile indefinitely.
Combining with the catalogue
Memory does not replace your recommendation engine. It supplies the shopper-side constraints it cannot see.
Retrieve constraints before generating, apply hard ones as filters and soft ones as ranking signals, and keep the catalogue system unchanged. This keeps the two concerns separable and independently testable.
Why inspectable retrieval matters commercially
When a recommendation is wrong in a way a customer complains about, someone has to explain it. Being able to see which constraints were retrieved for that request turns an unexplainable output into a fixable one.
Scope and privacy
Shopper memory is personal data, frequently including health-adjacent facts such as allergies. Use a stable opaque identifier rather than an email, keep scope enforced server-side, and ensure deletion removes derived memories rather than only the source record.
What you get
- Stated constraints are respected
- Preferences persist across sessions
- Superseded constraints stop applying
- Conversational and behavioural signals combine
- Inspectable retrieval per recommendation
- Opaque per-shopper scope
Use cases
Build e-commerce recommendations with durable memory
Start on the free tier and test retrieval, scoping, and deletion against your own workload.
Start free. No credit card required.