Scopri quali sessioni
sono andate male, e perché.

No. L'analisi delle sessioni è costruita sullo stesso flusso di eventi di RUM. Se lo script RUM di Site Qwality è già sul sito, l'analisi delle sessioni sta già raccogliendo dati. Non serve alcuno script o configurazione aggiuntiva.

L'analisi delle sessioni mette in evidenza pattern aggregati (conteggi di sessioni, tassi di errore, pagine principali, segnali di frustrazione) su tutte le sessioni. Il session replay permette di guardare una singola sessione come una registrazione video. Entrambi si alimentano degli stessi dati RUM, e puoi passare da una vista aggregata a uno specifico session replay con un clic.

Oggi no. Non esiste un costruttore di funnel, non c'è tracciamento della profondità di scroll, non c'è una metrica di tempo sulla pagina e non c'è un tasso di ritorno: l'SDK non raccoglie i segnali sottostanti, quindi nulla li calcola. Una versione precedente di questa pagina pubblicizzava tutte e quattro le cose, ed era falso. Ciò che esiste è la panoramica aggregata, l'elenco filtrabile delle sessioni, la timeline per sessione e il session replay.

In parte. setUser allega un id utente, un'email e un nome alla sessione, e l'elenco delle sessioni è ricercabile per id o email. Un oggetto di contesto passato ad addError o addAction viene archiviato su quell'evento per 30 giorni, ma nulla nel prodotto lo mostra oggi: nessuna schermata della dashboard e nessuna risposta API lo restituisce, e la timeline della sessione mostra l'evento senza di esso. Non considerarlo una garanzia. Il dato è archiviato, è leggibile da chiunque abbia accesso al database, e una release futura potrebbe esporlo. Anche filtrare o raggruppare le viste aggregate per i tuoi attributi non è disponibile oggi.

Le misure aggregate delle sessioni vengono conservate per 458 giorni, poco più di 15 mesi, su ogni piano incluso quello gratuito. Il dettaglio per sessione (singole azioni, risorse, errori) viene conservato per 30 giorni e i session replay per 30 giorni, di nuovo su ogni piano. Pagare di più non allunga nessuna delle tre. Due delle tre si possono accorciare, una no. Un tetto di conservazione si imposta per singola applicazione RUM tramite le API e limita la finestra di 458 giorni delle misure (settings.retention.observe_days) e quella di 30 giorni del dettaglio per sessione (settings.retention.analyze_days), fino a un minimo di un giorno, e vale sia per i dati già archiviati per quell'applicazione sia per quelli nuovi. Il session replay è l'eccezione. La sua finestra non si può accorciare e una richiesta che ci prova viene rifiutata con un errore che ne spiega il motivo, invece di essere ignorata in silenzio: le registrazioni vengono eliminate da una regola di storage separata che non può seguire un'impostazione per applicazione. Niente di tutto questo è ancora nella dashboard: oggi è una chiamata API.