Tealeaf uses a dimensional data model that is populated by event-based mechanisms to deliver a reporting facility of unprecedented power and flexibility to manage the customer experience of your web application. Events and event-related mechanisms are developed and tested through the Event Manager, which is integrated into the Portal.

Structural Overview

An event is a condition that is detected in the session data stream that triggers an action.

A hit attribute is a specified start tag and end tag in session data that can be referenced as a condition for one or more events. Hit Attributes can also be explicit text strings in the data. Hit Attributes are not directly applicable to reporting. Hit Attributes are defined in the Event Manager.

An event is associated with one or more report groups, which are collections of dimensions on which you can report simultaneously.

• A dimension is a list of values that are associated with an event. This list of values can be fixed or can be generated from the session data stream every hour.
• A fact is the data entity that combines an event and a report group. Facts are the essential storage mechanism for reporting data. Some facts can have fact values, which are event instance data that can be configured in the event definition.
• A label is a grouping mechanism for event and dimension objects. You can organize a set of related objects under a single label. Labels have no impact on data processing.

Basics

Tealeaf captures all HTTP or HTTPS transactions between the visitors to your web application and the servers that serve the application to them. Each request from the visitor and the corresponding response from the web server are forwarded to Tealeaf for capture, processing, analysis, and reporting.

• A request is a message that is sent from the client, typically the visitor's browser, to the server for one or more files.
• A response is the information that is sent from the web server back to the client. Any binary content in the response is typically dropped from Tealeaf capture.

A single request and a single response together form a hit , which is the basic unit of capture in Tealeaf.

The sequence of hits that are captured from a single visitor's contiguous experience with your web application is asession.

This diagram shows the request and response flow between the client and the server:

Page Generation Time

Page Generation Time indicates web server performance. Spikes or high numbers indicate web server slowdowns. The time that it takes to begin sending the page to the browser from the last request packet to the beginning of the response, shown in this diagram:

Network Time

Network Time measures the time on the network to the browser. High times indicate slow networks or browsers. The time to send the Response HTML to the browser until the moment when the browser sends the acknowledge back, shown in this diagram:

Round Trip Time

Round Trip indicates connection performance. Spikes or High numbers indicate slow connections. The time between the server receiving request until receiving acknowledgment from browser: Round Trip Time = Page Generation Time + Network Time, shown in this diagram:

Page Render Time

Page Render Time can indicate browser issues. High numbers indicate slowdowns The time that it takes from when processing of the response begins until execution of the document.onload() function in the browser, shown in this diagram:

If UI Capture is deployed, page render time is measured from the moment after UI Capture loads until the DOM-ready state is complete.

Alerts

An alert is an action triggered off the triggering of an event or off a threshold value for an event. For example, if the number of application errors is tracked in an event, you can configure an alert to trigger off the occurrence of this event (meaning at least one application error occurred) or off the occurrence of 10 application errors, which can require escalation of the issue.

Alerts are defined through the Event Manager in the Portal. Alerts can be triggered off an event. You can configure alerts for user-defined events and canister events.

Based on the criteria that are defined for the alert, you can trigger any combination of these actions:

Alert actions	Description
App Event Log	A log message is inserted into the application event log.
Email	An email alert is delivered to a configured list of addresses.
Shell Command	An external shell command that you specify is run.
SNMP	An SNMP message is delivered through the configured server.
XML Log File	An XML-formatted log file is generated and saved.

Report groups

An event can be associated with one or more report groups. A report group is a set of dimensions that can be displayed on the same report. A report group can be thought of as the parent of dimensions.

For example, you can create a report group that is called user agent properties to contain values for the following properties that are associated with mobile user agents:

• User agent name
• Screen width
• Screen height
• Javascript support

In this example, the inclusion of the user agent name dimension is useful for combining dimensions into new reports. If another dimension also includes this dimension, then dimensions from each of the two dimensions can be displayed in the same report.

These dimensions are of different data types, yet they can be added to the same report in the Report Builder.

