PayCal Technologies Inc.

Trasparenza metriche piattaforma

Questa pagina mostra quale telemetria raccoglie PayCal, perché la raccogliamo e quando viene eliminata.

Pubblicato:

Il nostro impegno

Gli utenti dovrebbero poter vedere esattamente quale telemetria raccoglie un servizio. Questa pagina documenta ogni metrica usata per monitorare la salute della piattaforma.

Tutta la telemetria in questa pagina è solo aggregata. Non memorizziamo identificatori personali nelle chiavi di telemetria.

Metadati di verifica

Metadati route

  • Route: /transparency/metrics/
  • Ultima verifica:
  • Prossima review:
  • Ambito verifica: review manuale rispetto all’inventario attuale delle chiavi metriche e alla policy di conservazione.

Limitazioni note

  • L’inventario delle chiavi metriche è tenuto manualmente sincronizzato con il codice; tooling automatico key-diff è pianificato per review trimestrali.
  • I valori di conservazione riflettono la configurazione predefinita attuale e potrebbero non riflettere futuri override tenant-specific.

Questi metadati sono aggiornati come parte della chiusura audit trimestrale.

Inventario metriche

Categoria metrica Dati personali? Conservazione Scopo
Metriche ciclo sessione No 30 giorni raw, 52 settimane rollup, 24 mesi mensile Esperienza utente e capacity planning
Metriche salute Redis No 24 ore raw, 7 giorni orario, 4 settimane giornaliero Affidabilità infrastruttura
Aggregati business No 30 giorni giornaliero, 52 settimane settimanale, 24 mesi mensile Crescita e planning
Eventi telemetria frontend No 30 giorni Rilevamento errori e salute feature
Metriche operazioni cifratura No 30 giorni raw, 52 settimane rollup, 24 mesi mensile Affidabilità crittografica

Metriche ciclo sessione Nessun dato personale

Contiamo totali login/logout e range durata sessione per capire pattern d’uso. Non tracciamo chi ha effettuato il login.

Cosa: eventi login giornalieri, logout e distribuzioni durata sessione.

Perché: rilevare problemi autenticazione, ridurre attrito e migliorare capacity planning.

Come: contatori giornalieri e bucket durata fissi.

Conservazione: 30 giorni raw -> 52 settimane rollup -> 24 mesi mensile -> purge.

Bucket:

  • 0-5min - controlli rapidi
  • 5-30min - sessione tipica
  • 30-60min - sessione estesa
  • 60min+ - lunga sessione di lavoro

Chiavi esempio:

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: l’hash sessione viene distrutto subito dopo il calcolo durata. Nessun UUID utente nelle chiavi telemetria.

Limite volume: massimo 734 chiavi/anno.

Metriche salute Redis Nessun dato personale

Monitoriamo Redis come dati di salute infrastruttura, non come attività utente.

Cosa: uso memoria, conteggi chiavi per namespace e statistiche connessione.

Perché: rilevare memory leak, prevenire evictions e osservare crescita.

Come: parse di Redis INFO a intervallo pianificato.

Conservazione: 24 ore raw -> 7 giorni orario -> 4 settimane giornaliero -> purge.

Namespace: massimo 10 namespace tracciati (allowlist hardcoded).

  • 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

Chiavi esempio:

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: i conteggi namespace sono solo aggregati. Il contenuto delle chiavi non viene ispezionato.

Limite volume: massimo 1.680 chiavi nella finestra attiva.

Metriche aggregate business Nessun dato personale

Sono totali di piattaforma usati per pianificazione, non per profilare individui.

Cosa: utenti totali, account attivi, media work entries.

Perché: capacity planning e analisi crescita.

Come: aggregazione giornaliera di conteggi database.

Conservazione: 30 giorni giornaliero -> 52 settimane settimanale -> 24 mesi mensile -> purge.

Chiavi esempio:

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: solo valori aggregati. Nessun record telemetria per utente.

Limite volume: 1.095 chiavi/anno.

Eventi telemetria frontend Nessun dato personale

La telemetria eventi aiuta a rilevare errori client-side e problemi affidabilità feature.

Cosa: eventi performance frontend, conteggi errori e eventi uso feature.

Perché: identificare problemi client e monitorare salute prodotto.

Come: POST a /api/telemetry/record solo per tipi evento approvati.

Conservazione: 30 giorni (TTL applicato su incremento).

Limiti invio e tipi evento esempio:

  • 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

Chiavi esempio:

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

Privacy Guard: i tipi evento sono allowlisted. Nessuna stringa arbitraria o identificatore utente/sessione nelle chiavi.

Limite volume: massimo 18.250 chiavi/anno.

Metriche operazioni cifratura Nessun dato personale

Le operazioni crittografiche sono monitorate come segnali affidabilità piattaforma.

Cosa: contatori successo/fallimento DEK wrap/unwrap.

Perché: rilevare rapidamente errori crittografici e misconfigurazioni.

Come: contatori successo/fallimento incrementati per ogni risultato operazione.

Conservazione: 30 giorni raw -> 52 settimane rollup -> 24 mesi mensile -> purge.

Chiavi esempio:

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: sono registrati solo conteggi operazione. Nessun materiale chiave, ciphertext o identificatore personale.

Limite volume: 1.460 chiavi/anno.

Pipeline conservazione e compattazione

Dati raw: i contatori giornalieri scadono automaticamente dopo 30 giorni.

Rollup settimanali: aggregazione pianificata per conservazione 52 settimane.

Rollup mensili: aggregazione pianificata per conservazione 24 mesi.

Purge: metriche oltre 24 mesi eliminate.

Script compattazione: /scripts/compact-metrics.php.

Enforcement nel codice

I vincoli privacy sono validati da contract test in CI.

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

Guardrails: limiti namespace/event hardcoded impediscono crescita non limitata delle metriche.

Rate limit aggiuntivi:

  • Query metriche admin: 100 richieste/ora
  • Health check pubblici: 600 richieste/ora

Accesso e verifica

Dashboard metriche: /admin/metrics (richiede autenticazione e ruolo admin).

Endpoint health pubblico: /api/v1/health restituisce stato piattaforma aggregato.

Ultimo aggiornamento: 9 marzo 2026.