---
title: "Customer memory for ecommerce AI"
description: "How ecommerce AI remembers one customer across storefront, email, chat and returns: identity resolution, changing sizes and seasonal facts that expire."
canonical: https://past.dev/industries/ecommerce
last-updated: 2026-09-02
---
# Customer memory for ecommerce AI

Source: https://past.dev/industries/ecommerce

Ecommerce AI needs one memory per customer rather than one per channel. The same person browses the storefront, emails support, chats with an agent and stands at the returns desk, usually under different identifiers. Useful customer memory resolves those identifiers to one profile, records orders and returns as dated events, supersedes preferences and sizes when they change, and expires seasonal facts on schedule. Without those mechanics, the agent recommends the jacket the customer returned in March and sizes them from an order placed two years ago.

## One customer, four identifiers

The same shopper reaches a brand through a storefront account, a support email address, an anonymous chat session and an order number read out at a returns desk. Each channel stores its own fragment under its own identifier. Until those fragments resolve to one profile, the agent treats one person as four unrelated customers, and every channel restarts the relationship from zero.

Linking records that carry different identifiers for the same person is [identity resolution](/guides/identity-resolution). It builds on [entity resolution](/glossary/entity-resolution) and depends on [merging duplicate profiles](/guides/merge-duplicate-profiles) carefully, because a wrong merge shows one customer another customer's history. Merge quality is testable; [testing entity resolution](/guides/testing-entity-resolution) describes the probes.

## Stale personalization is the visible failure

Memory failures in ecommerce are customer-visible. The recommendation engine proposes the coat that came back three weeks ago. The chat agent offers a leather restock alert to a customer who wrote in April that she had stopped buying leather. The size on file predates a documented exchange. Each incident has the same mechanical cause: the store kept a fact after the world changed.

- **Session-scoped memory forgets the customer.** [Session memory](/glossary/session-memory) ends with the conversation. Ecommerce needs [cross-session memory](/glossary/cross-session-memory) keyed to the customer rather than to the chat.
- **Summaries lose the timeline.** Bought, exchanged, returned is a sequence. A summary that records a preference for the coat cannot express that the coat came back. Orders and returns are [episodic facts](/glossary/episodic-memory): dated events kept in order by [event time](/glossary/event-time).
- **Preferences change without announcement.** A customer who moved to size S on January 8 keeps receiving size M suggestions until something closes the old fact. Handling that change is [fact supersession](/glossary/fact-supersession).
- **Seasonal facts never age out.** December's ski glove search was a gift purchase. Without a [forgetting policy](/guides/forgetting-policy) it keeps influencing recommendations in July. [Memory decay](/glossary/memory-decay) describes time-based downweighting.

## What the memory layer must provide

| Ecommerce requirement | Memory mechanism | Where it is defined |
| --- | --- | --- |
| One profile across storefront, email, chat and returns | Channel identifiers resolve to one customer entity | [Identity resolution](/guides/identity-resolution) |
| Sizes and preferences that change | The new value supersedes the old one and both keep their dates | [Facts that change over time](/guides/facts-that-change-over-time) |
| Order and return timelines | Events stored in true order by their own timestamps | [Event time vs ingestion time](/guides/event-time-vs-ingestion-time) |
| Seasonal interest that should fade | Facts carry expiry or decay rules per class | [Forgetting policy](/guides/forgetting-policy) |
| Recommendations that can be checked | Each recalled fact cites its dated source | [Data provenance](/guides/data-provenance) |

The probes that evaluate memory systems generally apply directly here: state a purchase with a date, state a return with a later date, then ask what the current state is. The [benchmark methodology](/benchmarks/methodology) describes how update and ordering probes are scored.

## A worked example: Maya, twelve months

Maya Lindgren shops with one brand across every channel for a year. The timeline is ordinary, which is what makes it a good test.

