| Oracle® Real User Experience Insight User's Guide Release 6.5.1 for Linux x86-64 Part Number E18053-01 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 6.5.1 for Linux x86-64 Part Number E18053-01 |
|
|
View PDF |
This chapter explains the use of the Data Browser. This is at the heart of RUEI, and provides direct access to the information gathered during monitoring. Through it, you can drill down, search, and filter information in an intuitive and user-friendly manner.
The information shown in each report is derived from a multi-dimensional data structure that contains all the information captured during monitoring. Through this structure, you can explore Web data by simply clicking down through increasing levels of detail, and view by different dimensions (such as period, referrer, visitor type, and so on). This data structure can be viewed through the Browse data tab.
You can use the Data Browser to understand the context of the data shown in a report, and to drill down, rank, sort, and filter information to gain insight into causes, effects, and trends. To open the Data Browser from within a report, select the Browse option from the report menu. To open the Data Browser from elsewhere, click the Browse data tab. A window similar to one shown in Figure 3-1 appears:
The toolbar icons at the top of the Data Browser screen are shown in Figure 3-2, and are described in Table 3-1:
| Icon | Description |
|---|---|
 |
Graph. Displays the standard graphic visualization (pie chart, line chart, or bar chart) for the data. The graphic form depends on the underlying data. |
  |
Additional visualizations. In addition to the standard graphical visualization, depending on the underlying data, additional visualizations may be available, and can be selected by clicking the appropriate icon. You can also use the Type option from the Graph menu to select a visualization. |
 |
Values. Shows the underlying data values for the data in the browser. See Section 3.3, "Working With Value Lists" for more information about working with value lists. |
 |
Previous and Next page. Use these controls to move between pages in the displayed data set. |
 |
Glossary. Provides a brief explanation of the metrics currently shown within the Data Browser. This includes both the dimensions shown in the graph or values table, and any filters that have been applied to it. The use of filters is explained in Section 3.7, "Working With Filters". |
 |
Search. Allows you to search for strings within in the currently displayed data set. The use of the search facility is described in Section 3.4, "Searching in the Data Browser". |
  |
Zoom in and Zoom out. Allows you to change the level of displayed detail. When zooming in and out, you change the dimension of the viewed data. The new dimension depends on the currently selected dimension. For example, if you are viewing yearly data, zooming in will change the view to a monthly one. If you are viewing client location by country, zooming in will change the displayed dimension to providers within the client location country. To quickly return to the original dimension, select Reset view from the View menu. |
 |
Open as report. Opens a new window with the currently shown data in report print layout mode. The creation and customization of reports is described in Chapter 2, "Working With Reports." |
 |
Open as export. Opens a new window in which you can further customize the currently shown data prior to exporting it to a wide variety of applications (such as Microsoft Excel). This facility is described in Section 3.8, "Exporting Data". |
 |
Add to dashboard. Adds the current view to a selected dashboard. This facility is described in Section 1.7.4, "Adding a Data Browser or KPI View to a Dashboard". |
 |