Up to a maximum of 4 dimensions can be displayed in the same report group. Dimensions in the same report group can appear in the same report. Dimensions in different report groups cannot appear in the same report.

Events and report groups

Since you can create events and report groups independently, some report groups cannot exist for the lifetime of the event. For example, data that is acquired for the same dimension in two different report groups cannot be entirely consistent if the dimension was added to one of the report groups after the other one was added. As a result, you can end up trying to pivot on the dimension across report groups for a report period that does not exist in one of the report groups.

All events are automatically aggregated by the No Dimension Report Group report group, which cannot be disabled.

Events can be added to other report groups, as well.

Dimension values and report groups

A dimension is a list of values that are associated with an event. When an event is triggered, the detected value is reported into a dimension.

The values to detect are configured in the Values tab in the Event Manager. The report groups into which the values are reported are specified in the Report tab of the Event Manager. A dimension can belong to multiple report groups, which can be associated with multiple events.

Unbounded Lists

An unbounded list dimension type is generated by extracting values in the transaction stream for the dimension and building a list for each hourly time interval. If the limit for the dimension is configured to be 1000, the first 1000 values for a dimension that are detected in an hour become the available dimension values for that dimension during that period. Subsequent values that had not been previously detected during the hour are mapped to a single fixed value, TLT$LIMIT.

Value Lists

A value list dimension type contains a pre-defined set of values that are the only accepted values for the dimension. The list of the states of the United States of America is an example of this type of dimension. When an event fires, the values that are assigned to the event must come from one of these listed values.

Value lists can be one of these types:

Values to record	Description
Whitelist + Observed Values	Record values that are on the whitelist for the dimension, and also as non-blacklisted values detected in the capture stream.
Whitelist Only	Record only values that are displayed on the specified whitelist for the dimension.
Group Lists - Text	Populate the dimension from a group list of text values that are configured for the dimension.
Group Lists - Numeric	Populate the dimension from a group list of numeric values that are configured for the dimension.

Facts and events

A fact is a data structure that is generated when an event fires. It contains the triggering event, its value, and the related dimension or dimensions and values. The fact is the essential data storage structure for Tealeaf reporting. This internal storage mechanism is not directly accessible to Tealeaf users through the Portal.

Any data that is to be visible together in the same report must be stored in the same report group because data is stored at the fact level in the database. All facts that are associated with an instance of a triggered event contain the same fact value. Each fact that is associated with a single event can contain dimension data for a different report group.

Multiple facts

Multiple facts can be charted together if they share one or more common dimensions. For example, if two facts share the DimURL dimension, then they can be displayed in the same chart.

• Multiple time-based events can always be displayed in the same chart, since they always share time as a dimension-type axis.
• For reports not based on time, the events in them must share a common dimension to be displayed in the same chart.

Fact value types

A fact value is data which is recorded with the triggered event. There are three types of Fact value types:

• Count fact values - These fact values are undefined. The count of each triggered event is accumulated for reporting.
• Numeric fact values - Numeric fact values are stored at the hourly level. For each hour of numeric fact value you can apply different operations: Sum, Average, Min, Max.
• String fact values - Any non-numeric fact value is a string fact value. No predefined operations can be completed on detected values.

Fact values

Fact values are event instance data that can be configured in the event definition. When an event fires, any data that is found between a specified Start Tag and End Tag in a hit attribute is captured as a fact value and stored in the database. This data can be searched and reported in the Portal.

• Tealeaf fact values can be numeric or text values.
• By default, numeric fact values automatically trigger the computation and recording of the count, sum, average, minimum, and maximum values of the value for each hour.

All facts that are generated by a single event either fire or do not fire, which can be configured through the Event Manager. Fact values can be configured to be searchable and reportable in the Report tab of the Event Manager.

Count fact values

These fact values are undefined. The count of each triggered event is accumulated for reporting.

Numeric fact values

Numeric fact values are stored at the hourly level. For each hour of numeric fact values, you can apply the following operations to them:

• Sum
• Average
• Min
• Max

String fact values

Any non-numeric fact value is a string fact value. No predefined operations can be completed on detected values.