Session replay helps answer a question that an error counter often leaves open: what was the visitor doing when the application failed? The useful result is a testable sequence of events, linked to server evidence and a reproducible failure. BEA and TeaLeaf’s early application-management story provides context for that diagnostic approach.
From WebLogic integration to experience investigation
The March 2002 BEA–TeaLeaf announcement concerned TeaLeaf IntegriTea and BEA WebLogic. Its central idea was to reconstruct an individual web experience so application teams could investigate a reported problem. That historical product context belongs to its era; the workflow below uses present-day documentation and an invented incident.
IBM announced completion of its Tealeaf acquisition on June 13, 2012. IBM’s 2020 annual report (PDF) records the 2019 divestiture of selected marketing platform and commerce software offerings and the Acoustic rebranding. For implementation details, consult the documentation for the installed product and SDK version.
Acoustic’s session replay guide describes replay, timeline and raw-data views. It also distinguishes browser event timestamps from collector timestamps. That matters when aligning an interaction with a server log: record the timezone, clock source and correlation identifier before concluding that two entries refer to the same request.
Give each evidence source a specific job
On narrow screens, scroll the table horizontally. Keyboard users can focus it and use the arrow keys.
| Source | Useful question | Limit to account for |
|---|---|---|
| Replay | Which page, control and sequence preceded the problem? | Masked values, unsupported elements or missing events can leave gaps. |
| Browser diagnostics | Did a request start, fail or trigger an exception? | The captured session may omit network bodies or console events. |
| Server logs and traces | Which request reached which service, and what happened? | A successful response does not establish that the UI displayed it correctly. |
| Database or business record | Was the intended operation committed? | Use approved read access and stable identifiers; avoid assuming a click equals a transaction. |
Treat a blank replay area as missing evidence until you have checked the capture configuration. Avoid inferring what a visitor typed from an intentionally masked field. For server-side investigation, continue with Java metrics and traces or the slow-application diagnostic workflow.
Follow a failed checkout from observation to test
Fictional incident: an address update leaves checkout waiting
On narrow screens, scroll the table horizontally. Keyboard users can focus it and use the arrow keys.
| Time | Observation | Next inference or check |
|---|---|---|
| 14:02:10 | Visitor selects a saved address. | Record page version and the synthetic session ID S-17. |
| 14:02:11 | Browser sends address request R-42. | Find the same request ID in approved server logs. |
| 14:02:11 | Server returns success; no order request follows. | Investigate client handling before blaming the order database. |
| 14:02:12 | Browser diagnostic event records a missing-field exception. | Reproduce with the same response shape in a test account. |
| 14:02:15 | Replay shows the spinner still visible. | Check the UI state transition and error recovery. |
The working hypothesis is a client response-handling defect. The server’s success status alone cannot validate the response contract. A test fixture with the missing field reproduces the spinner, while a complete response allows progress. After fixing validation and the recovery message, rerun both fixtures and verify the expected UI states.
Confirm the business record before asking the user to retry a consequential action. This example has no order request; a timeout after an order commit would require a different recovery decision. The timeline illustrates reasoning, not measurements from a real deployment.
Verify capture controls before production use
Acoustic’s Web SDK privacy guidance distinguishes protection for user input from masking page content. It describes masking content before a DOM snapshot is sent to its cloud servers. Configure the applicable mechanisms for your SDK and test the transmitted data as well as the replay display.
- Map sensitive locations: inputs, rendered account details, error messages, URL parameters and dynamically added content. Decide what to omit and what sanitized events are sufficient.
- Use synthetic test values. Exercise typing, paste, validation errors, page changes and newly rendered components.
- Inspect an authorized test capture at the collection boundary and in replay. Verify that disallowed values are absent in both, including after UI updates.
- Limit replay access and retention to the investigation’s needs. Record the product version and repeat the test when capture rules or page structure change.
Keep the investigation record small: symptom, release, sanitized session/request identifiers, clock assumptions, corroborating evidence, hypothesis and verification result. Download a session-replay investigation worksheet. A useful incident report explains both what the evidence establishes and which step still needs reproduction.