What Digital Experience Analytics Covers That Web Analytics Misses

What is digital experience analytics?

Product and UX teams use digital experience analytics to reconstruct how a single visit actually went, combining session replay, heatmaps, friction detection and journey analysis into one view, instead of counting how many times an event fired. A traffic dashboard reports that 4,000 people reached checkout and 1,200 finished. Digital experience analytics shows the field where the other 2,800 stopped, the button that swallowed their clicks, and the error the browser threw while they waited. The unit of analysis is the visit, not the metric.

One checkout, by the numbers

Reached checkout4,000

Finished checkout1,200

Stopped before finishing2,800

What does the category actually include?

Four capabilities make up the category, and a tool that ships all four covers it end to end. Session replay stores the changes needed to play one visit back in a browser. Heatmaps aggregate clicks, taps and scroll depth from many visits onto a single layout. Friction detection flags rage clicks, dead clicks, errors and abandoned steps without anyone watching a recording first. Journey analysis puts one visitor's pages and events in order, so a team reads the route instead of the destination.

Capability	What it captures	Question it answers
Session replay	DOM changes, input, scroll and pointer events from one visit	What did this person see and do?
Heatmaps	Clicks, taps and scroll depth aggregated across many visits	Where does attention land on this page?
Friction detection	Rage clicks, dead clicks, JavaScript errors, abandoned steps	Which moments went wrong, and for how many people?
Journey analysis	Ordered pages and events for one visitor	Which route led to the drop-off?

Treat the term as that set of capabilities, then check which of the four a given tool ships. A product that records sessions but never flags a struggle moment leaves the reviewing work to you.

How is digital experience analytics different from web analytics and product analytics?

The three answer different questions because they work on different units. Web analytics aggregates traffic into counts and rates for a page or a source. Product analytics aggregates named events into funnels, cohorts and retention curves for a feature. Digital experience analytics keeps the visit intact and reads what happened inside it.

	Unit of analysis	Main artifact	Answers
Web analytics	Page and traffic source	Counts, rates, trends	How many, from where
Product analytics	Named event	Funnels, cohorts, retention	Which step lost people
Digital experience analytics	One visit	Replay, heatmap, friction signal, journey	What went wrong in that step

Use all three together. Web analytics tells you traffic to the pricing page fell, product analytics tells you the fall started at the plan selector, and digital experience analytics shows the selector rejecting a valid input.

How does a tool reconstruct a visit without recording video?

The recorder takes one full snapshot of the page structure, then streams every later change as an incremental event, so playback rebuilds the page instead of playing frames. The open source rrweb project documents this split in its README: the snapshot package converts the DOM and its state into a serializable data structure, and the record package "builds on an initial snapshot to record all HTML state changes (mutations) and user interactions as the user browses the web page."

Those mutations come from a browser API. MDN describes MutationObserver as an interface that provides the ability to watch for changes being made to the DOM tree, covering child node additions and removals, attribute changes, and the whole subtree of a target node. rrweb's observer notes add the rest of the stream: mouse movement and interaction, scrolling, window resize, and input on input, textarea and select elements, including programmatic changes caught by hooking the property setter.

The practical consequence is that a replay is a text event log, not a movie. A machine can read it, search it and summarize it, which is what makes AI session replay possible at all.

How do you measure friction from a set of sessions?

Count the sessions that contain at least one friction signal and divide by all sessions in the window.

friction rate = (sessions with at least one friction signal / total sessions) x 100

Take 12,000 sessions in a week, of which 840 contained a rage click, a dead click or an uncaught JavaScript error:

840 / 12,000 = 0.07, and 0.07 x 100 = 7 percent

A 7 percent friction rate is a starting number, not a finding. Break it down by page, by element and by error message, then rank the groups by how many distinct users hit each one. Two rage clicks on the same button are one bug; two rage clicks on different buttons are two. User friction analysis is the step that turns the rate into a work queue.

What does this change about a bug report?

