Tealeaf has two search interfaces: Search and Classic search.

Both Search and Classic search query captured data to locate sessions for further analysis or replay.

Because the entire request and response data stream is captured, Search and Classic search provide access to a rich reservoir of data that describes the interaction activities that visitors have with your website or mobile application.

With session search, you can input criteria and create search conditions to retrieve a list of sessions that represent a shared customer experience. For example, if visitors abandon their transactions, you can search those sessions and explore the common factors of abandonment.

Session searches are based on:

• Session status
• Application profile
• Session end time
• Conditions
• Groups of conditions

With Search and Classic search, you run searches based on session status (active sessions, complete sessions, all sessions, or archived). An Archived session is a searchable session that was exported from Tealeaf to IBM Cloud™ Object Storage.

To learn all about Session search, visit our Acoustic Academy learning course, Session Search.

Differences between Search and Classic search

Search and Classic search provides the same capabilities, but Search has a more modern interface and it applies predictive technology against your search input, presenting intelligent keyword matching, value recommendations, and suggestions for name value matching, all while boosting performance and reducing back-end costs.

By providing suggestions in response to your search input. Search helps hone and build searches more efficiently, returning a relevant list of sessions quicker than ever before.

For information about how to use Classic search, see Search sessions using Classic search.

For information about how to use Search, see Search sessions using Search.

How to switch from Search to Classic search and vice versa

There is a “switcher” in the Search user interface that allows you to go back and forth between the Search and Classic search.

The search that you select from the switcher is persisted and becomes the “de facto” default. For example, if you select Classic search from the “switcher”, Classic search becomes the default search. So when you select Session Search from the navigation panel, the search that opens is the original/classic search.

See the following sections for tips on how to optimize Search and Classic search:

Support for wildcard searches

Session search supports wildcard searches except for the following conditions:

• Free text search and URL searches
• Search fields with pre-defined values, where you select options from a drop-down list. For example, Browser and Country code.

The wildcard search is not case sensitive.

Wildcard searches are applied only when you include an asterisk (*) to the search value. For example, let's say you are searching sessions for a Browser user agent. See the Wildcard search example for details.

Ways to optimize performance

Searches of completed sessions are faster than active sessions because completed sessions are indexed.

Avoid doing free text searches of the request or the response. Use keywords and provided search fields instead.

Try to minimize the date range to only the relevant dates for complete sessions.

Boost search capabilities by adding multiple conditions

By using multiple conditions, you can further define your search. For example, you might search for sessions that meet the criteria for either Condition 1 or Condition 2:

• Condition 1: Event, which has a Promo Code, and the promo code is save10.
• Condition 2: Event, which has an Abandoned Cart, and the abandoned cart value is yes.

Group conditions in a session search

You can define a more selective search by using condition grouping. Condition grouping is similar to using parenthesis in a mathematical equation and using AND/OR logic. For example, you might want to search for sessions that meet the criteria for both Group 1 and Group 2:

• Group 1:
  • Event 1: Event, which has a Promo Code, and the promo code is save10
  • Event 2 Event, which has an Abandoned Cart, and the abandoned cart value is yes
• Group 2:
  • Event 1: Event, which has a Promo Code, and the promo code is FREESHIPPING
  • Event 2: Event, which has an Abandoned Cart, and the abandoned cart value is yes

Track search results in session replay

The results from your free text and Event searches are flagged in all three views (Replay, Timeline, and Raw data) in the Replay UI.

You can use the flags to quickly identify where the searched term or Event occurs in the session.

Pages that include the searched term are marked in the navigation by a flag icon. The flag includes a number that indicates the count of steps inside the page that contain the searched term. Each individual step inside the page that contains the search term is also marked with a flag icon.

Wildcard search example

Wildcard searches are applied only when you include an asterisk (*) to the search value. For example, let's say you are searching sessions for a Browser user-agent:

Include => Session attribute => Browser user agent <Attribute value>

Here are some examples of Browser user agents:

Mozilla/5.0 (Windows NT 6.1; Win64; x64) 
 AppleWebKit/537.36 (KHTML, like Gecko)
 Chrome/41.0.2272.43 Safari/537.36"

• To see sessions with Browser user agents that start with "Mozilla", enter the following wildcard in the Session attribute value field:

  mozilla*

• To see sessions with Browser user agents that end with "537.36", enter the following wildcard in the Session attribute value field:

  *537.36

• To see sessions with Browser user agents that contain "Chrome" , enter the following wildcard in the Session attribute value field:

  *chrome*