{{ p.title }}

A recommendation system learns from behavior: what a shopper opened, compared, kept and returned. Collected carelessly, that behavior ends up attached to names, email addresses and payment details, and the system becomes a store of personal data with a recommendation feature on top. We decided early that our system would make decisions from behavior alone. That choice has engineering consequences, and it has limits worth stating plainly.

Pseudonymous and anonymous are different things

Anonymous data cannot be linked back to a person by anyone. Pseudonymous data replaces direct identifiers, such as a name or an email address, with a stand-in identifier, so it can be linked back to a person only with additional information held separately. Our system works with pseudonymous identifiers. Describing that as anonymous would be inaccurate.

The distinction has legal weight. Under the EU’s General Data Protection Regulation, pseudonymized data is still personal data, and the obligations attached to personal data still apply. US state privacy laws treat it in varying ways. Pseudonymity reduces risk and narrows what a breach could expose. It does not take a system outside data protection law, and we do not present it as if it did.

What the system reads, and what it never stores

The decision path reads behavioral signals tied to a pseudonymous identifier: products viewed and compared, filters applied, items added to a cart, and the surface and context of the request. From these it builds the dimensions of the User Barcode, which describe shopping intent in the current session. It does not receive or store names, email addresses, phone numbers, postal addresses or payment card numbers.

Keeping those fields out is easiest to enforce at the boundary. A decision request needs an identifier and behavioral events and nothing else, and an integration built around only those fields is far less likely to carry personal data by accident.

Who holds the key

If a business wants to connect a shopper’s sessions to its own customer records, for example to use purchase history in a decision, the mapping between the pseudonymous identifier and the real customer stays on the business’s side. We never hold the key that re-identifies a shopper, so a breach of our systems would expose behavior tied to identifiers that mean nothing without data we do not have.

This shifts some responsibility to the business. The key has to be managed and access to it controlled, and the identifiers have to be generated so they cannot be reversed or guessed. An identifier derived predictably from an email address offers little protection, because anyone holding a list of email addresses could recompute it. Identifiers should be random or produced with a secret the business controls.

Where the data lives and how long it stays

Behavioral data is stored in the region the customer chooses: the US, the EU or India. It is removed within 30 days of a deletion request. Beyond that, shorter retention is generally better. Behavior from two years ago says little about intent today, and keeping it adds risk without improving decisions.

What pseudonymity cannot do

Pseudonymity does not prevent inference. Behavior alone can reveal sensitive information, and a pattern of purchases can suggest a health condition or a life event. Removing names does nothing about that. The protection has to come from limiting what the system is allowed to infer, which is why our dimensions are restricted to shopping intent and exclude characteristics such as health, ethnicity, religion and sexual orientation.

Pseudonymity also costs some capability. Without a stable identity, linking a shopper across devices is limited to what the business itself can connect, and a shopper who clears cookies starts again as a new visitor. For most storefront decisions the session carries enough signal. Where history improves a decision, the business can pass its own consented signals through the pseudonymous identifier.

And it is one control among several. Encryption in transit and at rest, access controls, audit logging and vendor review still apply. Our controls are documented in the Trust center, which also publishes the status of our SOC 2 Type I and Type II audits, both expected to complete in the fourth quarter of 2026.

Five questions to ask any vendor

For a business evaluating a recommendation vendor, the useful questions are concrete: which fields the integration accepts, who holds the re-identification key, where the data is stored, how quickly it is deleted, and what the system is prevented from inferring. General assurances about privacy are easy to give. Specific answers to those five questions are much harder to fake.

Read the Trust center