This topic explains how to use LaunchDarkly’s observability features to perform session replays. The Sessions view displays a list of recorded sessions. Use this view to perform session replays, which are repeatable explorations of an end user’s session in your application. You can visually replay each recorded session to watch and play back how users interact with a website, digital product, or mobile app. Session replays give your organization visibility into how customers use your application, and can provide insight into why errors occur.
To instrument your application to capture session replay, read the documentation on Observability SDKs. The functionality is available through plugins to the LaunchDarkly JavaScript SDK.
LaunchDarkly supports both Shadow DOM and Web Components as part of this instrumentation.
To view a replay:
Use the buttons in the lower right corner to toggle these views:
>_): Shows or hides the Dev Tools panel.
To learn more about the search capabilities, read Search specification.
When you search on the Sessions page, the following behaviors apply by default:
completed=true. You can use completed=false to find live sessions and sessions that are not yet fully processed.email, device_id, or given identifier, as well as their city or country. For example, if you enter an expression without a key, such as search-term, then LaunchDarkly automatically expands that to email=*search-term* OR city=*search-term*.Additionally, by default, the session replay SDK plugin automatically injects several attributes to provide additional help with searching for sessions. To learn more, read Search attributes.
When you search on the Sessions page, you can search for sessions where an end user clicked a certain HTML element:
clickTarget looks for clicks on the provided DOM element.clickSelector looks for clicks on the provided CSS selector, concatenating the element’s tag, id, and class values.clickTextContent looks at the HTML element’s target’s textContent property. Only the first 2000 characters are considered.Here is an example:
When you search on the Sessions page, you can search for sessions where an end user visited a particular URL, using the visited-url filter. Use quotations around the value for this search to avoid any errors due to special characters in the URL.
Here’s how:
As with other filters, you can use contains and matches regex expressions with visited-url. The following example retrieves all sessions where the end user visited the “sessions” page:
By default, the session replay SDK plugin automatically injects the following attributes to provide additional help with searching for sessions:
You can create deep links to session search results or to specific sessions. This is useful for sharing session data with teammates, integrating with other tools, or creating bookmarks to common queries.
The queries you build when searching for sessions are reflected in the URL parameters. You can share these URLs with others to deep link to search results, or create them programmatically.
The URL syntax is:
Use the logical operators AND and OR, separated by URL-encoded spaces (%20):
The AND operator is implicit, so the following queries are equivalent:
Here are some example deep links:
For the list of session properties you can use in queries, read Search attributes.
You can retrieve the URL for a specific session programmatically using the session replay SDK plugin. This is useful for integrating session replay with other tools, such as customer support systems or error tracking services.
Use LDRecord.getSession() to get the URL for the current session. The method returns an object with two properties:
url: A link to the session in LaunchDarkly.urlWithTimestamp: A link to the session at the exact time the method was called. Use this to link directly to the moment an event occurred, such as when an error was thrown.Here’s how:
For example, you might send the session URL to a customer support tool when an end user reports an issue, or include urlWithTimestamp in error logs to link directly to the moment the error occurred.
To learn more about retrieving session URLs, read Retrieve session URLs on the client.
You can filter out sessions that you do not want to view in LaunchDarkly. This is useful for sessions that you know are not relevant to your application, or that are not actionable. Filtered sessions do not count against your sessions quota.
You can set up ingestion filters to manage the number of sessions recorded in the following ways:
development environment. For each session LaunchDarkly receives, it makes a randomized decision that results in storing only 1% of those matching sessions.You can configure these filters from your project settings. To learn how, read Observability settings.
To use filter logic that is not available in the project settings, use the session replay plugin’s options for starting and stopping sessions at your discretion. To learn how, read Manually control session recording.
Session replay supports privacy features, including data obfuscation and redaction. This ensures that sensitive data is not captured or displayed in the session replays. All of this functionality happens client-side, which means that no sensitive data is sent to LaunchDarkly servers. To learn more about the privacy options for session replay, read Privacy in the SDK documentation.
For images, videos, and other external assets, LaunchDarkly does not make a copy at record time. Instead, LaunchDarkly makes a request for the asset at replay time. If a request fails, some parts of the session may appear blank. Most commonly this occurs because of an authorization failure, or because the asset no longer exists.
For iframes, LaunchDarkly recreates an iframe with the same src. To learn more, read Working with iframes.
After a session starts, LaunchDarkly continues recording in the same session for up to four hours. Each browser tab or instance will start a distinct session, so if your web app is opened in two tabs at once, LaunchDarkly records two sessions.
However, after a session starts, it can be resumed. If your web app is opened in a single tab, closed, and then reopened within 15 minutes of closing, LaunchDarkly resumes the existing session. If more than 15 minutes have passed, LaunchDarkly starts a new session.
“Active time” is the time when an end user is interacting with your application with no more than a 10-second gap in activity. For example, if an end user is moving their mouse, typing, or clicking for 30 seconds with no gaps of longer than 10 seconds, that counts as 30 seconds of active time.
By default, sessions in the Observability session UI are identified by LaunchDarkly context keys. A context may contain multiple different kinds, and each of those kinds has its own key.
By default, these context kinds are combined to create the session identifier. Here are some examples of session identifiers composed of contexts:
Sally has an identifier of Sally.org-key-123 has an identifier of “organization:org-key-123`.Sally user and the org-key-123 organization has an identifier of organization:org-key-123:user:Sally.You may want to use a custom identifier, such as an email, screen name, or other attribute, instead of the context keys. To do this, provide a contextFriendlyName function when you configure the Session replay plugin:
Call the contextFriendlyName method whenever you need a session identifier. If your function returns undefined, the system will revert to the default behavior above.