Should raw telemetry expire by default?

As an open-source app maintainer, I’m leaning toward an automatic expiry for raw behavioral telemetry. Detailed clickstream and feature-use events are useful for debugging regressions, checking feature behavior, improving recommendations, and investigating abuse—but I don’t see why they should quietly become permanent history.

My practical default would be 7–30 days, followed by deletion or retention of only coarse aggregates. There’s a real trade-off: a late-discovered attack or regression may be harder to investigate, while keeping everything costs storage and expands the consequences of a breach. Still, “anonymous” event histories can remain linkable through timestamps, devices, and repeated actions, gradually forming a personal behavioral profile.

Minimization should be a system behavior, not an opt-out promise. I’d allow documented exceptions for active incidents, legal preservation, or a specifically justified operational need. Would you trust automatic retention limits, and what exceptions would you consider justified?

Seven days is fine for many regressions, but security investigations are the awkward case. If detection is delayed, the evidence may already be gone. I’d support a short default window plus an explicit incident hold that records who approved it and when it expires.

The incident hold is the important part. “Anonymous” is often treated as a magic eraser when it usually just means the obvious name was removed. Automatic deletion makes the safer choice happen without asking every user to understand a retention policy.

I’m less sure about deleting recommendation data after 30 days. Product teams need longer trends than that, though coarse aggregates can probably answer most planning questions. The boundary should be raw event trails versus useful statistics, not telemetry versus no telemetry.

I’d separate abuse evidence from product analytics. A suspicious account or attack can justify a narrowly scoped preservation hold, but “we might need it someday” should not. The hold itself should be auditable and access-controlled, or it becomes indefinite retention by another name.

If deletion requires a quarterly meeting, it will not happen. Put the expiry in the pipeline, make extensions annoying enough to explain, and keep the aggregate tables boring. Boring is underrated here.

One concern: coarse aggregates can still expose small groups or unusual behavior. Expiry is a good default, but aggregation needs minimum-group thresholds and sensible access controls. Otherwise we’ve reduced the resolution without really reducing the risk.

The operational exception needs a ticket, an owner, and an end date. That sounds bureaucratic, but it prevents “temporary” forensic retention from becoming a forgotten bucket in storage. I’d trust limits more if exceptions leave that paper trail.