The report arrives with evidence attached instead of a description written from memory. Flowsery groups matching sessions into a single issue, ranks issues by how many users hit them, and sends each one to Slack, Linear or Jira with the replay and the steps to reproduce. Tag @flowsery in Slack on that issue and it opens a draft pull request in the team's GitHub repository.

That closes the loop the category leaves open. Detection, grouping and ranking are the analytics part; a ticket a developer can act on is the reason anyone runs it.

How do you run it without collecting personal data?

Mask the fields before the data leaves the browser, and drop the identifiers you never needed. Session replay privacy masking replaces the contents of inputs and marked elements with placeholder characters at record time, so the values never reach the server. Flowsery is cookie-free, EU-hosted and GDPR by design, runs from one script under 10 KB, and applies no data sampling, so the friction numbers above come from every session instead of a subset.

Decide the masking rules before you turn recording on. A rule added after the fact does not clean the recordings you already stored.

Frequently Asked Questions

Is digital experience analytics the same as session replay?

No. Session replay is one of the four capabilities in the category, alongside heatmaps, friction detection and journey analysis. A tool can record sessions without detecting a single struggle moment, which leaves you watching recordings by hand. The category is the combination, not the recorder.

Do you still need web analytics alongside digital experience analytics?

Yes, because the two work at different scales. Web analytics answers how many people arrived and from where, across the whole site, in aggregate. Digital experience analytics answers what happened inside one of those visits. Flowsery ships both, with real-time traffic, funnels, goals and revenue by source next to the replays.

Which team owns digital experience analytics?

Product, design and engineering all read it, and the owner is whoever fixes what it finds. Designers use heatmaps and journeys to judge a layout. Engineers use replays and error signals to reproduce a defect. Give one person the job of triaging the ranked issue list each week, or the queue grows and nobody clears it.

How many sessions does a friction rate need to be readable?

The rate is a fraction, so a small denominator makes it jump. Compute it per page and per step instead of for the whole site, and read the count of affected users next to the percentage. A step with 9 percent friction across 40 sessions is a weaker signal than a step with 4 percent across 6,000.

Can digital experience analytics run without cookies?

Yes. Recording a visit needs a way to tie events to one session, and that identifier does not have to be a cookie stored across visits. Flowsery is cookie-free and EU-hosted, and its plan limits are quota-based across analytics sessions, recordings and retention.

Does it require new tracking code on every page?

Flowsery installs as one script under 10 KB. If a team already records sessions in PostHog or Amplitude, Flowsery connects to those existing replays with no re-instrumentation, so the analysis runs against recordings the team already has.

How does digital experience analytics explain a checkout drop-off?

A traffic dashboard might show 4,000 shoppers reaching checkout and 1,200 finishing, without saying why 2,800 left partway through. Digital experience analytics reads those same sessions and points to the field where they stopped, the button that swallowed clicks, or the error the browser threw while they waited. The explanation comes from the visit itself, not from a separate metric layer.

What happens after Flowsery groups sessions into an issue?

Flowsery groups matching sessions into a single issue, ranks issues by how many users hit them, and sends each one to Slack, Linear or Jira with the replay and the steps to reproduce attached. Tagging @flowsery in Slack on that issue opens a draft pull request in the team's GitHub repository. The report arrives with evidence attached instead of a description written from memory.

How is a session replay built from mutations different from a video recording?

The recorder takes one full snapshot of the page structure, then streams every later change as an incremental event, the same split rrweb documents in its README. A replay built this way is a text event log, not a movie, so a machine can read it, search it and summarize it. That's what makes AI session replay possible at all.

Why mask fields before the data leaves the browser?

Session replay privacy masking replaces the contents of inputs and marked elements with placeholder characters at record time, so the values never reach the server. Masking rules need to be set before recording starts, because a rule added afterward doesn't clean recordings already stored. Flowsery pairs this with being cookie-free, EU-hosted and GDPR by design.