Back/Forward. Undoes or redoes your most recent actions within the Data Browser. |
The information available within the Data Browser is divided across groups. At the highest level, there are two types of groups: application-related groups and services-related groups. Each group provides a number of perspectives, or views, on the collected data. These views can be selected from the View selection panel, located on the left-hand side of the Data Browser window (Figure 3-1).
Each main group within the View selection panel relates to a broad category of information. There are groups available about the pages visited on the monitored Web environment, visitor sessions, user flows, failed URLs and pages, and key pages.
Within each of these groups, sub-groups offer information about a specific aspect of the selected category. More specifically, they offer information across specific dimensions. These dimensions are indicated in the name of the sub-group. For example, within the All sessions group, views are available across the dimensions domain, period, user ID, and client browser, language, location, and operating system. This is shown in Figure 3-3:
Figure 3-3 Data Structure Selection Panel
Individual views are grouped according to a standard classification (failure, performance, overall, and size) that reflects the type of information they provide. Within these, you can select the active dimension you want to use to explore the underlying data.
In addition to the standard dimensions discussed in this section, it is also possible to extend the information available within the Data Browser through the use of custom dimensions. These are described in Section 3.9, "Working With Custom Dimensions".
The Session diagnostics facility is described in Section 3.10, "Working With the Diagnostics Facility".
Within RUEI, two types of information are available: information derived from all active sessions detected during a 5-minute period, and information derived from finished (closed) sessions. Each of these are described in the following sections.
Active Sessions-Derived Information
Nearly all information reported in RUEI is based on the open (active) sessions detected within a 5-minute period. There is one exception to this: the reporting of multiple-day periods within the All sessions group. This is discussed in the next session.
Be aware that the properties reported for a session within the 5-minute period, such as IP address and user ID, are effectively snapshots taken at the end of the 5-minute period. While the value of these properties can potentially change during the 5-minute period, it is their values at the end of the period that are reported.
Closed Sessions-Derived Information
Information reported for multiple-day periods within the All sessions group is derived from finished (closed) sessions. As a result, this information has a delay associated with it. The delay arises from the defined session idle time. This specifies the period of inactivity after which a visitor session is regarded as terminated. By default, this is 60 minutes.
As a result of how this information is derived, it is not possible to drill-down to the level of 5-minute intervals. In addition, imagine a visitor session starting at 9 AM, and finishing at 5 PM. The session is active throughout the day, except for lunch, from 12 AM to 1 PM. This session would normally be reported as one session. However, multiple-day periods within the All sessions group would be reported as two sessions because of the inactive period.
Why are There Sometimes Differences in Reported Data?
It is possible that small differences arise between the data reported for a single-day period and a multiple-day period. For example, the number of reported sessions in the All sessions view for a day may be slightly different to that reported for the same day when viewed within a two-day period in the All sessions view. In order to understand why these differences arise, it is necessary to understand how data for a single day and for a multiple-day period is processed.
Consider the situation shown in Figure 3-4. Two visitors, A and B, both start browsing at 12:05. A's session ends at 12:45, while B's session ends at 13:55. Visitor A returns at 14:05, and leaves at 14:55.
On a hourly level, the number of concurrent visitor sessions is reported as shown in Table 3-2.
Table 3-2 Hour-Level Reporting
| Hour | Sessions |
|---|---|
|
12:00 |
2 (during 12-13 there two unique visitors seen). |
|
13:00 |
1 (during 13-14 there was one unique visitor seen). |
|
14:00 |
1 (during 14-15 there was one unique visitor seen). |
On a daily level, two concurrent sessions would be reported. However, when viewed on the monthly or two-day level, the number of sessions is reported. In this case, because of the elapsed idle time between A's two sessions, that is reported as three. In order to prevent differences between the number of reported sessions, you should ensure that the specified session idle time matches that of the monitored application.
The Problem analysis category of views (shown in Table 1-3) provides, for applications, in-depth information about failing or problematic page views and hits. It contains the following views:
Failed URLs
Reports on the objects (hits) within failed pages. For example, those pages that contain broken images and unavailable downloads. Note that it logs a maximum of 5000 objects per 5-minute period. All technical errors (described in Appendix E, "Explanation of Failure Codes") for that object are reported. Because this view is does not use application information, it can still report possible reasons for failed pages when no applications have been configured.
Failed pages
Reports on the server, network, Web site, and content errors experienced with application pages.
Slow URLs
Reports on the slowest 5000 objects per 5-minute period detected by the system, based on the object's end-to-end time. Note that objects must have an end-to-end time of at least five seconds to be reported in this view. Applications do not need to be configured for this view.
For services, it contains the following view:
Failed functions
Reports on the server, network, Web site, and content errors experienced with function calls.
Note:
The period for which information about failed URLs, pages, and service calls is available is determined by the Reporter system's data retention policies. These are described in Section 9.6.1, "Defining Reporter Retention Policies".The page delivery dimension is available within the Failed pages, All pages, Key pages views, and reports which errors have been detected on a monitored Web site. All errors reported in the page delivery dimension are also available through the Session diagnostics replay facility (see Section 3.10, "Working With the Diagnostics Facility").
Note if a page or object experienced several types of errors (for example, both a network and a Web service error), the page or object error is not recorded multiple times. Instead, it is reported according to the following order: Web site, server, network, and content. For example, an object that experienced both a Web site and a network error, is recorded as a Web site error rather than a network error.
The errors reported in this dimension are also available as the basis for KPIs as metrics expressed both as counters and percentages. This is shown in Figure 3-5.
Hit-based information is available via the Failed URLs and Slow URLs groups. These groups contain extensive information about images and other static objects, as well as dynamic objects. As a result, the URLs reported in these groups can contain a large amount of session and unique information (such as user IDs and any identifiers shared between different objects). An additional consideration is that these groups are limited to 5000 objects per 5-minute interval. This can make it difficult to isolate the specific hit-related information within a reported URL.
The URL diagnostics group is specifically orientated towards the separate recording of dynamic objects within pages (such as portlets and frames). Instead of reporting the literal URLs associated with particular hits, the URL diagnostics group reports functional URLs. These are customizable reporting schemes where session and unique information is typically stripped from the reported URLs. The information available within this group enables you to access dynamic server-interacting URLs independently of pages. This approach has the advantage that relevant hit-based information is more quickly located. For example, you could specify that you are only interested in the monitoring of Java or PHP-based calls. This is supplemented by a powerful clickout facility that provides dedicated support for diagnostic utilities, such as CAMM and AD4J.
The configuration of URL diagnostics is specified at application and suite level, and is described in Section 6.2.16, "Controlling Reporting Within the URL Diagnostics Group" and Section 3.2.5, "Suite Groups". The procedure for configuring external utilities for clickout from within RUEI is described in Section 7.7, "Configuring Clickouts to External Tools".
The suites category of views (shown in Table 1-3) provides in-depth information about the operation of monitored suites. The availability of individual suite groups depends on the accelerator packages installed on your RUEI installation. In addition, at least one suite must be configured for each suite to be available.
For each installed and configured suite, a diagnostics group is also available that provides for the suite the equivalent information available for applications through the URL diagnostics group (described in Section 3.2.4, "The URL Diagnostics Group").
The Service tests group provides for the reporting of service tests monitored through Oracle Enterprise Manager. Service tests enable organizations to ensure that the highest possible levels of quality and availability are maintained for their business services.
Oracle Enterprise Manager service tests are executed from beacons, and monitor services from the end-users' perspective, and their correlation to the underlying IT infrastructure. Beacons are set to perform user flows that are representative of normal application usage, and Oracle Enterprise Manager then breaks down the response time of that user flow into its component pieces for analysis.
Within RUEI, specific applications and suites can be monitored for service test traffic and, when detected, reported via the Service tests Data Browser group. In addition, diagnostics information about monitored service tests is also available via the Service tests diagnostics facility. The procedure for configuring applications to detect service test traffic is described in Section 6.2.4, "Reporting Service Test Beacon Traffic".
In order to make use of this facility, Oracle Enterprise Manager Grid Control 11g must be installed and running within the monitored deployment environment.
When configuring your service tests within Oracle Enterprise Manager Grid Control, you should pay particular attention to the following points:
Within Oracle Enterprise Manager, when creating the beacon, the Enable Message ID Request Header check box must be checked. This is necessary in order for RUEI to be able to monitor the user flow traffic.
Within Oracle Enterprise Manager, the cookie used for session tracking within the monitored environment or application should be specified in the Advanced properties section of the service test. Specifically, within the Session parameters field of the Request part of the Test parameters section. Otherwise, sessions can become mixed.
Be aware that conditional user flows (such as a password expiry notification) may result in low reported page views and metric levels), and it is recommended that you do not use them within RUEI monitored service tests.
All service test steps must have an associated page.
When configuring your services tests, it is strongly recommended that you specify a 5-minute collection frequency. Otherwise, gaps will appear in the time-based reporting of service tests, and the total number of real-user page views may be under-reported.
When working with value lists, you can add additional columns to the displayed list. Select Show percentage or Show growth from the Values menu to add indicator columns to the displayed data. Note that availability of these options depends on the currently viewed list, and the columns are also carried forward when you view the list as a report (by selecting Open as report from the View menu).
You can also change the sort order by selecting a column header at the top of the Values list. The view changes to reflect the selected column sorted in ascending order. Click it again, and the sort order becomes descending. The order symbol within a column heading indicates the current order. An example is shown in Figure 3-6:
Within value lists, you can also right click items to open the context menu shown in Figure 3-7.
The following options are available:
Select value: adds the selected value as an inclusive filter to the Filters panel. That is, only values that match the selected value are displayed in the browser.
Exclude value: adds the selected value as an exclusive filter to the filters panel. That is, only values not matching the selected value are displayed in the browser.
You can use the Search facility to locate the incidence of strings in the currently displayed data set. This is shown in Figure 3-8.
The search facility will try to match any search pattern you specify either as a full match or as a substring. Hence, the search pattern "fire" will match the occurrences of "firefox", "x-fire", and "sefirewall", as well as, of course, all occurrences "fire". As mentioned earlier, the search is restricted to the currently displayed data. To extend the search further, you will need to modify the current view, or remove applied filters, and repeat the search. If the search did not find any matches, a pop-up dialog informs you that "No results were found".
Note:
The search facility does not support the use of wildcard characters (such as *). All characters are treated as literals. The results list is a values list and has the same functionality (see Section 3.3, "Working With Value Lists").To sort data in a graphic visualization, select the corresponding dimension from the legend beneath the graph. This is shown in Figure 3-9:
For information on sorting within a value list, see Section 3.3.1, "Changing the Sort Order".
In addition, you can use the Sorting option within the Data menu to undo any specified sorting specifications (Remove sorting), or swap the current sorting specification (Invert sorting).
When working within the Data Browser, you can use the Back and Forward icons within the taskbar (see Table 3-1) to move between your previous selections. In this way, you can undo previous actions (such as setting filters) without having to repeat your complete viewing actions. When using this facility, bear in mind the following points:
A maximum of 20 actions are remembered.
Within the diagnostics facility, the Exit diagnostics icon returns you to your position within the Data Browser immediately before you entered the diagnostics facility, and your previous actions are preserved in the selection history.
If you leave the Data Browser for another module (for example, the Configuration or Report module), your selection history is preserved on return to the Data Browser.
If you use the Back icon to undo a selection, and then perform a new selection, your selection history from that point onwards is discarded.
You can select the Reset Back/Forward history option from the View menu to reset the remembered viewing actions.
You can use the Filter panel at the top of the Data Browser window to tighten the profile of the information you want to view. An example is shown in Figure 3-10:
The first item shown in the Filter panel is always the date or period for which information is required. In the example shown in Figure 3-10, this is the year period 2007. This can be thought of as the highest-level filter, and can be changed through the calendar (explained in Section 2.4, "Using the Calendar").
After that, additional filters can be set. There are two kinds of filters: inclusive and exclusive. Inclusion filters specify that only data items that match the data value in the filter should be shown. Exclusive filters specify that only data items that do not match the data value in the filter should be shown.
For example, the filter profile in Figure 3-10 specifies that only information should be displayed for the year 2007 in which the client location was Liechtenstein, and the client browser was not Firefox.
You can define any data item within the Data Browser window as a filter by right clicking it to open the menu shown in Figure 3-7. After you have defined a filter, you are free to modify it by clicking it and using the context menu shown in Figure 3-11:
The following options are available:
Invert: changes the selected inclusive filter into an exclusive filter, and vice versa.
Invert filters(s): inverts (as described above) all currently defined filters.
Remove: deletes the selected filter.
Note:
Filters are applied in the order in which you define them. Once defined, it is not possible to change the order in which they appear in the Filter panel. To re-order them, you must remove and redefine them in the required order.Mark as report filter: the use of this option is described in Section 3.7, "Working With Filters".
Remove all: deletes all current defined filters.
Within value lists, you can select multiple values by clicking the Multiple section command button, and then clicking each required value outside of the its associated link. The selected item(s) are then highlighted. An example is shown in Figure 3-14.
After selecting the required values, you can use the toolbar at the bottom of the screen to specify whether the values should be inclusive or exclusive filters. You can also use the toolbar to invert all currently defined filters, or to remove them.
Report filters can be used with reports that you create from the Data Browser. When you specify a report filter for information you include in a report, the user opening the report can use the defined filter when viewing the report's contents.
For example, if you are viewing client location information (via the All sessions groups, and the client-location sub-group), you could create a report that allowed its users to select on client location. To define the filter, do the following:
Select a value from the displayed list of locations, and define it as a filter.
When displayed in the filter panel, right click it, and select Mark as report filter from the menu. An example is shown in Figure 3-13:
Note:
Only one report filter can be defined for each dimension. However, it is possible to define multiple report filters across different dimensions. Care should be taken when designing reports with multiple filters because it can make the report difficult to view.Select Open as report from the View menu, and finalize the structure of the required report. Notice that the selected filter is now shown within the report. An example is shown in Figure 3-14:
Highlight the filter by placing the mouse pointer over it, and select Edit filter type from the menu. A dialog similar to the one shown in Figure 3-15 appears.
Use the check box(s) shown in the Edit filter type(s) dialog to control which filters can be selected by a user when the report is opened. There will be a check box for each defined report filter. When ready, click Apply.
Save the report, as described in Section 2.9, "Creating New Reports".
When the report is opened, and a report filter has been enabled, the value selected as the report filter becomes the default selection in a list of dimension values. An example is shown in Figure 3-16:
You can export the data currently shown in the Data Browser to a wide variety of applications, such as spreadsheets. To start working with export data, open the Export window by clicking the Open as export icon, or selecting Open as export from the View menu. A new window with the current data is opened. An example is shown in Figure 3-17:
Note:
A maximum of 5000 items can be exported to Microsoft Excel.The Export window (Figure 3-17) shows the raw data that is available for export. However, you can customize how the data should be exported. To do so, right click within the export window, and select Edit. A dialog similar to the one shown in Figure 3-18 appears:
This dialog allows you to modify the order of data columns, the order in which values appear in those columns, and specify additional columns that will appear in the Microsoft Excel export.
Within the Data columns and Value columns fields, you can use the lists to add additional primary (index) columns, and the data columns that should appear within them. The exact selection of data and value columns that are available within each list depends on the view group with which you are working. For example, if you are viewing data from the All clients group, the selection of Web site/page data columns is limited to domain and Web site. However, if you are working in All pages group, additional data columns are available for such things as page content and page user flow. For a complete description of the data and value columns that are available for export within each view group, see Appendix D, "Summary of Data Items."
The Percentage check box allows you to specify whether an additional column, showing the percentage make up from the reported values, is added to the Microsoft Excel export.
The Growth check box allows you to specify whether an additional column, showing the actual increase in the reported metric, is added to the Microsoft Excel export.
You can use the Up, Down, and Remove icons next to a data column selection to control the sort order hierarchy, or to remove a data column as an index to the data. Similarly, you can use these controls within the value column field to rearrange the order in which they appear in the export.
You can save the export to a new or existing file, or append it to an existing export.
In addition to controlling how the exported data will appear, you can also specify the format in which the data will be exported. To do so, select the Download menu. The following export formats are available:
Be aware that the exported data is in Unicode (UTF-8) format.
Custom dimensions allow you to add your own user-defined dimensions to views in the Data Browser. These new dimensions are then also available for use within KPIs, as well as reports and exports. For example, you might want to add a dimension "supplier" so that you could more easily track and analyze your organization's suppliers. Using this facility, you could determine which suppliers have the highest conversion rates associated with them within key business operations, or which suppliers attract the most page views on the organization's Web site. Note that the use of problem-based custom dimensions is primarily intended for application debugging purposes.
Note:
Custom dimensions can be page, session, function, user flow, or problem -based. Because KPIs are based on real-time data, session-based custom dimensions cannot be used as metrics within KPIs. However, page-based custom dimensions can be used as KPI filters.Reporting of Custom Dimensions
Each custom dimension has a unique name, and is page, session, function, user flow, or problem-based. This determines the Data Browser groups within which it is reported and, as explained in the following section, how dimension information is preserved between page views. The reporting of custom dimensions within Data Browser groups is highlighted in Table 3-3.
Table 3-3 Reporting of Custom Dimensions Within Data Browser Groups
| Source | All pages | Key pages | All sessions | Failed pages | Failed URLs | Slow URLs | All functions | Failed functions | (named) Suite | URL diagnostics | All user flows |
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Page |
X |
X |
X |
X |
X |
X |
X |
||||
|
Page (session aware) |
X |
X |
X |
X |
X |
X |
|||||
|
Session |
X |
X |
X |
X |
X |
||||||
|
Function |
X |
X |
|||||||||
|
Problem analysis |
X |
X |
X |
||||||||
|
User Flow |
X |
Be aware that when reviewing live session-based custom dimension information (that is, during the same day as the session), the reported user name can change. When viewing the same information the multiple days, the reported user name is based on the last one detected during the session.
Preserving Dimensional Information
As previously explained, the entity (page, session, function, user flow, or problem) upon which a custom dimension is based, determines how information within the dimension is preserved between page views. This section provides a detailed explanation of how the selected scheme effects the reporting of custom dimension information. This is based on the presentation of example visitor sessions. Each example session refers to a monitored Web site containing a sales catalog. To capture information about which collections within the catalog visitors are viewing, a custom dimension with three levels is defined. These three levels are derived from three arguments: a, b, and c.
When a custom dimension is specified as page-based, the values shown in Table 3-4 are reported.
Table 3-4 Page-Based Custom Dimension Information Retention
| Input | Dimension level | ||
|---|---|---|---|
|
1 (a) |
2 (a » b) |
3 (a » b » c) |
|
|
a=men |
men |
men » none |
men » none » none |
|
a=men, b=coats |
men |
men » coats |
men » coats » none |
|
a=men, b=coats, c=winter |
men |
men » coats |
men » coats » winter |
|
a=men, b=hats |
men |
men » hats |
men » hats » none |
|
a=men, b=hats, c=trilby |
men |
men » hats |
men » hats » trilby |
|
a=children |
children |
children » none |
children » none » none |
Notice that when using this scheme, only the information available within the current page view is used when reporting on the custom dimension levels. No information is inherited from previous page views.
When a custom dimension is specified as page (session aware)-based, the values shown in Table 3-5 are reported.
Table 3-5 Page (Session Aware)-Based Custom Dimension Information Retention
| Input | Dimension level | ||
|---|---|---|---|
|
1 (a) |
2 (a » b) |
3 (a » b » c) |
|
|
a=men |
men |
men » none |
men » none » none |
|
(a=men,) b=coats |
men |
men » coats |
men » coats » none |
|
(a=men,) (b=coats,) c=winter |
men |
men » coats |
men » coats » winter |
|
(a=men,) b=hats |
men |
men » hats |
men » hats » none |
|
(a=men,) (b=hats,) c=trilby |
men |
men » hats |
men » hats » trilby |
|
a=children |
children |
children » none |
children » none » none |
Notice that now when custom dimension level information is not available on a page view, the information is inherited from the previous page view. This inheritance is indicated with the use of brackets. The information between the brackets is not available in the current page view, and so is derived from the previous page view.
When a custom dimension is specified as session-based, the values shown in are Table 3-6 are reported.
Table 3-6 Session-Based Custom Dimension Information Retention
| Input | Dimension level | ||
|---|---|---|---|
|
1 (a) |
2 (a » b) |
3 (a » b » c) |
|
|
b=coats |
none |
none » coats |
none » coats » none |
|
b=coats, c=winter |
none |
none » coats |
none » coats » none |
|
c=winter |
none |
none » none |
none » none » winter |
|
...... |
none |
none » none |
none » none » none |
Notice that in the above example, no inheritance occurs for custom dimension information. In addition, be aware that only one page view can be reported using this scheme. This is the first page view for which custom dimension information is available. In this case, that is the first page in the viewing history (none » coats » none). All custom dimension information on other page views is discarded. Note that Table 3-4, Table 3-5, and Table 3-6 each refer to a single session.
Translations for Custom Dimensions
Optionally, you can also define a set of translations for each unique source value reported for the dimension. For example, you could define the service-based custom dimension "server ID" with the associated translations shown in Table 3-7:
Table 3-7 Example Custom Dimension Translations
| Value | Translation |
|---|---|
|
178349 |
Business Partnerships |
|
561808 |
Newsletter and Events |
|
405969 |
Catalog |
|
969533 |
Payment Handling |
To define a custom dimension, do the following:
For function-based custom dimensions, select Configuration, then Services, and then Custom dimensions. For application-based custom dimensions, select Configuration, then Applications, and then Custom dimensions. A list of the currently defined custom dimensions appears. A maximum of two user flow, and a maximum of five page or session-based custom dimensions can be defined. For function-based custom dimensions, the maximum is 10. Click the New dimension command button. The a dialog similar to the one shown in Figure 3-19 appears.
Specify a unique name for the new dimension. Note that in displays (such as within the Data Browser or a report) that feature the defined custom dimension, the dimension's name is appended with an asterisk (*).
Use the Based on menu to specify the entity type upon which the dimension should be based. For function-based dimensions, this is automatically selected as function, and cannot be modified. For application-based dimensions, you can selected this to be page, page (session aware), session, user flow, or problem analysis. The use of these options is explained in a previous section. Note a maximum of five page, session, user flow, or problem-based custom dimensions, and a maximum of 10 function-based custom dimensions, can be defined.
Use the Number of levels menu to specify the level of dimension information that should be retained. By default, only one level of information is retained for the defined custom dimension. However, you can use this facility to build a hierarchy of retained session information. For example, you might want to capture information about the user's location using the three levels of country, region, and city. A maximum of four levels is supported.
Within the displayed Level tabs, specify a name for the dimension level. Use the Source type menu and Source value field to specify the scope of the search for the dimension, and whether the search should use an XPath expression, a header, the cookie, a URL argument (request), or a custom tag or function. More information about using XPath queries is available in Appendix F, "Working with XPath Queries". Note if the source is a URL argument, the raw (original) input is used. However, in the case of an HTTP header, only ASCII input is allowed. Non-ASCII characters are replaced by an underscore (_) character when reported. For more information encoding support, see Appendix G, "Working With National Language Support".
If the custom tag or custom function options are selected, the tag or function name must be specified within the Source value field. Note that, in the case of a custom function, only the first parameter is used, and it must be enclosed in single or double quotes. For example:
wiViewState("wi_menu_main_menu");
More information about how custom tags and functions are interpreted within pages is available in Appendix A, "Tagging Conventions".
When ready, click Save. An overview of the defined custom definition (similar to the one shown in Figure 3-20) appears.
Optionally, you can also define a set of translations for each unique source value reported for the dimension. To do so, click « Add new translations ». The dialog shown in Figure 3-21 appears.
Specify the required source value and its translation. When ready, click Save.
Note that if the list of imported translations is very large, you can use the controls in the toolbar at the bottom of Figure 3-20 to scroll through the displayed list. In addition, you can use the search facility to locate a required translation. The search string can be specified in terms of either a source value or a translation. The use of wildcard characters (such as *) is not supported, and all characters are treated as literals.
Importing Lists of Translations
Instead of separately defining each translation, you can click the Upload list icon within the toolbar (at the bottom of Figure 3-20) to import a file containing a list of translations. The dialog shown in Figure 3-22 appears.
Figure 3-22 Upload Custom Dimension Translations
Use the Browse button to locate and select the required file. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Appendix G, "Working With National Language Support". If an unsupported encoding is encountered, or the transcoding fails, an error is reported.The file may only contain one translation per line, with source values and translations tab separated. When ready, click Merge.
Note:
You can also use the custom dimension facility to redefine the functionality of standard dimensions.Fallback Values Reported For Custom Dimensions
Within custom dimensions, two fallback values can be reported:
None: indicates that the source defined for the custom dimension was not found within the page or function call.
Unknown: indicates that the defined source was defined after the cited period for the page or function call. For example, if a custom dimension is defined at 1 PM on a Monday, the daily view will show "unknown" for the period before 1 PM. Similarly, within the week and month views, it will be reported for the period before the custom dimension was defined.
To remove a custom dimension, do the following:
For application-based dimensions, select Configuration, then Applications, and then Custom dimensions. For function-based dimensions, select Configuration, then Services, and then Custom dimensions. A list of the currently defined custom dimensions appears. Right click the required custom dimension, and select Remove from the menu.
If the custom dimension is used as a filter in a KPI or a report, you are warned that deleting the custom dimension also results in the deletion of the associated KPI or report. Click Yes or No.
The diagnostics facility provides a powerful means for Application Managers and IT technical staff to perform root-cause analysis of operational problems. It supports session performance breakdown, including the impact of failing pages and hits on sessions, the full content of each failed page, and the relationship between objects, page views, and sessions. Diagnostics for Web services is also available to investigate failed function calls.
When problems are identified, the diagnostics facility offers a means to drill-down into RUEI's rich data structure and both assess the impact of the problem on your Web site's visitors and Web services, and obtain direct insight into possible causes.
Important:
In order for session replay data to be available, session recording must be enabled. This is described in Section 8.4, "Masking User Information".In addition to the information described above, RUEI also offers the opportunity to track exactly what error messages visitors to the monitored Web site receive, and when. With this ability to recreate application failures, you can accurately and immediately eliminate annoying and problematic parts of your Web pages.
Understanding Session Reporting
Information about user sessions is reported within the diagnostics facility as user records. It is important to understand that information is reported using a resolution of five minutes. The properties associated with it, such as IP address and user ID, are effectively snapshots taken at the end of the 5-minute period. Note that while the value of these properties can potentially change during the 5-minute period, it is their values at the end of the period that are reported.
Using the Diagnostics Facility
To locate the diagnostics information you require, do the following:
Select Browse data, and select the group from which you want to start. Diagnostics information is available from within the All sessions group, the Service test group, the Failed URLs, pages, and functions groups, as well as the accelerator-specific groups (such as Oracle E-Business Suite and Siebel). Click the required diagnostics option. Note the name of the option reflects the selected group. For example, Session diagnostics, Page diagnostics or URL diagnostics. A diagnostics panel similar to the one shown in Figure 3-23 appears.
Use the Calendar controls (described in Section 2.4, "Using the Calendar") to select the required period. The selected viewing range must be a single day (or less). If you attempt to search outside this limit, an error is reported. The availability of replay content is determined by the associated Collector retention policies (described in Section 9.6.2, "Defining Collector Data Retention Policies").
Use the search facility to locate the required user record(s). The specific criteria available depends on the selected group. The available search criteria are shown in Table 3-8. Note that only the first 100 items are listed within each criteria menu. Therefore, if the required item is not listed, you can use the Search icon to the right of the appropriate criteria field to locate and select it. The Exit diagnostics icon returns you to your position within the Data Browser immediately before you entered the diagnostics facility.
Table 3-8 Diagnostics Search Criteria
| Data Browser Group | All sessions | Service tests | Failed pages | Failed URLs | Slow URLs | E-Business Suite | Siebel | PeopleSoft | JD Edwards |
|---|---|---|---|---|---|---|---|---|---|
|
Application name |
• |
• |
• |
• |
• |
• |
• |
||
|
User ID |
• |
• |
• |
• |
• |
• |
• |
||
|
Client IP address |
• |
• |
• |
||||||
|
Service name |
• |
||||||||
|
Beacon name |
• |
||||||||
|
Object URL |
• |
• |
|||||||
|
Object delivery |
• |
||||||||
|
Object URL |
• |
||||||||
|
Client network |
|||||||||
|
EBS responsibility |
• |
||||||||
|
Siebel method |
• |
||||||||
|
PeopleSoft node name |
• |
||||||||
|
JD Edwards form |
• |
Optionally, you can specify additional search criteria using the Add more filters facility. As with the primary search criteria, the additional search filter options depends on the selected group. Be aware that all criteria specified for the search must be meet for matched user records to be reported, and that exact searching is used. All strings are regarded as literals, and the use of wildcards is not supported.
Optionally, you can specify the order in which matched user records are reported through the Search result order facility. When ready, click Search. The results of the search are shown in the main part of the window. An example is shown in Figure 3-24.
Use the controls in the toolbar at the top of the window to scroll between result pages. A maximum of 100 user records are listed per page. You can select a specific user record from the displayed list by clicking it.
Optionally, use the Order menu to specify the order in which matched user records are listed. In addition, you can use the Dimension level and Value menus to apply additional filters to the displayed list. When ready, click Add. The options available within the Dimension level menu depends on the selected group.
Note that you can select the Export session option from the user record context menu shown in Figure 3-24. The use of this facility is described in Section 3.10.3, "Exporting Full Session Information".
After selecting a user record, the View part of the panel in the left-hand side of the window allows you to view information about the selected user record. Use the Pages, Object, and Info items under the Session part to view information concerning specific aspects of the selected user record. An example is shown in Figure 3-25.
Session pages are grouped so that when expanded their associated objects can be viewed. The overview shows the pages (and their times) recorded within the selected user record. Icons indicate slow or failed objects, page loading satisfaction, whether the pages are key pages, and whether replay content for them is available. The use of the Replay viewer is described in Section 3.10.1, "Replaying User Sessions".
Note you can use the Include/Exclude spurious objects icon within the toolbar to control whether hits not directly associated with a reported page are included in its displayed list of objects. This facility is particularly useful in the identification of problem objects that have an extremely long load time. Normally, these objects would not have associated pages and, therefore, would not be listed in the session page report.
The Export session pages command button allows you to export a summary of the currently selected user record to Microsoft Excel. The use of this facility is explained in Section 3.10.2, "Exporting Session Pages to Microsoft Excel".
You can click the Pages or Objects option under the View part of the panel to review a summary of pages viewed by the visitor or the objects within them. An example is shown in Figure 3-26.
Figure 3-26 Example Page Properties Dialog
Within the displayed page history, the full page content, as well as the underlying HTML code of the messages received by the server and client are also available. Be aware that the reported contents are subject to the currently defined masking options for HTTP protocol items. Detailed application and session-related information about the page or URL is available via the Info option. An example is shown is shown in Figure 3-27.
When ready, you can click the Remove icon beside the selected user record. You are returned to the diagnostics window shown in Figure 3-24. From here, you can select and drill down into other user records.
Masking Sensitive Information Within the Diagnostics Facility
As mentioned earlier, the availability of information (such as header or URL information) within the diagnostics facility can be controlled through the appropriate HTTP protocol item masking facility. This is described in Section 8.4, "Masking User Information".
When available, you can click the Replay icon beside a viewed page to replay the complete user session. This provides the opportunity to review each page viewed by the visitor during the session, together with any reported error messages. An example is shown in Figure 3-28.
The replay details are shown in a new window which is the same size as the main window. Note that when selected from the main Session Diagnostics window (shown in Figure 3-24), the complete session page history is available on the left-hand side of the Replay window. However, if selected by clicking the Replay icon for a page within a selected user record, the displayed page history starts from the point of the selected page.
The controls below the page listing allow you to navigate through the page history. The Page information section indicates the currently highlighted page's loading satisfaction, whether it is key page, and whether it contains an error.
If a viewed page contained HTTP form elements, these and the visitor replies are reported in the Page events panel. Unnamed elements are reported as "NO_NAME_number" (where number is incremented for each unnamed element). Hidden form elements are also reported. Be aware that the replies made by a visitor to form elements is derived from the request body of the next page in the session page view history. Therefore, if the visitor switched context to another page between the request and response pages, the user response cannot be extracted and reported.
The status bar at the bottom of Figure 3-28 provides information about the session user ID, each page's recorded timestamp, loading time, number of objects and (in the case of static pages) an indication that reported pages are retrieved from the live source (such as the application server).
The HTTP content command button on the toolbar allows you to view the actual request and response content of the currently selected page. An example is shown in Figure 3-29.
Note that external JavaScript files can also be viewed by clicking the link within the page content. The reported content of these files is retrieved from the live source (for example, an application server).
If no Replay icon is available beside a page in the displayed viewing history, this indicates that the page's content is not available. This can be because the information is expired due to data storage constraints, or because the viewed page was a static page. In the case of the latter, you can still view the static page's content by highlighting the page immediately before or after the static page in the viewing history, and via this page, view the static page's content.
Be aware that the reported content for the objects on a static page is retrieved from the live source. Hence, if the live source is not available for any reason, the page's content may not be correctly reported. In addition, data masking and JavaScript execution rules are not applied to any page contents retrieved from the live source. The page contents are shown "as is". Note that if a static page was cached at the client, an earlier complete page fetch for any session is used for the preview. Therefore, depending upon the configuration of the monitored Web site, this may have been modified since the visitor actually viewed the page. For example, a page listing current stock market prices. When live source data is reported, this is indicated in the Replay status bar.
JavaScript Execution Within the Replay Viewer
Pages viewed by visitors can contain inline JavaScript code. The application definition facility allows you to specify how execution of this JavaScript code should be handled within the replay facility. This is fully described in Section 6.2.17, "Controlling JavaScript Replay Execution". In addition, be aware that suites (such as Siebel and PeopleSoft) have preconfigured JavaScript execution rules that optimize their reporting within the Replay viewer.
You can export a summary of the pages within the currently selected session to Microsoft Excel. To do so, do the following:
Select the required session using the procedure described earlier. Click the Export session pages command button. Depending on how your browser is configured, you are either prompted to specify the tool with which to open the file directly (by default, Microsoft Excel), or it is immediately saved to the defined default location.
Within Microsoft Excel, you can view and edit the generated file. An example is shown in Figure 3-30.
Figure 3-30 Example Microsoft Excel Session Pages Export
The exported page view history and session summary can be used to compile sets of real-user sessions. For example, to be used as the basis for testing or performance analysis.
In addition to viewing session information, you can also export complete session contents to external utilities for further analysis or integration with other data. For example, this offers the opportunity to use complete real-user sessions as the basis for test script generation. Test platforms, such as Oracle Application Testing Suite (ATS), can easily be configured to generate automated test scripts for an application's most commonly encountered usage scenarios.
In addition, this facility can also be used to support powerful root-cause analysis. Complete user session information can be provided to application or operations specialists to help identify unusual or difficult to isolate issues. Sensitive information within the exported data is masked according to the actions defined in the HTTP protocol item masking facility. This is described in Section 8.4, "Masking User Information".
To export session information, do the following:
Locate the required session and select the Export session option from its context menu. This is shown in Figure 3-31.
Alternatively, within the Replay facility, select the Session menu, and then select the Export session option. In either case, a dialog appears prompting you to confirm exportation of the selected session.
It is important to understand that the exported data may contain sensitive information. It is recommended that you carefully review the session's contents to ensure that sensitive information has been correctly masked. To confirm export of the selected session, click Yes.
Depending on how your browser is configured, you are either prompted to specify the location to which the zip file should be saved, or it is immediately saved to the defined default location.
In order for the session export files to be created correctly, you should ensure that:
The exported session is not older than the Full Session Replay (FSR) setting (as described in Section 9.6.2, "Defining Collector Data Retention Policies").
The URL prefix masking setting is specified as "Complete logging" (as described in Section 8.4, "Masking User Information").
In addition, it is recommended that you verify the exported content files (described in the following section) are present before attempting to import an exported RUEI session into an external utility.
Understanding the Structure of the Exported Data
The exported session zip file contains the following files:
data.tab: contains the direct (raw) hit information for the selected session extracted from the Collector log file.
content_hitno.tab: contains the complete (raw) content information for the indicated hit. There is a file for each hit within the data.tab file that has content. For example, if the third and sixth hits had content available for them, two files would be created: content_3.tab and content_6.tab. An example of a hit file is shown in Figure 3-32.
The first line within the file (in this case, 589 68 313 221) contains four integers that indicate respectively the length (in bytes) of the request header, the request body, the response header, and the response body. In addition, note how the user's password has been masked in the file.
Note:
The log files used as the basis for creating exported session files are also used internally by RUEI. The format and contents of these files is subject to change without notice.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
