PayCal Technologies Inc.

Transparence des métriques de plateforme

Cette page montre quelle télémétrie PayCal collecte, pourquoi nous la collectons et quand elle est supprimée.

Publié :

Notre engagement

Les utilisateurs devraient voir exactement quelle télémétrie un service collecte. Cette page documente chaque métrique utilisée pour surveiller la santé de la plateforme.

Toute la télémétrie de cette page est uniquement agrégée. Nous ne stockons pas d’identifiants personnels dans les clés de télémétrie.

Métadonnées de vérification

Métadonnées de route

  • Route : /transparency/metrics/
  • Dernière vérification :
  • Prochaine revue :
  • Périmètre de vérification : revue manuelle de l’inventaire actuel des clés métriques et de la politique de rétention.

Limites connues

  • L’inventaire des clés métriques est synchronisé manuellement avec le code ; un outillage automatique de diff est prévu pour les revues trimestrielles.
  • Les valeurs de rétention reflètent les valeurs par défaut actuelles et peuvent ne pas refléter de futurs overrides par tenant.

Ces métadonnées sont mises à jour dans le cadre de la clôture d’audit trimestrielle.

Inventaire des métriques

Catégorie de métrique Données personnelles ? Rétention Objectif
Métriques de cycle de vie de session Non 30 jours brut, 52 semaines rollup, 24 mois mensuel Expérience utilisateur et planification capacité
Métriques de santé Redis Non 24 heures brut, 7 jours horaire, 4 semaines quotidien Fiabilité infrastructure
Agrégats business Non 30 jours quotidien, 52 semaines hebdo, 24 mois mensuel Croissance et planification
Événements télémétrie frontend Non 30 jours Détection erreurs et santé features
Métriques opérations chiffrement Non 30 jours brut, 52 semaines rollup, 24 mois mensuel Fiabilité cryptographique

Métriques de cycle de vie de session Aucune donnée personnelle

Nous comptons les totaux login/logout et les plages de durée de session pour comprendre les usages. Nous ne suivons pas qui s’est connecté.

Quoi : événements login quotidiens, logout et distributions de durée.

Pourquoi : détecter les problèmes d’authentification, réduire la friction et améliorer la planification.

Comment : compteurs quotidiens et buckets fixes.

Rétention : 30 jours brut -> 52 semaines rollup -> 24 mois mensuel -> purge.

Buckets :

  • 0-5min - vérifications rapides
  • 5-30min - session typique
  • 30-60min - session prolongée
  • 60min+ - longue session de travail

Clés d’exemple :

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 : le hash de session est détruit immédiatement après le calcul de durée. Aucun UUID utilisateur dans les clés de télémétrie.

Limite volume : maximum 734 clés/an.

Métriques de santé Redis Aucune donnée personnelle

Nous surveillons Redis comme donnée de santé infrastructure, pas comme donnée d’activité utilisateur.

Quoi : mémoire, nombre de clés par namespace et statistiques de connexion.

Pourquoi : détecter fuites mémoire, prévenir evictions et surveiller croissance.

Comment : parser Redis INFO à intervalle planifié.

Rétention : 24 heures brut -> 7 jours horaire -> 4 semaines quotidien -> purge.

Namespaces : maximum 10 namespaces suivis (allowlist fixe).

  • 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

Clés d’exemple :

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 : les comptes par namespace sont uniquement agrégés. Le contenu des clés n’est pas inspecté.

Limite volume : 1 680 clés maximum dans la fenêtre active.

Métriques agrégées business Aucune donnée personnelle

Ce sont des totaux de plateforme utilisés pour planifier, pas pour profiler des individus.

Quoi : total utilisateurs, comptes actifs, moyenne des work entries.

Pourquoi : planification capacité et analyse de croissance.

Comment : agrégation quotidienne de comptes base de données.

Rétention : 30 jours quotidien -> 52 semaines hebdo -> 24 mois mensuel -> purge.

Clés d’exemple :

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 : valeurs seulement agrégées. Aucun enregistrement télémétrique par utilisateur.

Limite volume : 1 095 clés/an.

Événements télémétrie frontend Aucune donnée personnelle

La télémétrie événementielle aide à détecter les échecs côté client et les problèmes de fiabilité feature.

Quoi : événements performance frontend, compteurs erreurs et événements usage feature.

Pourquoi : identifier problèmes client et surveiller santé produit.

Comment : POST vers /api/telemetry/record uniquement pour types approuvés.

Rétention : 30 jours (TTL appliqué à l’incrément).

Limites de soumission et types d’événement exemple :

  • 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

Clés d’exemple :

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

Privacy Guard : les types sont allowlisted. Pas de chaînes arbitraires ni identifiants utilisateur/session dans les clés.

Limite volume : maximum 18 250 clés/an.

Métriques opérations de chiffrement Aucune donnée personnelle

Les opérations cryptographiques sont surveillées comme signaux de fiabilité plateforme.

Quoi : compteurs succès/échec DEK wrap/unwrap.

Pourquoi : détecter rapidement échecs cryptographiques et mauvaise configuration.

Comment : compteurs succès/échec incrémentés pour chaque résultat.

Rétention : 30 jours brut -> 52 semaines rollup -> 24 mois mensuel -> purge.

Clés d’exemple :

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 : seuls des comptes d’opérations sont enregistrés. Aucun matériau de clé, ciphertext ou identifiant personnel.

Limite volume : 1 460 clés/an.

Pipeline de rétention et compaction

Données brutes : les compteurs quotidiens expirent automatiquement après 30 jours.

Rollups hebdomadaires : agrégation planifiée pour 52 semaines.

Rollups mensuels : agrégation planifiée pour 24 mois.

Purge : métriques de plus de 24 mois supprimées.

Script de compaction : /scripts/compact-metrics.php.

Application dans le code

Les contraintes de confidentialité sont validées par contract tests dans CI.

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

Guardrails : limites namespace/event codées en dur pour empêcher une croissance non bornée.

Rate limits additionnels :

  • Requêtes métriques admin : 100 requêtes/heure
  • Health checks publics : 600 requêtes/heure

Accès et vérification

Dashboard métriques : /admin/metrics (authentification et rôle admin requis).

Endpoint public health : /api/v1/health retourne le statut plateforme agrégé.

Dernière mise à jour : 9 mars 2026.