En replay är en rekonstruktion, inte en video
Det vanligaste missförståndet om session replay är att det spelar in skärmen. Det gör det inte. En replay fångar DOM – sidans struktur – plus varje förändring av den, tillsammans med klick, scrollningar, input-event, nätverkstider och konsolfel. Uppspelningen bygger upp sidan igen från de data i din webbläsare.
Den skillnaden är hela poängen. Eftersom en replay är strukturerade data i stället för pixlar kan du söka i den, hoppa till exakt det ögonblick då ett fel utlöstes och läsa av DOM-tillståndet i just den sekunden. En skärminspelning ger dig inget av det, och kostar långt mer bandbredd att samla in.
Vad den ger dig som en stack trace inte gör
En felövervakare talar om att ett TypeError kastades på rad 214. Den talar inte om att användaren redan hade skickat formuläret två gånger, att andra försöket skedde på en långsam uppkoppling, eller att knappen förblev inaktiverad efteråt. Replay ger dig händelseförloppet som skapade det tillstånd din kod satte i halsen.
I praktiken kortar det ner den långsammaste delen av felsökning: att återskapa felet. I stället för att gissa sig till stegen utifrån en enradig buggrapport ser du vägen användaren faktiskt tog.
Så använder du den när en bugg kommer in
Arbeta bakåt från felet i stället för framåt från sessionens början. Hitta felet i din övervakning, öppna den länkade replayen och hoppa till tidsstämpeln. Spola sedan bakåt trettio sekunder – orsaken finns nästan alltid i halvminuten före symtomet, inte i början av sessionen.
Kontrollera tre saker i ordning: vad användaren klickade på omedelbart innan, om någon förfrågan misslyckades eller hängde sig, och om det som syntes på skärmen stämde med det du förväntade dig skulle renderas. De flesta buggar löser sig på någon av de tre.
Vad den inte löser
Replay visar dig vad som hände, aldrig varför personen gjorde det. Om en användare överger ett formulär talar inspelningen om vilket fält de stannade vid – den kan inte tala om ifall frågan var förvirrande, närgången eller helt enkelt för lång. Det svaret får du genom att fråga dem.
Den är också dålig på aggregerade frågor. En inspelning är en anekdot. Behöver du veta hur ofta något händer är det en tratt eller en event-fråga; använd replay för att förklara tappet, inte för att mäta det.
Att välja ett verktyg specifikt för felsökning
Om felsökning är uppgiften väger du tre saker tyngre än allt annat. Insamling av konsol och nätverk – utan dem tittar du på en stumfilm. Länkning från fel till replay, så att ett undantag tar dig direkt till sessionen som orsakade det i stället för till en lista att söka i. Och integritetskontroller som är tillräckligt finkorniga för att verktyget ska förbli användbart: att maskera varje inmatning skyddar användarna men kan dölja precis det värde som utlöste buggen, så leta efter regler på fältnivå snarare än en allt-eller-inget-brytare.