PayCal Technologies Inc.

Transparenz der Plattformmetriken

Diese Seite zeigt, welche Telemetrie PayCal sammelt, warum wir sie sammeln und wann sie gelöscht wird.

Veröffentlicht:

Unser Versprechen

Nutzer sollten genau sehen können, welche Telemetrie ein Dienst sammelt. Diese Seite dokumentiert jede Metrik zur Überwachung der Plattformgesundheit.

Alle Telemetrie auf dieser Seite ist ausschließlich aggregiert. Wir speichern keine persönlichen Identifikatoren in Telemetrieschlüsseln.

Verifizierungsmetadaten

Routenmetadaten

  • Route: /transparency/metrics/
  • Zuletzt verifiziert:
  • Nächste Prüfung fällig:
  • Verifizierungsumfang: manuelle Inhaltsprüfung gegen das aktuelle Metrikschlüssel-Inventar und die Aufbewahrungsrichtlinie.

Bekannte Einschränkungen

  • Das Inventar der Metrikschlüssel wird manuell mit dem Code synchron gehalten; automatisierte Key-Diff-Werkzeuge sind für Quartalsprüfungen geplant.
  • Aufbewahrungswerte spiegeln aktuelle Standardkonfigurationen wider und enthalten keine künftigen mandantenspezifischen Overrides.

Diese Metadaten werden im Rahmen des vierteljährlichen Audit-Abschlusses aktualisiert.

Metrikinventar

Metrikkategorie Persönliche Daten? Aufbewahrung Zweck
Sitzungslebenszyklus-Metriken Nein 30 Tage roh, 52 Wochen Rollup, 24 Monate monatlich Nutzererlebnis und Kapazitätsplanung
Redis-Gesundheitsmetriken Nein 24 Stunden roh, 7 Tage stündlich, 4 Wochen täglich Infrastrukturzuverlässigkeit
Business-Aggregate Nein 30 Tage täglich, 52 Wochen wöchentlich, 24 Monate monatlich Wachstum und Planung
Frontend-Telemetrieereignisse Nein 30 Tage Fehlererkennung und Feature-Gesundheit
Verschlüsselungsoperations-Metriken Nein 30 Tage roh, 52 Wochen Rollup, 24 Monate monatlich Kryptografische Zuverlässigkeit

Sitzungslebenszyklus-Metriken Keine persönlichen Daten

Wir zählen Login-/Logout-Summen und Sitzungsdauerbereiche, um Nutzungsmuster zu verstehen. Wir verfolgen nicht, wer sich angemeldet hat.

Was: tägliche Login-Events, Logout-Events und Verteilungen der Sitzungsdauer.

Warum: Authentifizierungsprobleme erkennen, Reibung reduzieren und Kapazitätsplanung verbessern.

Wie: tägliche Zähler und feste Dauer-Buckets.

Aufbewahrung: 30 Tage roh -> 52 Wochen Rollup -> 24 Monate monatlich -> Löschung.

Buckets:

  • 0-5min - schnelle Prüfungen
  • 5-30min - typische Sitzung
  • 30-60min - verlängerte Sitzung
  • 60min+ - lange Arbeitssitzung

Beispielschlüssel:

telemetry:auth:login:2026-03-09      -> 247
telemetry:auth:logout:2026-03-09     -> 219
telemetry:session:duration:0-5min    -> 45
telemetry:session:duration:5-30min   -> 128
telemetry:session:duration:30-60min  -> 39
telemetry:session:duration:60min+    -> 7

Privacy Guard: Der Session-Hash wird direkt nach der Dauerberechnung zerstört. Keine Nutzer-UUIDs werden in Telemetrieschlüsseln gespeichert.

Volumenlimit: maximal 734 Schlüssel/Jahr.

Redis-Gesundheitsmetriken Keine persönlichen Daten

Wir überwachen Redis als Infrastrukturgesundheitsdaten, nicht als Nutzeraktivitätsdaten.

Was: Speichernutzung, Schlüsselzahlen nach Namespace und Verbindungsstatistiken.

Warum: Speicherlecks erkennen, Evictions verhindern und Wachstum beobachten.

Wie: Redis-INFO-Ausgabe in geplanten Intervallen parsen.

Aufbewahrung: 24 Stunden roh -> 7 Tage stündlich -> 4 Wochen täglich -> Löschung.

Namespaces: maximal 10 verfolgte Namespaces (fest kodierte Allowlist).

  • session:* - Active sessions
  • lock:* - Distributed locks
  • cache:* - Application cache
  • telemetry:* - Metrics storage
  • ratelimit:* - Rate limiting counters
  • nonce:* - CSRF tokens
  • temp:* - Temporary data
  • queue:* - Job queues
  • encryption:* - Wrapped keys
  • feature:* - Feature flags

Beispielschlüssel:

telemetry:redis:memory:used_mb:2026-03-09:14  -> 247
telemetry:redis:keys:session:2026-03-09:14    -> 342
telemetry:redis:keys:lock:2026-03-09:14       -> 18

