Una registrazione di sessione è una ricostruzione, non un video
L'equivoco più comune sulla registrazione delle sessioni è che registri lo schermo. Non è così. Una registrazione acquisisce il DOM (la struttura della pagina) più ogni sua modifica, insieme a clic, scroll, eventi di input, tempi di rete ed errori della console. La riproduzione ricostruisce la pagina a partire da questi dati nel tuo browser.
Questa distinzione è il punto centrale. Poiché una registrazione è fatta di dati strutturati e non di pixel, puoi fare ricerche, saltare all'istante esatto in cui è scattato un errore e leggere lo stato del DOM in quel momento. Una registrazione dello schermo non ti offre nulla di tutto questo, e richiede molta più banda per essere raccolta.
Cosa ti dà che uno stack trace non ti dà
Uno strumento di monitoraggio degli errori ti dice che è stato generato un TypeError alla riga 214. Non ti dice che l'utente aveva già inviato il modulo due volte, che il secondo tentativo era su una connessione lenta o che il pulsante è rimasto disattivato dopo. La registrazione fornisce la sequenza di eventi che ha prodotto lo stato su cui il tuo codice si è bloccato.
In pratica, questo comprime la parte più lenta del debug: la riproduzione. Invece di indovinare i passaggi da una segnalazione di una riga, guardi il percorso che l'utente ha seguito davvero.
Come usarla quando arriva un bug
Lavora a ritroso dal guasto invece che in avanti dall'inizio della sessione. Trova l'errore nel tuo monitoraggio, apri la registrazione collegata e salta al timestamp. Poi torna indietro di trenta secondi: la causa è quasi sempre nel mezzo minuto prima del sintomo, non all'inizio della sessione.
Controlla tre cose in ordine: cosa ha cliccato l'utente subito prima, se qualche richiesta è fallita o si è bloccata e se ciò che vedeva sullo schermo corrispondeva a ciò che ti aspettavi venisse renderizzato. La maggior parte dei bug si risolve su una di queste tre.
Cosa non risolverà
La registrazione ti mostra cosa è successo, mai perché la persona l'ha fatto. Se un utente abbandona un modulo, la registrazione ti dice a quale campo si è fermato, ma non può dirti se la domanda era confusa, invadente o semplicemente troppo lunga. Questa risposta arriva chiedendolo direttamente.
È anche poco adatta alle domande aggregate. Una registrazione è un aneddoto. Se devi sapere quanto spesso succede qualcosa, ti serve un funnel o una query sugli eventi; usa le registrazioni per spiegare il calo, non per misurarlo.
Sceglierne una specificamente per il debug
Se il tuo obiettivo è il debug, valuta tre cose prima di tutto il resto. Acquisizione di console e rete: senza di esse stai guardando un film muto. Collegamento tra errori e registrazioni, così un'eccezione ti porta direttamente alla sessione che l'ha prodotta invece che a un elenco in cui cercare. E controlli sulla privacy abbastanza granulari da mantenere utile lo strumento: mascherare ogni input protegge gli utenti ma può nascondere proprio il valore che ha causato il bug, quindi cerca regole per singolo campo invece di un interruttore tutto o niente.