Product wants to add "customers who bought this also bought" using purchase history. What does privacy by design require here?

The first question is lawful basis, not architecture

Purchase history was collected to fulfil orders. Using it for recommendations is a new purpose, and purpose limitation means it requires a basis: either legitimate interest with a documented balancing test, or consent.

This is the step engineers skip, because the technical instinct is that data already held is available for any use. Establishing the basis first determines everything downstream — under consent, the feature must work for users who decline, and withdrawal must propagate.

Then the design, applying minimisation

Aggregate rather than individualise where possible. "Customers who bought X also bought Y" can be computed from item co-occurrence counts across all customers — a matrix of products, containing no personal data at all. That version is out of scope for most privacy obligations entirely, and it delivers most of the product value.

Personalised recommendations using an individual's own history are a stronger feature and a materially larger obligation. Make that a deliberate, separate decision rather than an implementation detail.

Set a threshold. A co-occurrence pair supported by very few purchases can identify individuals — "customers who bought this rare item also bought" with a count of two is a disclosure. Suppress below a minimum support count. This is the sort of re-identification risk that gets missed.

Retention. The aggregate matrix does not need raw history retained indefinitely; recompute periodically and let the underlying data age out per the existing retention policy.

The obligations that follow the data

Erasure — if the model is trained on individual histories, an erasure request must reach it. An aggregate recomputed on a schedule handles this naturally; a per-user embedding does not.

Purpose recorded in the catalogue and propagated through lineage, so the derived dataset carries its constraints.

Sensitive categories excluded. Purchases can reveal health conditions, religion, sexual orientation and pregnancy — all special categories with stricter rules. A recommendation engine that surfaces these inferences has caused real harm and real regulatory attention, and category exclusion is a design decision.

What a strong answer adds

Naming the aggregate-versus-individual choice as the architectural decision, because it determines whether the feature carries privacy obligations at all. The instinct is to build the more sophisticated version; the aggregate version delivers most of the value, has no erasure obligation, no consent dependency and no re-identification risk, and can be built in a fraction of the time.