Skip to main content

Search, replay, and session administration

Search, replay, and session administration

Adding other fields for indexing and search

By default, Tealeaf indexes various request data so that Tealeaf components and users can search for sessions using a range of criteria. The set of available fields is defined for the most common case. Any application-specific fields or data added using optional Tealeaf components is not automatically available for search.

The following section provides a set of potential methods for making any request variable available for indexing and searching.

Note: By default, most Tealeaf solutions do not index response data.

General approach

To make data available for indexing, it must be located in or moved to a section of the request where data is indexed.

Note: The IndexMultiProcess does not support specifying individual fields or sections of the request for indexing. All additional data that is to be indexed must be inserted into the [appdata] section of the request.

The purpose of indexing, however, is to make the data available for search. It is possible to also make request or response data available for search by creating events that capture and store the values as event data.

In the sections below, the different approaches are described, and examples are provided for making the data available for each approach.

Methods for making indexing available for search

Use the following methods to make request or response data available for indexing. You can also use these methods to move response data.

Table 1. Methods for making indexing available for search
Method Description Pros Cons

Move request data to [appdata]

Using the Privacy session agent, you can move any request variable into the [appdata] section of the request. All fields in this section are automatically indexed.
  • Privacy session agent should already be deployed.
  • Indexed data is available in a consistent space
  • Data is not available for reporting.
  • Indexes are stored in individual Canisters and are periodically trimmed when the session is no longer available. Reporting data is typically retained for a longer period of time in a SQL database.
  • Privacy session agent can be resource-intensive, particularly if regular expressions are used or if the field occurs frequently in session data.
  • A limited number of rules can be created for Privacy session agent.
  • With two copies of the data in the request, it is possible for discrepancies to be created between the request variable names and their values.
  • Each additional field added to indexing grows the size of the indexes

Create an event to capture the request data

Through the Event Manager, you can create an event to capture and store the request data. From the Portal, you can then search for sessions using the event or values for the event.
  • Event data is available for search and for reporting.
  • Event data is stored in the session itself; indexing data is stored separately.
  • By default, event data is stored in the SQL database for 365 days.
  • Event data is more widely accessible in the Portal. For example, you can locate sessions that contain events based on the icon associated with the event.
  • Events can be configured to be checked on every hit when they only need to be checked on the first or last hit, for example, which impacts Canister performance.
  • If regular expression is used to define an event, event evaluation can be impacted by a poorly constructed regular expression.
  • Adding a new event increases the storage required for every session in which the event occurs. Depending on how frequently the event is triggered and the number of dimensions associated with the event, the storage increase can be significant.
  • Events are also stored in the Reporting database.

Using privacy to insert Request or Response data for indexing

The Privacy session agent can be used to move request or response variables and values into the [appdata] section of the request, where it is automatically made available for indexing.

Note: Adding new fields for indexing increases the size of the indexes, particularly if the fields occur frequently in the session data. Additionally, depending on privacy rules are created, the new processing can impede throughput in the pipeline. Tealeaf recommends creating a single Privacy rule to move one field of data and checking the change in the size of the indexes before adding more rules.
Note: Adding new fields for indexing is not required to enable users to search for the data. To search for request variable and value combinations, users may enter the following in the All Text field: 

RequestVariable contains RequestVariableValue

where

  • RequestVariable = the name of the request variable
  • RequestVariableValue = the value of the request variable

While the above method works, it is expensive in terms of Search Server processing. Tealeaf recommends moving the data for indexing for searching for common request variables.

Example

The CX UI Capture for AJAX solution captures items that may not generate transactions with the web server, such as user interface events and other properties, from the visitor's browser and submits them to Tealeaf for capture. Using CX UI Capture for AJAX, you can capture a rich repository of data about visitors to your web application.

When CX UI Capture for AJAX is deployed, some Tealeaf performance reports are populated with data captured from the visitor's browser. These reports are available through the Portal.

However, these reports are generated from internal events in the Canister. For maintaining performance, the Canister does not maintain events to reflect all of the possible data captured from the client. For example, exceptions detected in the user interface are detected by CX UI Capture for AJAX and submitted to Tealeaf, but they are not available in the provided reports.

This information could be very valuable for assisting customers with problems with your web application and then providing that information to developers to resolve. If you were able to capture this information and store it in such a way that it is indexed for search, CSRs at your enterprise could search for these sessions, drill into them to locate the customer issues, and then provide the sessions to developers for further resolution.

Tealeaf automatically provides this information in the [env] section of the request. In that section, CX UI Capture for AJAX inserts the following request variable containing an identifier for the number of client user interface exceptions:


HTTP_X_TEALEAF_PAGE_CUI_EXCEPTIONS=2

Configuring privacy

By default, Tealeaf does not index this field, so you can use the Privacy session agent to move this field into the [appdata] section of the request.

Note: The following example is created using the raw configuration for the privacy filter. If you are creating multiple rules to move content to the [appdata] section of the request, you can copy and paste finished versions of the rule to create new, similar rules.

To configure privacy indexing:

  1. Verify that Privacy is enabled.
  2. Open the privacy configuration.
  3. Create a privacy action and rule.
  4. Test the privacy action and rule.
  5. Create any additional rules and actions.

Related articles

community icon

Join the community

Ask questions, share best practices, and connect with fellow marketers.

Ask a question

Academy

Read how-to articles, guides, and more to help you on the path to success.

Learn more