Do recommendations need years of my clicks to stay useful?

I’m reconsidering a fairly basic assumption in personalization: that a recommendation system should retain every click, search, pause, skip, and viewing decision for years.

A less invasive design seems technically plausible. Keep recent activity on the device, build a profile that decays over a user-chosen period, and use it for the current session or immediate task. The server could still receive narrowly scoped telemetry for errors, latency, model versions, rate-limit violations, authentication failures, and other abuse signals, without receiving a permanent behavioral diary. Raw activity would be deleted by default rather than deletion being an advanced privacy setting.

That would not be free. Cross-device continuity would get worse, as would remembering stable but infrequent interests, recovering recommendations after a reinstall, and some forms of collaborative filtering. Someone who watches one obscure topic every few months might reasonably prefer the service to remember it. I also suspect long-tail discovery would suffer in some catalogs, although I haven’t seen a general benchmark that tells us whether seven, thirty, or ninety days is the right window.

There are promising directions here: session-based recommenders, on-device profiles, and federated systems where history stays local while privacy-protected updates are shared. But “local” is not a magic word; updates can still leak information, and a compromised device is still a problem.

My current position is that a compact, inspectable preference summary should be optional, while the raw event timeline should expire unless the user explicitly chooses otherwise. Is that a sensible compromise, or would it make products noticeably worse? I’d especially like examples of privacy-preserving recommendation systems, or a strong case where long-term behavioral history creates value that recent activity cannot reproduce.

The telemetry distinction is the important part. For debugging, I want event type, timestamp, service/model version, outcome, error code, and latency. For abuse, I may need a pseudonymous session or account identifier plus authentication failures, rate-limit violations, and suspicious automation. None of that implies retaining the content of every search or pause forever.

The hard implementation question is deletion across caches, feature stores, backups, and derived embeddings. “We deleted the clicks” is not enough if a durable vector still encodes them. A local profile reduces the blast radius, but it also moves state-management and recovery problems onto the client.

I’d make deletion the lifecycle, not the button. Retention should require a purpose, a time limit, and a visible explanation.

A user-controlled summary is much more defensible than an invisible timeline. Let me see “likes science fiction” or “prefers short videos,” edit it, export it, and clear it. Don’t make me infer what the system remembers from years of oddly persistent recommendations.

I’m sympathetic, but I think the proposal understates continuity. A lot of value in recommendations is precisely that they remember the person I am not being today. Recent-session data will be excellent when I’m shopping for a thing or following a temporary interest; it may be poor at bringing back an occasional interest that never appears in the current session.

That does not justify indefinite raw logs. I’d rather see a deliberately small long-term preference model than pretend every useful signal can be reconstructed from seven days of activity.

This sounds like a good local-first boundary: raw events stay local, the profile is a materialized view with an expiry policy, and sync is an explicit feature rather than the default.

The user should be able to choose “this device only,” “sync preferences,” or “sync history,” with different retention semantics. The engineering cost is real, especially around reinstall and multi-device merge, but complexity is not an argument for making collection invisible.

Small evidence note: session-based recommendation research does support the narrow claim that current activity sequences can capture short-term, changing interests. Other work reports gains from combining recent and long-term signals. That is not evidence that a local seven-day profile matches a persistent profile across products.

The federated movie system I’ve seen reported was a feasibility deployment with 22 participants, 53 days, and 8,807 titles. Interesting, but not a production-scale quality comparison. I’d be careful not to oversell it.

“Keep it local” changes the threat model; it does not eliminate one. Model updates, gradients, sync traffic, device compromise, and re-identification still need analysis. If anything leaves the device, it needs a reason and a protection story.

For abuse prevention, short retention can work for many signals, but some investigations need linkage over a bounded period. The answer should be a documented retention schedule and access controls, not an absolute promise that servers never see identifiers.

As a small developer, I’d start with a local rolling window and no cloud profile. It is simpler to explain and gives users a feature that still works offline. The moment you add cross-device sync, you are building identity, conflict resolution, deletion propagation, and support tooling whether you planned to or not.

I’d accept weaker recommendations in exchange for not operating a permanent behavioral warehouse.

The support edge cases are where this gets messy. Someone clears their profile, reinstalls, then says the service “forgot” them. Someone else shares a television with a household and says the recommendations are contaminated. A third person wants an account deletion but has offline state on three devices.

Those are solvable, but the controls need to be ordinary product flows. If deletion requires a special request and a week of support tickets, it is not really the default.

A recommendation engine that forgets me occasionally is not a catastrophe. Sometimes it is a feature.

I’d keep explicit likes, subscriptions, and saved items indefinitely if the user asks for that. A pause on a video from 2019 should not become a personality trait.

There is a business question underneath this: does better continuity actually produce enough user value to justify the storage, governance, and breach exposure? That answer probably varies by catalog and product, so I would test it rather than argue from ideology.

Offer a local mode, a 30-day mode, and an opt-in persistent preference mode. Measure satisfaction and retention, but do not quietly use the experiment to justify keeping raw histories forever.

I agree with the direction, with one qualification: “deletion by default” needs a precise object. Raw events, derived features, embeddings, backups, fraud records, and aggregated model-training data do not all have identical deletion behavior.

The defensible principle is purpose limitation and storage limitation: retain identifiable data only as long as the purpose requires, and state what happens to each derivative. A shorter history may reduce personalization quality, but the trade-off should be explicit rather than hidden in an account setting.