| Date | Event | What memory must record |
| --- | --- | --- |
| Oct 12, 2025 | Buys the Arden coat, size M, on the storefront | Order event; a size M fact opens |
| Dec 14, 2025 | Searches ski gloves and buys one pair as a gift | Interest fact with a seasonal class and an expiry |
| Jan 8, 2026 | Exchanges the coat for size S by email | Exchange event; size M closes Jan 8 and links to size S |
| Apr 2, 2026 | Writes in chat that she has stopped buying leather | Preference fact, source: the chat message, resolved to the same Maya |
| Jun 30, 2026 | Returns a suede bag at a store desk under her order number | Return event linked to her profile through the order identifier |

```thesizefactsaftertheexchange
[
  {
    "id": "fact_71c",
    "subject": "customer-maya-lindgren",
    "predicate": "coat_size",
    "value": "M",
    "valid_from": "2025-10-12",
    "valid_to": "2026-01-08",
    "superseded_by": "fact_a44",
    "source": "order-58112"
  },
  {
    "id": "fact_a44",
    "subject": "customer-maya-lindgren",
    "predicate": "coat_size",
    "value": "S",
    "valid_from": "2026-01-08",
    "valid_to": null,
    "superseded_by": null,
    "source": "exchange-58112-r1"
  }
]
```

In August 2026 an agent with this memory recommends size S, avoids leather and suede, and leaves ski gloves alone. An agent on channel-siloed chat memory recommends a size M leather bag, and Maya notices.

## Forgetting as a product feature

Ecommerce carries a lighter records burden than regulated industries, so forgetting is mostly a quality tool rather than an obligation. Two distinct mechanisms cover it, and they should never be conflated.

- **Expiry by class.** Seasonal and campaign-driven signals carry short horizons, while sizes and stated preferences persist until superseded. [AI data retention](/guides/ai-data-retention) covers setting horizons per record class.
- **Erasure on request.** When a customer asks for deletion, removal works by source: the chat logs, the order feed, and every derived fact that only those sources supported. [GDPR memory deletion](/guides/gdpr-memory-deletion) covers doing this verifiably.

Expiry and erasure have different triggers and different guarantees. Treating them as one operation either deletes too much or forgets too little, and both mistakes show up in the customer experience.

## Where past.dev fits

past.dev is a memory API for AI agents: send order events, chat messages and emails with their original timestamps, and it resolves them to one customer, tracks changed preferences through supersession, and returns recall results with dates and sources. Deleting a source erases what only that source supported. The [quickstart](/docs/memory-api/quickstart) shows the ingest and recall calls.

## Frequently asked questions

### Why does my ecommerce chatbot recommend products the customer already returned?

Because its memory recorded the purchase and never recorded the return, or recorded both without ordering them. Returns must be stored as dated events on the same customer timeline as orders, so the current state reflects the return.

### How do I unify a customer's chat, email and order history into one memory?

Ingest each channel with its own identifiers and timestamps, then resolve those identifiers to one customer profile through identity resolution. Keep the source on every fact so a wrong merge can be found and unwound.

### Should ecommerce AI memory expire old customer data?

Expire by class rather than globally. Seasonal and campaign signals should fade within weeks, sizes and stated preferences should persist until the customer changes them, and deletion requests are a separate path that removes data by source.

### Does past.dev work for ecommerce personalization?

past.dev stores order events, chats and emails with their original timestamps, resolves them to one customer, and returns recall with dates and sources, which is the memory substrate personalization needs. Ranking and merchandising remain the application's job.

## Related

- [Financial services AI](https://past.dev/industries/financial-services)
- [Healthcare AI agents](https://past.dev/industries/healthcare)
- [Identity resolution](https://past.dev/guides/identity-resolution)
- [Merging duplicate profiles](https://past.dev/guides/merge-duplicate-profiles)
- [Forgetting policy](https://past.dev/guides/forgetting-policy)
- [Customer support memory](https://past.dev/use-cases/customer-support)