Digital experience analytics: session-replay summaries & UX friction detection

Product teams cannot watch thousands of session recordings or read every heatmap. Digital experience analytics (DXA) tools capture how visitors interact with a site or app, use sequence mining and anomaly detection to find friction (rage clicks, error loops, abandoned forms), and use LLMs to summarise sessions and answer questions in plain language. The result is a ranked list of fixes with estimated impact. Because the raw data is behavioural and often personal, consent-gated capture and masking are part of the design, not an add-on.

Problem & value

• Today: analysts sample a few recordings, look at funnels in a web-analytics tool and guess why visitors leave. Developers learn about UX bugs from support tickets. Prioritisation relies on opinion.
• AI value: (1) summarise many sessions or a single long replay into a few sentences, (2) detect and cluster friction automatically, (3) tie each issue to conversion or revenue so the backlog can be ranked, (4) let non-analysts ask "why did checkout completion drop on mobile last week?".
• Evidence: vendors document these features (Contentsquare Sense/AI features, FullStory, Hotjar AI, Microsoft Clarity Copilot, PostHog) [1][2][3]. Independent, peer-reviewed uplift figures are scarce; treat vendor ROI claims as marketing and measure your own baseline.
• Not covered here: warehouse NL-to-SQL (DATA-001), A/B testing (DATA-027), KPI anomaly alerts, system telemetry (CODE-010) and free-text feedback (LANG-013).

Variants

• E-commerce / SMB shop: checkout, search and filter friction; mobile vs desktop; payment-form errors.
• SaaS product teams: onboarding drop-off, feature discoverability, in-app journeys (mobile SDKs).
• Banking / insurance / public portals: form-heavy journeys with strict masking; replay often limited to non-sensitive pages.
• Accessibility focus: friction patterns for keyboard and screen-reader users (link to EAA/BITV work, DOC-026).
• Support-assist: agent opens the customer's replay to see what went wrong (needs a lawful basis and strict access control).

How it works

1. consent management platform (CMP)
2. tag/SDK loads only after consent (or consent-free, cookieless mode)
3. capture: events + DOM mutations, client-side masking of inputs/text/regions
4. ingest (EU region)
5. sessionisation, friction rules (rage/dead clicks, error loops, u-turns)
6. sequence/journey mining + clustering of similar sessions (embeddings)
7. LLM layer: summarise a session or cluster from structured event text (not raw PII), name the issue
8. impact model: affected sessions × conversion gap × value per session
9. prioritised issue list
10. ticket (Jira/Linear) with replay link
11. fix
12. monitor

• Friction detection is mostly deterministic rules plus statistical anomaly detection; the LLM is best used on a textualised event stream ("clicked 'Pay' 5 times in 3 s; console error 502") rather than on pixels.
• Impact estimation is a regression/cohort comparison, not a causal proof. Validate important fixes with an experiment (DATA-027).
• Conversational layer: LLM with tool access to the metrics store (cf. DATA-001) and links to evidence sessions.
• Human-in-the-loop: product/UX owners confirm issue clusters, check evidence replays and decide priorities; nobody should act on an LLM summary alone.

Data preparation

Data is mostly generated new by an SDK or tag, so there is little legacy to clean. Relevant sources are the web shop or app (event stream, DOM recording), the consent management platform, the CRM or shop backend (orders, customer segments) and the ticketing system (Jira, Linear). Typical gaps: inconsistent event names, no tracking plan, missing consent state, forms and text fields not masked, bot and internal traffic mixed in, and orders not joinable with sessions because IDs differ.

Preparation steps: 1. Write a tracking plan with event names and owners (PREP-012 for shared KPI definitions). 2. Configure the CMP and mask all inputs and sensitive regions client-side by default (PREP-022, PREP-025 for purpose and legal basis). 3. Filter bots and staff IPs; join orders with session IDs via a stable key (PREP-005). 4. Define a category scheme for friction types and severity (PREP-019). 5. Textualise sessions for the LLM instead of sending raw pixels or DOM.

Tools: tag manager, the analytics product's own configuration, SQL/dbt. Effort is low, roughly 10-20% of the project, concentrated in tracking plan and masking review. See also GUIDE-003.

Implementation paths

Which path for whom

