SilentChat

PRIVACY BY DESIGN

We know where your data is. Always.

Six stages, from the first keystroke in the widget to deletion. Configurable per tenant, every deletion with an audit entry.

01

Collection

Data is created when an end customer interacts with the widget. We collect what the chat needs: a random visitor identifier (stored in the browser, only from the first chat), the conversation, optional name and email (only if voluntarily provided), a salted hash of the IP address, browser, device and operating system, country, language, referrer including campaign values, and the page where the chat started. Further visited pages only if the operator switches on visitor tracking (default: off). Operators can additionally transmit their own attributes and events through the widget JavaScript API — what arrives there is decided by their own code, and it runs through the same lifecycle as everything else.

  • Visitor IP never in plain text — salted hash on the session
  • No third-party cookies
  • No third-party trackers or pixels
  • Visitor can stay anonymous
02

Processing

Data is processed in realtime during the conversation. Bot answers are based on RAG over your knowledge base — according to IONOS, inputs are not used to train the models.

  • The AI receives the conversation and knowledge-base excerpts — no visitor identifier, no name from the profile
  • AI processing exclusively at IONOS in Germany
  • No AI providers outside Germany
  • Sentiment analysis for agents via the same provider
03

Storage

Active conversations live in a PostgreSQL database in Germany (Hetzner, Falkenstein). External connections exclusively over TLS. Tenant isolation enforced at the repository layer.

  • Database backup every 6 hours, encrypted, off-site at Strato in Germany
  • Credentials and keys additionally encrypted at the application layer (AES-256-GCM)
  • No data copy outside the EU
  • Backup retention 30 days rolling
04

End of retention

Default: 180 days after a conversation is closed, configurable per tenant between 7 and 365 days. After that the data is deleted, not merely anonymised: 30 days in the recycle bin, then permanently.

  • Trigger: conversation closed + retention period
  • Deletion instead of anonymisation
  • Separate periods for sessions and page views
  • Every run is recorded in the audit log
05

Deletion

Operators carry out deletion requests (GDPR Art. 17) in the dashboard: Settings → Data retention → Delete visitor data. Deletion takes effect immediately and completely — sessions, page views, events, conversations with messages and notes, contact and visitor. Backups expire after 30 days at the latest.

  • Deletion in the dashboard, per visitor identifier
  • Effective immediately
  • At most 30 days incl. backups
  • Audit entry for every deletion
06

Export

Access (Art. 15) and portability (Art. 20) as JSON: visitor profile, sessions, conversations with messages, and consents. Requested through the widget interface, delivered via a confirmation link to the visitor's email address.

  • JSON format, machine-readable
  • Incl. conversations with messages, sessions, consents
  • Confirmation link by email, valid for 24 hours
  • No third-party data (nothing about agents)

RETENTION OVERVIEW

What we keep, and for how long.

Active conversations
while ticket is open
Tenant DB, EU
Closed conversations
7–365 days (default 180)
Tenant DB, EU
Offline messages
365 days
Tenant DB, EU
Audit log
12 months (up to 24 with a longer plan viewing period); records 3 years; sign-in log 90 days
Tenant DB, EU
Backups
30 days rolling
Strato, Germany (encrypted)
Login sessions
7 days / logout
Blocklist in Redis
Application logs
size-capped rotation
IP shortened, email masked
IP hashes (session)
up to 180 days
Tenant DB, EU