Privacy Guard: Namespace-Zahlen sind nur aggregiert. Schlüsselinhalte werden nicht inspiziert.

Volumenlimit: maximal 1.680 Schlüssel im aktiven rollierenden Fenster.

Business-Aggregatmetriken Keine persönlichen Daten

Dies sind Plattform-Gesamtsummen für Planung, nicht für Profiling einzelner Personen.

Was: Gesamtnutzer, aktive Konten, durchschnittliche Arbeitseinträge.

Warum: Kapazitätsplanung und Wachstumsanalyse.

Wie: tägliche Aggregation von Datenbankzählungen.

Aufbewahrung: 30 Tage täglich -> 52 Wochen wöchentlich -> 24 Monate monatlich -> Löschung.

Beispielschlüssel:

telemetry:business:users:total:2026-03-09     -> 1247
telemetry:business:users:active:2026-03-09    -> 892
telemetry:business:work:avg_per_user:2026-03  -> 23.4

Privacy Guard: Nur Aggregatwerte. Keine Telemetriedatensätze pro Nutzer.

Volumenlimit: 1.095 Schlüssel/Jahr.

Frontend-Telemetrieereignisse Keine persönlichen Daten

Event-Telemetrie hilft, clientseitige Fehler und Feature-Zuverlässigkeit zu erkennen.

Was: Frontend-Performanceevents, Fehlerzahlen und Feature-Nutzungsereignisse.

Warum: Clientprobleme erkennen und Produktgesundheit überwachen.

Wie: POST an /api/telemetry/record nur für freigegebene Eventtypen.

Aufbewahrung: 30 Tage (TTL beim Inkrement erzwungen).

Übermittlungslimits und Beispiel-Eventtypen:

  • 90 events/minute per client (abuse prevention)
  • calendar.load.success
  • calendar.load.failure
  • encryption.dek.unwrap.success
  • encryption.dek.unwrap.failure
  • passkey.login.success
  • passkey.login.failure

Beispielschlüssel:

telemetry:event:calendar.load.success:2026-03-09    -> 3421
telemetry:event:passkey.login.failure:2026-03-09    -> 17

Privacy Guard: Eventtypen sind allowlisted. Keine beliebigen Strings und keine Nutzer-/Sitzungsidentifikatoren in Telemetrieschlüsseln.

Volumenlimit: maximal 18.250 Schlüssel/Jahr.

Verschlüsselungsoperations-Metriken Keine persönlichen Daten

Kryptografische Operationen werden als Plattform-Zuverlässigkeitssignale überwacht.

Was: DEK-Wrap-/Unwrap-Erfolgs- und Fehlerzähler.

Warum: kryptografische Fehler und Fehlkonfigurationen schnell erkennen.

Wie: Erfolgs-/Fehlerzähler werden für jedes Operationsergebnis erhöht.

Aufbewahrung: 30 Tage roh -> 52 Wochen Rollup -> 24 Monate monatlich -> Löschung.

Beispielschlüssel:

telemetry:encryption:dek:wrap:success:2026-03-09      -> 1203
telemetry:encryption:dek:wrap:failure:2026-03-09      -> 2
telemetry:encryption:dek:unwrap:success:2026-03-09    -> 5847
telemetry:encryption:dek:unwrap:failure:2026-03-09    -> 31

Privacy Guard: Nur Operationszahlen werden erfasst. Kein Schlüsselmaterial, Ciphertext oder persönliche Identifikatoren werden gespeichert.

Volumenlimit: 1.460 Schlüssel/Jahr.

Aufbewahrungs- und Kompaktierungspipeline

Rohdaten: tägliche Zähler laufen automatisch nach 30 Tagen ab.

Wöchentliche Rollups: geplante Aggregation auf 52 Wochen Aufbewahrung.

Monatliche Rollups: geplante Aggregation auf 24 Monate Aufbewahrung.

Löschung: Metriken älter als 24 Monate werden gelöscht.

Kompaktierungsskript: /scripts/compact-metrics.php.

Durchsetzung im Code

Datenschutzbedingungen werden durch Contract Tests in CI validiert.

MetricsPrivacyContractTest::testSessionDurationHasExactlyFourBuckets()
MetricsPrivacyContractTest::testNoUserUUIDsInTelemetryKeys()
MetricsPrivacyContractTest::testRedisNamespacesNeverExceedTen()
MetricsPrivacyContractTest::testAllTelemetryKeysHaveTTL()

Guardrails: fest kodierte Namespace-/Eventlimits verhindern unbegrenztes Metrikwachstum.

Zusätzliche Rate Limits:

  • Admin-Metrikabfragen: 100 Requests/Stunde
  • Öffentliche Health Checks: 600 Requests/Stunde

Zugriff und Verifizierung

Metrik-Dashboard: /admin/metrics (Authentifizierung und Adminrolle erforderlich).

Öffentlicher Health Endpoint: /api/v1/health gibt aggregierten Plattformstatus zurück.

Zuletzt aktualisiert: 9. März 2026.