ChatShipper Data Retention Policy
As per the docs, these types: https://developers.chatshipper.com/messaging/messagetypes/
- chat: a regular chat message from an agent or from a consumer (default).
- card: a card-shaped message from an agent or from a consumer.
- postback: a canned response for an action button from an agent or a consumer.
- mention: a comment left by the agent for an organization or another agent.
- tag: a command sent by the agent.
- search: a search command sent by the agent.
- command: a command sent by the agent.
- form: activation or de-activation of a form within the conversation's current category.
- field: a recording of a data result for a form field.
- results: a set of one or more results as completed and 'sent' by the agent.
- report: a set of one or more results as generated by a bot.
- status: a system-generated status triggered by the system.
Can each have their own life expectancy.
ChatShipper has implemented a simple and fairly aggressive default CS message retention policy across the board:
- results: 1 year
- chat, card, mention: 6 months
- reports: 3 months
- anything backchannel (bots, team, articles, approaches): 30 days
- tag, postbacks, command, bot-command, status, search, forms, fields : 30 days
This applies to *messages* in the event stream, not active conversation.forms, conversation.results, conversation.intent and so on - conversation state is permanent. Also, these are shown in the UI as 'sliding windows' - eg a 30-day old 'approach' article is visible in the stream today, but gone tomorrow.
The following resources may be "archived" instead of permanently deleted:
- - users
- - organizations
All other resources are immediately, permanently removed from live systems on deletion.
We think this approach is defendable, given GDPR and all - risk minimization. Also, trims all conversations, speeds up UI, decreases overhead cost-per-org, enables cost-effective service provisioning, and we provide ample ways to store and process messages for longer-term storage yourself, anyway.
We _could_ implement overriding everything per-org from the admin UI if needed (eg set all msg types to max 18 months), but I feel simply enforcing strict, short retention periods will send a stronger message about how to optimize CS usage (keep communicating, keep it flowing).
All automatic deletions can propagate as webhook events, and could trigger additional business processes (eg "@admin we've deleted your Mailgun for non-usage, click here to re-enable"-bot) if needed.