Een replay is een reconstructie, geen video
De meest voorkomende misvatting over session replay is dat het het scherm opneemt. Dat doet het niet. Een replay legt de DOM vast — de structuur van de pagina — plus elke wijziging daarin, samen met klikken, scrollbewegingen, invoerevents, netwerktimings en consolefouten. Bij het afspelen wordt de pagina uit die data opnieuw opgebouwd in je browser.
Dat onderscheid is precies waar het om draait. Omdat een replay gestructureerde data is en geen pixels, kun je erin zoeken, naar het exacte moment springen waarop een fout optrad, en de staat van de DOM op dat moment uitlezen. Een schermopname geeft je daar niets van, en kost bovendien veel meer bandbreedte om te verzamelen.
Wat het je geeft en een stack trace niet
Een errortracker vertelt je dat er een TypeError is opgetreden op regel 214. Hij vertelt je niet dat de gebruiker het formulier al twee keer had verstuurd, dat de tweede poging over een trage verbinding ging, of dat de knop daarna uitgeschakeld bleef. Replay levert de reeks gebeurtenissen die de toestand veroorzaakte waarop je code vastliep.
In de praktijk laat dat het traagste deel van debuggen wegvallen: reproduceren. In plaats van de stappen te raden uit een bugmelding van één regel, kijk je naar het pad dat de gebruiker echt aflegde.
Hoe je het gebruikt als er een bug binnenkomt
Werk terug vanaf de fout in plaats van vooruit vanaf het begin van de sessie. Zoek de fout op in je monitoring, open de gekoppelde replay en spring naar het tijdstip. Spoel vervolgens terug in de tijd, zo'n dertig seconden — de oorzaak zit bijna altijd in de halve minuut vóór het symptoom, niet aan het begin van de sessie.
Controleer drie dingen op volgorde: waar de gebruiker vlak daarvoor op klikte, of er een verzoek mislukte of bleef hangen, en of wat er op het scherm stond overeenkwam met wat jij verwachtte te renderen. De meeste bugs zijn met één van die drie opgelost.
Wat het niet oplost
Replay laat je zien wat er gebeurde, nooit waarom iemand het deed. Als een gebruiker een formulier afbreekt, vertelt de opname je bij welk veld hij stopte — maar niet of de vraag verwarrend, opdringerig of gewoon te lang was. Dat antwoord krijg je door het te vragen.
Het is ook slecht in vragen over grotere aantallen. Eén opname is een anekdote. Als je moet weten hoe vaak iets gebeurt, is dat een funnel of een eventquery; gebruik replay om de uitval te verklaren, niet om die te meten.
Specifiek kiezen voor debuggen
Als debuggen de klus is, weeg dan drie dingen zwaarder dan al het andere. Console- en netwerkregistratie — zonder die twee kijk je naar een stomme film. Koppeling van fout naar replay, zodat een exception je rechtstreeks naar de sessie brengt die hem veroorzaakte in plaats van naar een lijst om te doorzoeken. En privacyinstellingen die fijnmazig genoeg zijn om de tool bruikbaar te houden: elke invoer maskeren beschermt gebruikers, maar kan precies de waarde verbergen die de bug veroorzaakte, dus zoek naar regels op veldniveau in plaats van een alles-of-nietsschakelaar.