Retention decisions are product decisions

Retention periods get chosen badly. Somebody looks at what a comparable company published, picks a similar number, and it goes in the policy. The number then quietly determines what the product can and cannot do, and nobody revisits it.

Work backwards from the use

There are four distinct uses for stored conversations, and each implies a different minimum:

• Answering an in-flight conversation. Needs the session only. Minutes.
• Support follow up, where someone references an earlier conversation. Days to weeks.
• Content gap analysis, the monthly review of what people asked. Needs enough history to see repetition. Months.
• Trend analysis across seasons or comparing before and after a site change. Needs a year or more.

If you are doing the third, thirty days is too short. You will keep discovering the same gaps because you cannot see that they repeat.

Separate the content from the identifiers

The strongest available design here is that these do not have to share a lifetime. The question text is what you need for analysis. The identifiers, meaning IP, email, session identity, are what carry the privacy weight.

Delete or detach the identifiers early and keep the question text longer. You retain the analytical value and shed most of the sensitivity. This is a design decision, and it has to be made before the schema is built, because retrofitting it is significantly harder than designing for it.

Deletion is not one action

A deletion request touches more places than the primary database, and any honest deletion commitment has to account for all of them:

• The primary conversation store.
• The search or vector index, if conversation content was indexed.
• Analytics aggregates, which may not be individually deletable.
• Backups, which typically expire on their own schedule rather than being edited.
• Any third party provider that received the data, subject to their terms.
• Logs, which are the most frequently forgotten.

This is why immediate deletion claims are almost always inaccurate. The honest version states a working timeframe for the primary systems and acknowledges that backups expire on their own cycle.

What to publish

Publish the period once it is decided, and publish it as a maximum rather than a promise about any specific record. Do not publish a number that has not been implemented. A policy that says ninety days while the database has never had anything deleted is worse than no number at all, because it is a specific verifiable claim that is false.

The default that is defensible

For a website assistant on a marketing site, a reasonable starting position is: full conversations with identifiers for a shorter window sufficient for support follow up, question text with identifiers stripped for a longer window sufficient for analysis, and a documented deletion path on request.

That is a design, not a recommendation with legal weight. The specific durations should be set with advice appropriate to your jurisdiction and your data. What I am arguing for is that the numbers come from a decision rather than from a competitor's footer.