• SMB (A): Mature EU-hosted products with default masking and consent support exist at SMB prices (Matomo, Mouseflow, Smartlook, Contentsquare/Hotjar) and the process is standard.
• Enterprise (B): The web or app experience is a core product asset, replay volumes are high and an event pipeline and warehouse exist, so custom LLM analysis on top of owned data pays off.
• Developer (C): OpenReplay, PostHog or rrweb with ClickHouse keep recordings on your own infrastructure and avoid per-session fees.

Path A — Buy (recommended for most)

• Platforms: Contentsquare (FR, EU vendor; AI features such as Sense and an assistant), FullStory (US; StoryAI), Hotjar (owned by Contentsquare, MT-based; AI summaries), Microsoft Clarity (free; Copilot summaries), PostHog (US-founded, EU cloud and self-host option; session replay and AI assistant), Heap, Mouseflow (DK, EU), Smartlook (CZ, EU), Matomo (NZ-founded, EU/self-hosted; session recording plugin), LogRocket (more developer-oriented).
• Check: EU hosting and subprocessors, default masking, consent-mode support, replay retention, role-based access, DPA, whether AI features send data to a third-party LLM and where.
• Choose A when: a team of 1–20 with a standard web shop or SaaS and no restriction on third-party SDKs.

Path B — Build on cloud APIs

• Capture with open-source rrweb or a vendor SDK, store events in an EU warehouse (BigQuery EU, Snowflake, ClickHouse Cloud EU).
• Textualise sessions and call an EU-region LLM endpoint (Mistral, Azure OpenAI EU, Claude on EU-region cloud, Gemini EU) with structured outputs for "issue / evidence / severity". Embeddings for clustering similar sessions.
• Add a conversational BI layer (DATA-001) over the event tables. Sensible when you already have an event pipeline.

Path C — Self-host (open source)

• Capture and replay: rrweb, PostHog (self-hosted), OpenReplay (EU-based, self-hosted), Matomo with the session-recording plugin.
• Storage/analytics: ClickHouse or PostgreSQL; Apache Superset or Metabase for dashboards.
• LLM: open-weight models of ≈8–30B (e.g. Qwen3, Llama, Mistral Small, Gemma) via vLLM or Ollama for summaries; bge-m3 or multilingual-e5 for embeddings. Summaries of textualised events run comfortably on HW2.
• Choose C when: data must not leave your infrastructure (public sector, banking) or replay volume makes SaaS pricing painful.

Path D — Custom training

Rarely needed. A small classifier for "frustrated session" or a sequence model for drop-off prediction can be trained on your own labelled sessions (a few thousand), mainly to cut LLM cost or tune to a niche product.

State of the art (2026)

• LLM session summaries and "ask your data" assistants are now standard in the major DXA suites; the differentiator is linking each insight to verifiable evidence sessions and to revenue impact.
• Cookieless and consent-aware modes plus aggressive default masking (mask all text and inputs, allow-list instead of block-list) are the norm in EU deployments.
• Agentic patterns appear: an agent watches friction clusters, opens a ticket and drafts a fix suggestion for developers; quality is uneven.
• Limits and failure modes: summaries can invent motives ("user was confused") that the data cannot show; rage clicks can be false positives (e.g. slow pages, carousels); SPAs and shadow DOM break replay; bots inflate friction; low-traffic pages give no statistical power; impact estimates are correlational; summarising unmasked replays with an external LLM leaks personal data. Do not infer emotions of individuals from behaviour for decision-making (see Risks).

Shared resources & combinations

• Event pipeline and warehouse shared with DATA-001 (NL-to-SQL), DATA-002 (reporting narratives) and DATA-027 (experiments).
• LLM summarisation stack (llm-general + embeddings + clustering) shared with LANG-013 (feedback analysis): combine "what users did" with "what users said" to explain friction.
• Process-mining ideas shared with DATA-013 (journey = process variant analysis).
• Front-end error and performance data overlaps with CODE-010 (AIOps); link errors to affected sessions.
• Hardware: one HW2 GPU can serve summarisation for multiple analytics use cases.

Effort, cost & KPIs

