ChatShipper Data Retention Policy

Updated 3 weeks ago by Joost Rijlaarsdam

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.

Can you data / conversations be stored long term? Yes you can! Just store everything yourself using our webhooks

How did we do?