Should recommendation systems have a genuinely forgetful mode?

I’d support a real “forgetful mode” for recommendations, not just a label saying “personalized privately.” The system could use clicks, searches, and dwell time during the current session, then expire those signals after a clearly stated interval. They should not be joined to a cross-service identity or exported into a lasting profile or training set. The obvious cost is weaker continuity: recommendations may feel less relevant when someone returns later. That seems like a reasonable trade if the product is honest about it.

The harder product question is proving the forgetting happened. A toggle and privacy policy require trust; I’d rather see an expiration timestamp, a record of which signals influenced a recommendation, and some auditable evidence that the data was deleted or disassociated across the relevant systems. I’m not sure ordinary users can independently verify that today. Is session-limited personalization a realistic privacy feature, or merely a less useful form of tracking? Concrete examples and counterarguments welcome.

The distinction between “not used for personalization” and “actually expired” matters. I’d want the product to state the retention boundary precisely, including whether event data can remain in logs, caches, or backups. Otherwise forgetful mode is mostly a promise about one query path.

Technically, the cleanest version uses a session identifier with a hard TTL and prevents that identifier from entering the identity graph. The ugly part is every side channel: analytics exports, debugging logs, feature experiments, and model pipelines. “Delete the profile” is much easier than proving no derivative copy survived.

This fits the general logic of purpose limitation, minimization, and storage limitation, but it should not be described as a specific legal requirement. The verification proposal is stronger than a badge because it treats retention as a lifecycle property rather than a front-end setting.

I’d threat-model the timestamp itself. A user-visible ledger can demonstrate what the service claims happened, but unless it is backed by independent auditing or tamper-evident records, the same operator controls the evidence and the system being assessed.

There’s also a social benefit to weaker continuity. A recommendation system that forgets can stop quietly reinforcing an old phase, obsession, or sensitive curiosity. “Why am I seeing this?” becomes easier to answer when the answer is simply “because of this session.”

Expiration is not a delete call. You need enforcement at ingestion, storage, queues, exports, caches, and model-training boundaries. If the product team cannot name those boundaries, the mode is probably just a preference flag attached to the ranking service.

I’m not convinced session-only is automatically a privacy win if the service can still infer a lot during the session and act on it immediately. A short-lived dossier is still a dossier. The benefit depends on what happens after expiration and whether sensitive inferences are blocked too.

A useful implementation might keep the temporary ranking state on the device, with the server receiving only requests that do not carry a durable account identifier. That would not solve every problem, but it reduces the number of places where expiration has to be trusted.

The support burden would be real. Users will ask why yesterday’s recommendations vanished, whether clearing a session also clears queued events, and what “disassociated” means. If the answer needs a data-governance specialist, the feature is not finished.

From a business angle, the question is whether the product can tolerate less behavioral history for targeting and experimentation. I’d expect some firms to offer this only if the setting is easy to understand and the commercial trade-off is measured rather than assumed.

The old web managed to recommend things without knowing my entire biography. Not perfectly, obviously, but “less accurate” is doing a lot of work here. Sometimes a product should accept being mediocre at guessing.

For enterprise buyers, I’d want a retention control that maps to a documented test: sample events, wait past the TTL, then verify they no longer affect ranking or appear in exports. A marketing claim without test evidence will not survive procurement review.

I’d ship it with a visible countdown and a “why this appeared” panel before attempting a grand proof system. Imperfect transparency that users can understand beats a perfect backend policy nobody can inspect.