Session replay for ecommerce: finding the bugs your dashboards can't see

Dashboards tell you that conversion dropped on a page; they rarely tell you why. Session replay records real user sessions so you can watch the failure happen — the mis-tapped filter, the button that does nothing, the checkout that spins forever. Done carelessly it is a privacy incident and a storage bill in equal measure. Here is how we run replay that earns its keep: consent-gated capture, friction scoring to surface the few sessions worth watching, joins back to orders and analytics, and the specific class of bug it catches that no error tracker ever will.

What replay shows that dashboards can't

Aggregate analytics are a summary; they smooth away the individual disaster. A funnel report tells you 8% of carts never reach payment, but it cannot tell you that a particular filter chip on mobile silently reloads the page and dumps the basket. Error trackers are worse for this than people expect: they only see failures that throw. The most expensive ecommerce bugs are the ones where every request returns 200, no exception is logged, and the experience is still broken — a layout that pushes the buy button off-screen, an autocomplete that never populates, a spinner with no timeout. Replay is the only tool that shows you the thing the user actually saw.

Consent-gated capture and privacy engineering

Replay records the DOM, which means it can accidentally record everything a user types — names, addresses, card fields. Treat it as personal-data processing from the first line of code, not as an afterthought. Three controls are non-negotiable: capture only after the analytics consent category is granted (strictly-necessary consent is not enough for behavioural recording); mask inputs by default and block sensitive fields at the recorder, so the raw keystrokes never leave the browser; and set a short retention window with automatic deletion. We go deeper on the classification and consent-state plumbing in GDPR and ePrivacy for ecommerce analytics, but the one-line rule is: if you would not put it in a log file in plaintext, do not let the recorder see it either.

Friction scoring: ranking the sessions worth watching

Nobody watches ten thousand sessions. Replay only works at scale if a machine ranks recordings so a human watches the worst twenty, not a random twenty. Friction scoring assigns each session a number from cheap, well-understood signals: rage clicks (rapid repeated taps on the same element), dead ends (navigations that immediately reverse), thrash (back-and-forth between two views), form abandonment after repeated edits, and long unexplained idle gaps mid-checkout. Sort the queue by score, watch from the top, and you spend your attention where the pain is concentrated. The score is not a diagnosis — it is a triage. Its job is to make the review queue finite.

Keep the signals dumb and transparent on purpose. A friction score you can explain in a sentence is one a reviewer trusts and can argue with; a black-box "quality" number is one everyone quietly ignores after the first misfire. It is also worth weighting the queue toward money — a high-friction session that reached checkout is worth more of your attention than one that bounced from a blog post — so the sessions you watch are the ones where a fix converts. Over a few weeks the queue teaches you your own site's recurring failure shapes, and the same signatures start jumping out in aggregate before you even open a recording.

The 200-OK bug replay was built to catch

That bug is the archetype. It sat below every alerting threshold, produced no stack trace, and was only legible as a story — one user, one broken screen, played back frame by frame. Every store has a few of these hiding in the gap between "the server responded 200" and "the customer could actually buy". Replay is how you find them before a support ticket does.

Joining replay to orders and analytics

A recording in isolation is an anecdote. A recording you can pivot to and from your other data is evidence. The high-leverage move is stamping a stable session identifier onto both the recording and your first-party events, and carrying the order identifier through so you can jump from a failed checkout row straight to the video of it failing. "Why did this order stall at payment" becomes a two-click question instead of a forensic project. That join is the same backbone that powers true attribution, which we lay out in the ecommerce analytics stack — replay is one more consumer of the session-to-order spine. It also closes the loop with site-search analytics: a spike in zero-result queries plus the replays behind them tells you whether the catalog is missing the product or the search is missing the synonym.

Masking, retention and the cost of keeping it honest

Replay storage grows quietly and consent makes it lumpy, so budget for both. Record a sampled fraction of sessions plus an oversample of the ones that look painful, rather than everything. Keep raw recordings for a short window and let the derived friction scores and notes outlive them — you rarely re-watch a month-old session, but you often want the trend. And keep the recorder cheap on the page: load it after consent, lazily, so it never blocks the first paint of a product page. Treated this way, replay is not a surveillance apparatus; it is a debugger that happens to work in the past tense, and the discipline that keeps it lawful also keeps it affordable. The broader monitoring-cost mindset behind that lives in our piece on ecommerce observability.

Frequently asked questions