Reporting is delayed due to system performance

When the message is displayed in the Report Builder, the data range in the current report intersects a period for which the Health-Based Routing server or Processing servers are spooling hits to disk. Since these hits are spooled, they are not yet collected and aggregated into the report database. Therefore, the reported data from these periods can be incomplete. You can review the last times when Canister data was collected and aggregated for reporting.

When using Compare function with dimensions, dimensions with a static list of values (for example, Day of Week) will be compared value-to-value

When you compare data between two periods while you use non-segment dimensions, the complete message can be displayed:

When using Compare functionality with dimensions, dimensions with a
static list of values (e.g. Day of Week) will be compared
value-to-value, i.e. Monday (Focus) to Monday (Compare). When
dimensions without static values are compared (e.g. Day and Hour),
the Focus and Compare ranges will simply be displayed side by side
(first Day and Hour of Focus range with first Day and Hour of
Compare range).

If you include dimensions on the x-axis or y-axis and applied a Compare period, the data in the dimension determines how the report data is displayed.

• Dimensions with static values, such as Day of Week, are displayed by using individual value that is compared to individual value.
• Dimensions such as Day and Hour do not have static values. Values for these dimensions are displayed side-by-side in the report.

Report query returned too many rows (> 1,000). Please filter or TopN your request.

To prevent runaway database queries that impede the Data Service, the Portal, and your browser, a limit of 1,000 rows of returned data is imposed on any configured report. If your report returns more than 1,000 rows, the preceding message is displayed, and the results are not delivered to your browser for display. You must adjust your report configuration and refresh the data.

• To correct the report, you can apply a dimensional filter to narrow the range of reported values, or you can filter dimensions to display a TopN number of values.
• Now, no limits are imposed on the number of rows in the report, which means that the number of events, functions, and dimensions are not impacted by this limit.
• Browser performance can be impacted by results that contain fewer than 1,000 rows. Where performance is a factor, you must attempt to change your report characteristics to reduce the number of rows of data.

This report uses one or more dimensions whose oldest observed values have been trimmed. As a result, this report may not reflect all originally observed dimension values.

To prevent the runaway growth of dimension values in the database, Tealeaf imposes the automatic trimming of dimension values, when the number of values that are stored in the database exceeds a predefined limit. When the number of values that are stored for an individual dimension exceeds the limit, the oldest dimension values are removed from the database.

You can configure this limit to be a high number, which is useful for dimensions such as URL (Normalized). You cannot completely disable this feature.

As part of this trimming of dimension values, all instances of the removed values are marked as [others] since the value is no longer among the available set.

What you can configure is whether the marking of values as [others] is applied to all stored report data.

You can choose to not change stored report data to [others]. However, in this case, discrepancies can be introduced between the counts for events in a report that is not filtered by a dimension and the counts for events in the report that is filtered by this dimension.

Suppose that:

• Dimension A contains the values Apple and Orange.
• The automated data trimming operation removes these values from Dimension A.
• The report data is not updated to mark these values as [others].
• The trimmed values is previously recorded with Event A.

If you create a report in the Report Builder by using Event A and do not filter it by any dimension, the counts of the events are already aggregated. So, the report data reflects the accurate total of event occurrences.

If you then apply Dimension A which is trimmed, your report on Event A does not include any counts that were recorded when Apple and Orange were detected. As a result, these counts cannot be summed to reach the count of the unfiltered parent event.

This discrepancy in the report counts can be resolved only when the report data is updated to mark trimmed values as [others].

The choice of whether to update reporting data to use the [others] value is configurable.

• After you have review the results of the trimming operation in your reports, you can reset the trim flag on the dimension so that the Portal message is no longer displayed when the dimension is used in reports.

There were not enough days of data to perform the calculation as specified due to the data retention settings. Values below have been calculated using available data.

When there is insufficient data to complete a function calculation, this message is displayed.

When applied to event counts, some functions, such as a rolling average function, require a preconfigured number of data points to complete the calculation in a satisfactory way.

Depending on the data retention settings that are applied to the data used in the event, there may not be enough days of data to produce enough data points that are required for the calculation. For example, if you are calculating a Same Day of Week average, the default number of weeks of data that is required for the calculation is 4. If you are retaining only three weeks of hourly data in your system, then there is not sufficient data to complete the calculation according to the configuration settings.

In these instances, the calculations are made based on the available data points, with any adjustments made to accommodate the smaller data set. In the previous example, the Same Day of Week average is computed by using three data points, and the preceding message is displayed.

Selecting a date range of one day is not an optimal report variable for an hourly dimension. Either select the "day" dimension or specify a date range of at least a week to pull hourly data.

Tealeaf reporting data is aggregated and stored by hour and by day. The most recent data in the system is stored by hour. As data ages out of the specified hourly data range, it is re-aggregated and stored as daily data.

Depending on the date range that is selected in the report, the following results can be observed:

• If the date range of the report extends past the hourly data cutoff, the report uses daily data to complete the older date ranges.
• If the selected date range is valid for daily data only and is grouped by using an hourly time dimension (such as Hour of Day or Day and Hour), then the report returns no data because the daily data cannot be broken down by hour.
  Note: By default, the Report Builder uses the Hourly dimension to filter reports with a selected date range of a single day. If this filter is applied against a single date that includes only daily data, then the report contains no data at all.

However, if you configure a report with a date range that includes daily and hourly data and is configured to use a daily level dimension, you can discover that the zero-filled days in the hourly report are now populated. The older data in the report that is outside the hourly date range is populated by the stored daily data, while the daily date range that is inside the hourly date range is populated by hourly data that is aggregated in an ad hoc manner for display in the report (while the data stored in the database remains in hourly form).

You can modify the date ranges for hourly and daily data retention. The hourly and daily data ranges are configured by default to exhibit the preceding behaviors for performance reasons.

• In previous releases, hourly and daily data ranges overlapped from the current day backward in time to the end of the shorter of the two ranges.
• You can modify the method and frequency of data aggregation, which can affect system performance.