Security and privacy. Personal data is protected from the start.

Security and privacy.

• Data is kept to a minimum

  • No IP address is stored. On ingestion it is used for country and city, the bot score and the internal traffic check, then dropped.
  • In the consent-required mode a unique visitor is hashed with a daily salt that is deleted at the end of the day; no persistent id is formed.
  • The web SDK writes no cookies and never reads form field values; it strips e-mail- and phone-like values and sensitive query parameters from URLs.

• Personal data is screened on ingestion

  • Every property in the event schema has a personal data class (none, pseudonymous, personal, sensitive) and an action for it: allow, hash, drop or reject.
  • An e-mail address, phone number, Turkish national id (by its checksum), IBAN or card number (Luhn) in an undefined field rejects the message, and the reason shows in the live stream.
  • Defined personal fields are hashed with HMAC-SHA256 and an app-specific key; the raw value is not stored. Ad and click ids are exempt from this screening, so campaign ids are never deleted by mistake.

• Consent is chosen per source

  • Three modes: consent required (before opt-in cookieless, without a persistent id, counted within the tab only), implied consent, and internal apps that need none.
  • Analytics and marketing consent are separate. Without marketing consent click ids are not stored and are sent to no ad platform.
  • Every message carries the consent state of its moment; the browser’s Global Privacy Control signal can turn marketing consent off.

• Organizations are isolated from each other

  • Every record belongs to one organization and is read only in that organization’s context, enforced by row-level security rules in the database; no application code bypasses them.
  • The API, ingestion and background jobs connect with separate database roles, each with only the rights it needs.
  • Roles can be scoped to apps: a member sees only the data of the chosen apps.

• Secrets sealed, keys hashed

  • Traffic is encrypted with TLS. Connection tokens, sending passwords, signing secrets and two-step verification secrets are sealed with AES-256-GCM, with a rotatable key ring.
  • Write keys and API keys are stored as hashes only; the full value is shown once, when it is created.
  • Server sources sign their requests with HMAC-SHA256; a timestamp window limits replays.

• Access is controlled and recorded

  • Signing in to the panel takes a password (scrypt) and two-step verification: a 6-digit code sent by e-mail (recommended, valid for 5 minutes, single use) or an authenticator app, with single-use recovery codes as a fallback. The session cookie is HttpOnly; sign-ins and code sends are rate-limited.
  • Every change goes to the audit log: who, when, what, with the value before and after. Client addresses are kept as hashes only.
  • Platform administration runs as a separate app with a separate session; two-step verification is mandatory for administrators.

• Retention per app

  • Raw events, interactions and sessions each get their own retention period; data past it is deleted together with its partition.
  • Test, internal and bot traffic is marked apart, and screens leave it out by default.

• Deletion requests

  • All data an app keeps about a person, named by user id, anonymous id or person id, is erased within minutes; the request stays on record with the number of rows removed.
  • A request is filed and followed in the panel under Settings → Data rights, or by your product’s server through the Management API; a pending request can be cancelled, and the id’s value is kept only until the request ends.