LogRocket supports the creation of Definitions as a business-friendly wrapper around the most crucial parts of their application. For example, if there is a particular URL pattern or CSS selector that maps to a particular page or button ('Checkout' page or 'Add to Cart' button), you can define those once as a Definition and leverage that Definition throughout LogRocket.
Navigate to the Definitions tab within Settings. You'll see a list of your current Definitions if any exist, including their name, description, type (page or event), as well as when they were last edited.
To create a new Definition, click the ‘Add New Definition’ tab in the top corner. A ‘New Definition’ modal will appear:
As you start to fill in the Definition, you will see an indicator appear letting you know whether it matches any sessions. This can help you confirm that the text or selector you have entered is correct.
Definitions today can be defined with either Click, Visited URL, or Element Visible filters, corresponding to Click, Page, and Element events. We currently only support a single filter within each Definition. You can add an optional 'Description' to clarify what the Definition refers to.
All Definitions are team-visible
Currently, we do not support the creation of personal Definitions. All Definitions that are created are visible and editable by all team members.
You can use Definitions in most places that you use filters.
You'll see a new "Taxonomies" category in the omnibar with a new filter called "Use Definition".
When you select this, you'll see a filter appear with a list of all Definitions within your application. Select the desired Definition to search for sessions matching it.
You can also use Definitions when creating charts within the Metrics section. Definitions are available for user when creating Timeseries charts or adding filters to any chart. They are also available when creating Funnels or Path Analysis.
When the "Element Visible" filter to create a definition, a "Use as Error State" checkbox appears at the bottom of the form:
Designating a definition as an "error state" includes the definition to be collected in Issues as an Error State issue type.
Note: Element visible definitions are non-retroactive, meaning they will record events after being defined, but will not look back in time before their creation date.
New projects added to an organization after Nov 9, 2022 will include several default error state definitions. These default definitions are common phrases used in apps to communicate to the user that a problem has been encountered. By providing default error state definitions, error state issues will immediately begin to populate in the Issues view if these default error states match any matching phrases in your app.
However, these default error states may or may not be a good fit for your app. You should review them and edit or delete them to setup the best fitting error states for your app.
Best practice: Review your app's error states
The default error state definitions are common phrases expressing errors to uses found in app. These are not guaranteed to match your app's error states and likely will not cover all of your app's error states.
The best practice is to review your app's error states and create error state definitions with them. This will guarantee that Error State issues will be populated as your users encounter these errors.
Also, these issues are non-retroactive, so the sooner these error state definitions are created, the better. Error State issues will only begin to appear after the point the error state definitions have been created.
Have a project created before 11/9/22? No problem, you can also manually trigger the creation of these default error state definitions. From the Issues view, 1.) click the issue types dropdown filter under "Issues", then 2.) click "Setup" next to "Error States". 3.) The Definitions side-modal will appear and if you have no error state definitions already, you'll see a button to "Create Default Error State Definitions".
Updated about 1 year ago