Many LogRocket enterprise clients capture hundreds of millions of monthly sessions, making it difficult to store all sessions without significant infrastructure cost.
LogRocket solves this problem by making it highly customizable to control which data you'd like to keep for long-term troubleshooting and analysis. We offer multiple ways for you to control which sessions you are capturing:
You may be interested in capturing sessions in which a user interacts with a specific part of your application or begins a certain flow. With LogRocket, you can choose to capture a specific percentage of user sessions that include a click on specific text or a selector.
This feature can be leveraged to capture sessions in which a user interacts with your Support or VoC tools, allowing you to view user frustration and specific actions.
Using LogRocket filters, you can capture specific sessions that exhibit known failures, to better understand the root cause of these issues as well as the experience of the end user:
Specific error filters that you can use to record sessions for include:
- Network errors (including request and response bodies - using the Network Request filter and specify a status code and a request or a response body
- DOM errors - use the Element Visible filter to record sessions in which a specific message was displayed to the user
- Slow network requests - set a specific duration for the Network Request filter
Product analytics teams often want to understand certain critical paths in their application (ie. opening a bank account, shopping cart checkout). With LogRocket, you can control session capture from specific pages on a percentage bases, such as "record 0.01% of users who start the checkout process".
You can construct these filters based on simple URL definitions.
In addition to configuring conditions for session capture, you can determine how long prior to a condition triggering to save data. You have two options:
- Record up to 30 seconds prior to the condition trigger
- Record entire session prior to the condition trigger
For example, with option (1), you would see 30 seconds prior to a user experiencing an error.
We typically recommend Option (1) since it less expensive and can cover most use cases. Depending on session volume and budget, Option (2) can give you more context into an issue.
If you have any questions about this functionality, please reach out to your Customer Success Manager or [email protected].
Updated about 1 year ago