• Path A: days to a few weeks (tag deployment, consent integration, masking review). Pricing is typically by sessions per month; replay volume drives cost.
• Path B: 1–3 months for capture-to-insight pipeline; cost driven by event storage and LLM tokens (summarise clusters, not every session).
• Path C: 2–4 months plus ongoing operations of capture, storage and GPU.
• KPIs: time from issue appearing to detection; share of top issues fixed per quarter; conversion/completion rate on fixed journeys (validated via experiments); rage-click rate per 1,000 sessions; analyst hours spent reviewing recordings; summary accuracy spot-checked against replays; masking-coverage audit results.

People & change

Start with the product or e-commerce lead (process owner) and management for scope and budget; involve IT for the tag and CSP changes, and the data protection officer early. Session replay processes personal data of website visitors, so consent (TTDSG/TDDDG and GDPR), masking, retention limits and an AVV with the vendor are required, and a DPIA is advisable at scale (GUIDE-005). Works council: depends. For a public web shop it is usually not involved, but if staff use recorded internal tools, portals or intranet apps, or if analysts' tool usage is logged, §87(1) no. 6 BetrVG applies and a works agreement should limit replay of employee sessions; inform the council in good time under §90(1) no. 3 (GUIDE-004).

AI literacy: support the UX and marketing team with short training on reading LLM summaries critically and on privacy-safe use (GUIDE-006, AI Act Art. 4). Communicate which pages are recorded and why in the privacy notice. Choose a pilot on one funnel (e.g. checkout), with two or three users. Typical concern: "we are watching customers". Address it with masking, no replay of identified individuals, short retention, and a rule that replays are viewed for friction, never to profile people. Keep humans in control: nobody ships a change on an LLM summary alone; they check the evidence session first (GUIDE-009).

Risks, regulation & compliance

• EU AI Act: typically minimal risk — product analytics, no Annex III use. Boundary: if tools infer emotions of natural persons from behaviour in workplace or education settings, Art. 5(1)(f) prohibits emotion-recognition systems there (biometric-based; behavioural-only inference is a grey area, avoid it). Do not use sessions for profiling that drives pricing or access to credit/employment. AI literacy (Art. 4) applies to the team [4].
• ePrivacy / TTDSG: storing or reading information on the user's device (cookies, SDK identifiers, local storage) needs consent under Art. 5(3) ePrivacy Directive, in Germany §25 TDDDG (formerly TTDSG), unless strictly necessary. Session replay is generally not considered strictly necessary; the EDPB guidelines 2/2023 on technical scope of Art. 5(3) also cover tracking techniques beyond cookies [5]. CNIL allows a narrow audience-measurement exemption, which does not extend to replay [6].
• GDPR: replays can capture names, addresses, health or payment data typed into forms; data minimisation, masking by default, short retention, DPIA (Art. 35) for large-scale replay, DPA with vendor, transfer assessment for non-EU vendors, access control and audit logging for replay viewing. Sending replay-derived text to an LLM provider is a further processing step to document.
• Security: replay scripts are a supply-chain risk; masking failures expose credentials. Never record password, payment and special-category fields.
• Mitigations: consent gating, allow-list masking, exclude sensitive pages, EU hosting, retention ≤ weeks, no fingerprinting, human review of AI conclusions, regular masking audits.

Getting started

1. Define 2–3 critical journeys (e.g. checkout, sign-up) and baseline conversion and error rates in your existing analytics.
2. Fix the consent layer first: CMP, consent-gated loading, and a documented lawful basis; run a DPIA if replay is broad.
3. Pilot one Path A tool (EU hosting, mask-all default) on those journeys for 4 weeks; verify masking by reviewing sample replays.
4. Take the top 5 AI-surfaced issues, verify each in raw sessions, fix, and measure (ideally via an A/B test, DATA-027).
5. Add a weekly review ritual and track the KPIs; only then consider Path B/C for custom summaries.

Sources

1. Contentsquare — product and AI features — https://contentsquare.com/
2. Microsoft Clarity documentation (session recordings, Copilot summaries) — https://learn.microsoft.com/clarity/
3. PostHog — session replay docs (privacy controls, masking) — https://posthog.com/docs/session-replay
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. EDPB — Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive — https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2023/guidelines-22023-technical-scope-art-53-eprivacy_en
6. CNIL — Audience measurement tools exempt from consent — https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications
7. rrweb — open-source web session recording — https://github.com/rrweb-io/rrweb
8. OpenReplay — open-source session replay — https://github.com/openreplay/openreplay