| Oracle® Real User Experience Insight User's Guide Release 4.5.2 for Linux x86-64 Part Number E14990-02 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 4.5.2 for Linux x86-64 Part Number E14990-02 |
|
|
View PDF |
This chapter describes how to identify the pages to be monitored. In particular, how to define the Web pages for which you want additional information to be available, the logical sequence of pages in transactions to be monitored, and those pages that should be monitored for the occurrence of specific text strings. This can only be performed by users with Analytical level access.
Page identification within RUEI is based on applications. Essentially, an application is a collection of Web pages. This is because pages on a Web site are typically bound to a particular application. Each page within an application has an assigned name, and belongs to a group. For example, "MyShop » Contact » About us" refers to the About us page in the Contact group, within the MyShop application.
Each application has a page naming scheme associated with it, which defines its scope. This can be specified in terms of a partial domain name, URL structure, or a combination of both of these. A page-naming scheme (such as page tagging or the title part of the HTML page) can also be specified to refine the application definition.
For each page that the system detects, it uses the available application definitions to assign a name to it. Note that information about any pages that could not be identified using these definitions is discarded and, therefore, not available through reports and the Data browser.
In addition to automatic detection, application pages can also be defined manually. This is particularly useful in the case of an inconsistent URL structure, or where identified pages contain sub pages, or you want to assign a different name to the one assigned automatically to it by the application. Note that these manually defined pages take precedence over pages identified automatically through application definitions.
The structure of the currently defined applications, their groups and pages, are visible by selecting Configuration, then Applications, and then Applications. An example is shown in Figure 6-1.
To define applications, do the following:
Select Configuration, then Applications, then Applications, and click New application. The Configure new application dialog shown in Figure 6-2 appears.
Specify a name for the application. This must be unique across suites, services, and applications. Note that applications cannot be renamed later.
Use the remaining fields to specify the scope of the application. This is defined in terms of partial page URLs. Note that as you enter this information, you can see the effect of your definition through the Filter preview column.
The highest level filter is the domain. For example, the domain "myshop.nl" would only find pages from the Dutch Web site. However, "myshop" would also find pages from other domains. You can specify a partial URL instead of, or to refine, a domain.
It is not possible to specify an application name and leave all the other fields blank. That is, a blank filter. In addition, the use of wildcard characters (such as *) is not supported. All specified characters are interpreted as literals.
Important:
Filter definitions must be mutually exclusive across applications, suites, and services. For example, do not define an application filtered on the domain "us.oracle.com" and then a second application filtered on "us.oracle.com/application_servlet". The use of non-mutually exclusive filter definitions can lead to unpredictable results.You can also specify an argument within the partial URL that must be matched. Note that if you want to use this facility, both the argument and argument name must be complete in order for them to be matched to found page URLs. This is, partial matching is not supported. When ready, click Next. The Application page-naming wizard shown in Figure 6-3 appears.
Figure 6-3 Application Page-Naming Scheme
This dialog allows you to specify the automatic page-naming scheme used for pages within the application. Only one scheme can be specified per application. The following option groups are available:
Page tagging: specifies that a either a standard scheme (such as Coremetrics) or a custom scheme is being used. In the case of a custom scheme, you are required to specify the name of the tag. The HTML title option specifies that the text found within the page's <title> tag should be used to identify the page. Note if this is not defined on the page, the <H1>, <H2>, and <H3> heading tags are used. The structure and processing of the generic page tagging schemes supported by RUEI are described in Appendix A, "Tagging Conventions."
Page URL: specifies that pages are identified on the basis of their URL structure. The following options specify which portion of the URL is used:
URL-directory: use only the directory. The various parts of the URL are highlighted in Figure 6-4.
Base-URL: use the main directory and file name (without the file extension).
Full-URL: use the main directory, the file name (without the file extension), and the configured arguments. If you select this option, you are prompted for arguments that you want included in the page name. Within the dialog box, multiple arguments should be separated with an ampersand (&) character. For example, if the frmAction parameter has been defined, the URL shown in Figure 6-4 will result in the page name myshop » shop » NL index buy.
Server response: specifies that pages are identified on the basis of an XPath expression applied to the server response. For more information on the use of XPath expressions, see Appendix B, "Cookie Structures".
Manual: specifies that the application pages will be manually defined rather than through automatic detection. Note that if you select this option, all pages associated with the application that you want monitored must be manually defined. See Section 6.2.10, "Manually Identifying Pages" for information on manually page definition. This is the default option.
When ready, click Finish. The application definition you have specified is displayed. An example is shown in Figure 6-5.
This overview provides a summary of the defined application. This includes the application's name, the page-naming scheme it uses, the page-loading satisfaction assigned to each of the application's associated pages, the number of unique pages that have so far been matched to it, and the date of the most recent page identified for it. The Identification section summarizes the match criteria currently defined for the application. This is described in more detail in the following section.
As explained earlier, each page within the system has the form application » group » name. Automatically detected pages are assigned their group and page names based on the directory structure within the URL. The first directory in the URL is assigned to the group name, and the remaining sub-directories are assigned to the page name. Note that the domain part is not used in the assigned name.
For example, the page URL http://MyShop.nl/catalog/menswear/sale.html for the application "Clothing" would generate the system page name Clothing » catalog » menswear sale. Note that slashes within the directory structure are converted to spaces.
If there are no sub-directories in the URL, then the default group "home" is assigned to the page. For example, the URL http://MyShop.nl/sale.html in the application Clothing is assigned the page name Clothing » home » sale.
Once you have defined your application, you can modify its associated page-naming scheme by clicking it and selecting a new scheme, as described earlier in this section.
Within the Identification section, you can click « Add new filter » to specify additional filters for the pages that should be associated with the application. You can also modify an existing filter definition by clicking it. In each case, you can select from the same filters as shown in Figure 6-2. The application overview is updated to reflect your additions or modifications.
In order to assess the user's experience when viewing application pages in a session, RUEI assigns a satisfaction level for each page. These are:
Satisfied: the page loads in the user browser within a specified threshold. This threshold is the page loading satisfaction threshold. For example, the page should load within five seconds.
Tolerable: the page takes longer to load than the specified threshold.
Frustrated: the page takes more than four times the specified threshold to load.
An example page load satisfaction report is shown in Figure 6-6:
Figure 6-6 Page Loading Satisfaction Report
As stated above, this assessment is based on a threshold within which pages would normally be expected to load. This threshold can be modified to fine tune the reported page load satisfaction within the Data browser. To do so:
Select the required application, and click the setting defined for the Page-loading satisfaction item. The Page load satisfaction dialog shown in Figure 6-7 appears.
Figure 6-7 Page Load Satisfaction Time Dialog
Specify the duration (in seconds) in which page loads would normally be expected to completed. The default is 4 seconds. When ready, click Save. Any change you specify takes effect immediately.
Sometimes you want to detect strings that appear on pages and have them reported as errors. For example, if a user receives the message "Your credit card has expired". Note that:
All pages within the selected application are searched for the specified error string. It is not possible to limit the search to specific pages (as it is with page content checks).
Functional errors can be specified in terms of a literal search string or an XPath expression, and whether the server response or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures".
Displayed page texts that match your specified error text strings are reported with the page content result "error string: error search string".
An example of a functional error report is shown in Figure 6-8:
Defining Functional Errors
To define a functional error string, do the following:
Select Configuration, then Applications, and then select the required application. The Application overview (similar to the one shown in Figure 6-5) appears. Click the Functional Errors tab. The currently defined functional errors are displayed. Click « Add new functional error » to define a new error, or click an existing one to modify it. The dialog shown in Figure 6-9 appears:
Specify whether the search should use a literal search string or an XPath expression, and whether the server response or client request should be searched. More information about using XPath queries is available in Appendix F, "Working with XPath Queries". When ready, click Save.
Importing Lists of Functional Errors
Instead of separately defining each site error that you want to be monitored, you can click Upload list to import a file containing a list of error messages. This could, for example, be a list of predefined application errors. The dialog shown in Figure 6-10 appears.
Figure 6-10 Upload Functional Errors Dialog
This file must be in ASCII format and contain one error message per line. There should be no blank lines in the file. Be aware that these messages will be regarded as literal strings to be searched for in the response content.
Note:
There is a delay of 10 minutes after you define a new functional error before it is reported. It is not possible to influence this delay.Within RUEI, user identification is first based on the HTTP Authorization field. If this is not found, the application's user identification scheme is used. This can be specified in terms of URLs, cookies, request or response headers, or XPath expressions. When it is not configured, RUEI will use the SSL client certificate (when available). The common name (CN) portion of it is used. If this is not found, the client ID is reported as Anonymous. To configure user identification, do the following:
Select the required application, and click the User ID tab.
Click the < Add new user > item. The dialog shown in Figure 6-11 appears.
Use the Search type menu to specify the user identification mechanism. This can be specified in terms of a literal search string, an XPath expression, or a cookie, and whether the server response or client request. More information about using XPath queries XPath queries is available in Appendix B, "Cookie Structures". When ready, click Save.
Note:
You can check the effect your user identification definition has by viewing the XLS User Information report in the Clients category. For more information on reports, see Chapter 2, "Working With Reports".The structure of the pages detected for an application are shown in the application overview on the left-hand side of the window. An example is shown in Figure 6-12:
Figure 6-12 Example Application Page Structure
Potentially, an application could have a very large number of pages associated with it. Indeed, far too many to be easily readable in the structure shown in Figure 6-12. For this reason, the structure view is restricted to those pages that have some Point of Interest (POI) associated with them. This could include the fact that the page is featured in a report or transaction, is manually named, or is part of a monitored KPI. The View list shown in Figure 6-13 allows you to control which type of pages are displayed in the structure overview.
By drilling down through the application page categories, you can locate specific pages. However, if you are working with an application with a large number of pages, it may be more convenient for you to use the page search facility. Do the following:
Select the application you want to search, and click the Search button above the application overview (see Figure 6-5). The Page search and results dialog shown in Figure 6-14 appears.
Figure 6-14 Page Search and Results Dialog
Specify the search profile you want to use to locate the required page(s). Note that the search is restricted to the current application, and page names have the structure application » group » name. 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 "home" would match occurrences of this string or any substring in the application, group, or page names. When ready, click Go.
The search results are shown in the lower part of the dialog. Click a matched page to open it. Use the backward and forward buttons to scroll between multiple pages of results.
Note:
The scope of the search includes both pages that have already been detected, and undetected pages that appear in reports and transactions.Information about each page detected for an application is available through the page Identification window. An example is shown in Figure 6-15.
The following tabs are available within this window:
Identification: specifies the page identification scheme (manual or automatic), and the conditions used to identify it.
Content check: specifies if content search strings have been defined for the page. This is fully described in Section 6.2.9, "Specifying Page Content Checks".
Reporting: lists the reports in which this page appears. Reports are fully described in Chapter 2, "Working With Reports."
Transactions: lists the transactions in which this page is defined. See Section 6.4, "Building Transactions" for more information on defining transactions.
Sometimes you want to monitor a specific page for the occurrence of a specific text string. For example, your Web application has an Order page, and at the end of a successful sale, the text string "Thank you for shopping with us" appears on the page. You can define a page content check that looks for this string on the required page. Note that if the specified text string is not found on the page, the page content check returns "configured string not found".
To define a page content check, do the following:
Select Configuration, then Applications, then Applications, and then select the required application page. The Page analysis window (shown in Figure 6-15) appears.
Click the Content check tab, and click Add check. The Add page content check dialog shown in Figure 6-16 appears.
Specify whether the search should use a literal search string or an XPath expression, and whether the server response or client request should be searched. If the XPath value is empty, then RUEI will search for the existence of the XPath expression. More information about using XPath queries is available in Appendix F, "Working with XPath Queries". When ready, click Save.
In addition to identifying pages through applications, you can also define pages manually. Note that manually identified pages take precedence over pages identified automatically through applications. This facility is very useful in the case of sub pages that cannot be identified automatically and to which you want to assign a different name. Manually identified pages are created by selecting an existing page to be the basis for the new page.
To manually identify pages, you can either define the new page from scratch, or use an existing page (automatically detected or manually defined) as the basis for the new page.
To define a page, do the following:
To define the page from scratch, select the required application in the application overview, and click the New page button. To use an existing page as a basis for the new page, select the required application page, and click the New page (based on current) button. In either case, the Manual page naming wizard shown in Figure 6-17 appears.
Note:
If the required page is not visible in the application overview for you to select, locate it using the Search button (described in Part , "Locating Page Details").Use this dialog to specify the conditions that must be met for the page to receive the assigned name. These conditions can be defined in terms of the page's partial or exact URL, content, domain, or arguments. An XPath expression can also be specified. Click Add condition for each required condition.
Note that when specifying an exact URL (for example, http://www.oracle.com/contact.html) the domain and remaining URL structure are automatically assigned to the page conditions. For example, Find in domain (oracle.com) and Find exact URL (/contact.html).
As you specify additional conditions, these are shown in the dialog. All specified conditions must be met for a match to be made. Note that conditions shown in blue can be removed by clicking them, while conditions shown in black cannot be removed. You must specify at least one condition for page identification. When ready, click Next. The dialog shown in Figure 6-18 appears.
Use this dialog to specify a group and name for the page. When ready, click Finish.
The new page's details are shown in a window similar to the one shown in Figure 6-12. You can use this window to track page detection and modify its definition.
This section is only relevant to customers using certain Oracle Enterprise architectures, such as Siebel, PeopleSoft, and E-Business Suite (EBS).
As explained earlier, page identification within RUEI is based on applications. However, if these applications are based on any of the above Oracle Enterprise architectures, then a fourth level, suite, is introduced. A suite is essentially a collection of applications, and Web pages associated with these suites have the structure suite » application » group » page.
Why Use Suites?
If you are using any of the above Oracle Enterprise architectures, it is strongly recommended that you make use of this facility. It not only saves you time in defining your applications, and makes applications within suites more compatible, but also ensures that these architectures are monitored correctly.
Creating Suites
To define suites, do the following:
Select Configuration, then Applications, and then Suites from the menu structure shown in Figure 6-19.
Important:
Suite functionality is, by default, disabled. Therefore, the option shown in Figure 6-19 is not immediately available. Packages are made available to enable it, and provide support for specific Oracle architectures. For information about package availability, please contact Customer Support or visit the Web site
http://www.oracle.com/enterprise_manager/user-experience-management.html.Click New suite. The dialog shown in Figure 6-20 appears.
Specify a name for the suite. The name must be unique across suites, services, and applications, and is restricted to a maximum of six characters. Note that suites cannot be renamed later.
Use the remaining fields to specify the scope of the suite. This is defined in terms of partial page URLs. The use of these filter criteria is the same as described in Section 6.2, "Defining Applications". Note that as you enter this information, you can see the effect of your definition through the Filter preview column. The use of blank filters is not permitted. In addition, the use of wildcards (such as *) is not supported. All specified characters are interpreted as literals. When ready, click Next. The dialog shown in Figure 6-21 appears.
Important:
Filter definitions must be mutually exclusive across suites, applications, and services. For example, do not define a suite filtered on the domain "us.oracle.com" and then another suite, application, or service filtered on "us.oracle.com/application_servlet". The use of non-mutually exclusive filter definitions can lead to unpredictable results.This dialog allows you to specify the Oracle Enterprise architecture upon which the suite is based. Currently, three architectures are supported: PeopleSoft, Siebel, and E-Business Suite (EBS)Foot 1 . When ready, click Finish. The suite definition you have specified is displayed. An example is displayed in Figure 6-22.
This overview provides a summary of the defined suite. This includes the defined page identification filter(s), the number of pages that have so far been matched to the suite, the functional errors (if any) that should be detected and recorded, and the user identification mechanism used within the suite to track visitor sessions. Each of these can be modified as required. The procedure is equivalent to that described in Section 6.2, "Defining Applications".
Uploading Configuration Files
It is strongly recommended that you run the appropriate script supplied with the package within your Oracle architecture production environment. For example, create_EBS_info.sh script. This is in order determine how these architectures have been implemented within your environment. In particular, the page-naming scheme. Do the following:
Download the script supplied with the package. See the documentation supplied with the appropriate package for further information on the use of this facility.
Run the script within your deployment environment. This script assigns an identification to the assigned page IDs within your environment. It creates a number of .txt files.
Create a .zip file from the generated .txt files.
Select Configuration, then Applications, then Suites, select the appropriate suite, and click Upload configuration. The dialog shown in Figure 6-23 appears.
Specify the name of the file generated by the script. A Browse button is available to help you locate the required file. This must be a .zip file. When ready, click Upload.
Note:
This configuration file must be uploaded for each required suite. It may only contain known (and non-empty)
.txt files. All these files must be in the root directory. That is, subdirectories are not permitted. It is important you upload the correct configuration file for the required suite, and that it is based on the actual production environment. The result of importing an erroneous configuration file is incorrect reporting.Modifying Suite Definitions
As explained earlier, a suite is essentially a collection of applications. Once you have defined your suites, you can modify its associated properties in the same way as described for applications in Section 6.2, "Defining Applications".
You should pay particular to the following:
A number of default suite-specific functional errors are defined. You should review these to reflect the requirements of your environment. The procedure is the same as described in Section 6.2.4, "Trapping Functional Errors".
A default user identification scheme is defined for each suite. You should review this to reflect the requirements of your environment. The procedure is the same as described in Section 6.2.5, "Defining User Identification".
In addition to identifying pages through suites, you can also define pages manually. The procedure is the same as described in Section 6.2.10, "Manually Identifying Pages". However, you cannot define the new page from scratch. You must use an existing page as the basis for the new page.
A transaction is a collection of pages that define a logical task. For example, a ferry booking application might have the following pages defined for the transaction booking:
Route and date details.
Passengers and vehicle details.
Payment details.
Confirmation.
This facility gives you far greater insight into how visitors experience your Web pages. For example, you might notice that 80% of visitors who start the above transaction fail to complete it while on the last page. This might indicate that there is something visitors find confusing or annoying about that page.
In order to facilitate administration, transactions are classified into groups. For example, you could define separate groups for bookings, requests for brochures, or job applications.
To define a new transaction, do the following:
Select Configuration, then Applications, and then Transactions. The currently defined transaction groups are displayed. Click New transaction. The dialog shown in Figure 6-24 appears:
Specify a name for the transaction, and the group in which it will be stored. Note that you can click the Add group button to create a new transaction group. In addition, specify the first step in the transaction. Each step in a transaction must have a unique name. Use the Page name field to specify the page used in step. Note that you can click the Search icon to the right of the Page name field to search for a required page. For information about applications, see Section 6.2, "Defining Applications". When ready, click Save. The new transaction and its first step are listed, as shown in Figure 6-25.
Note:
Within the Page name field, although it is possible to enter the page name directly, it is strongly recommended that you select it from the list. This prevents the risk of entering a non-existent page name. However, for performance reasons, a maximum of 500 pages are listed. If the required page is not listed, you can enter it manually in the format application » group » page. The separator character (») can be produced with the key sequence Alt 0187. If you enter the page name directly into the field, it is strongly recommended that you review the application overview (shown in Figure 6-1) to ensure that it is correctly specified.Use this window to define the remaining steps in the transaction. Note that an individual step can be made up of several pages. For example, in a payment method page, you may have a separate page for each available payment method (such as credit card, bank transfer, and so on). Click Add step/page to define additional transaction steps or pages. The dialog shown in Figure 6-26 appears.
Use this dialog to create transaction steps or specify additional pages for existing steps. Note that you can click the Search icon to the right of the Page name field to search for a required page. When ready, click Save. You are returned to the transaction definition shown in Figure 6-25.
Repeat the above procedure for each required transaction step.
To modify an existing transaction, do the following:
Select Configuration, then Applications, then Transactions, and click the required group and transaction. The transaction definition appears similar to the one shown in Figure 6-27.
Use the menu available under transaction steps to change their order in the transaction, or to rename or delete them. You can also use the Add step/page button to extend the existing definition with additional steps or pages.
Note:
Information about the transactions you have defined is available through the Transaction group of reports. For more information on reports, see Chapter 2, "Working With Reports."Transaction steps are correlated within their defined sequence. Hence, it is possible for RUEI to detect when visitors go back and forth between transaction steps, and ensure that the page visit is only recorded once. However, if visitors view pages out of the defined sequence, this can lead to inaccurate information.
Transaction completion is calculated by comparing the number of page visits within a session to the first transaction step to the number of page visits to the last transaction step. A sample transaction funnel is shown in Figure 6-28.
Therefore, in order to obtain accurate transaction information, it strongly recommended that you carefully review the design of all transaction pages within your Web environment. In particular, you should ensure that:
All transactions are designed in such a way as to ensure complete execution of all the defined steps. That is, visitors are required to visit all steps to complete the transaction. Furthermore, it should not be possible for visitors to enter or leave the transaction funnel through any means other than the designated path.
It is not possible for visitors to skip transaction steps. For example, through the use of bookmarks or hyperlinks on marketing material. In addition, avoid the use of your Home page in transaction definitions because, typically, visitors can easily skip it.
Reporting Transaction Information
Be aware that when a user starts a transaction, if the user is idle for longer than the defined session idle time (by default, 15 minutes) without completing it, the transaction is regarded as having timed out, and is reported as failed. If the user then continues with the transaction and completes it in the same session, this is not recorded as a completed transaction. For this reason, if you have a back-office system tracking transaction completions, you may notice that the number of completed transactions it reports is higher than that reported by RUEI.
It is recommended that you design your transactions to be short as possible in order to minimize the chance that users time out during transaction.
Footnote Legend
Footnote 1: The options available for selection depend on the packages you have installed.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
