|
|
This chapter provides information on accessing and working with the Analytics Administration console. It includes the following topics:
To access Analytics Administration:
This section contains the following topics:
The Runtime Settings page lets you configure timeout periods, enable portlet view and response time data capture, and limit the number of rows in exported reports. The timeout settings that you specify on the Runtime Settings page are only for Analytics reporting purposes; there is no relationship between these timeout settings and other portal timeout settings.
The following table describes the timeout settings that you can configure.
The following table describes the portlet view/response time settings that you can configure.
Select the check box to enable the collection of portlet view and response time data. Portlet view data is reported on the Portlet Views console page. Response time data is reported on the Portlet Metrics - Response Time console page. By default, the collection of portlet view and response time data is disabled.
Portlet view and response time data only appears in reports when running Analytics on version 5.0.4J/5.0.5J or 6.0 (UNIX and Windows) of the portal.
For guidelines on capturing portlet view and response time data, see Restricting Portlet View Data.
|
The following table describes the export report settings that you can configure.
The Security Settings page lets you control the data that users can access in Analytics reports. On this page, you can add and remove roles, and launch the Edit Role window to make changes to the role (changes include adding and removing role members, capabilities and user properties to and from roles).
A user's roles and capabilities are retrieved by Analytics when the user's session is being established. If you make changes to a user's roles or capabilities when that user is logged in, that user's access to Analytics data does not change until they log off or their session expires.
The Super Users role is delivered with Analytics and, by default, is added to Analytics Administration. The Super Users role grants portal Administrators Group and Administrator user access to all capabilities and user properties.
| Notes: | For new Analytics installations, you must run the User Property Sync Job before assigning user properties to the Super Users role. The User Property Sync Job exists in the Analytics Jobs subfolder within the Analytics subfolder of the Admin Objects directory. |
| Note: | Removing the Super Users role permanently deletes it from the system. To add the Super Users role again, you must re-create it. |
The following table describes the capabilities that you can assign to roles.
Lets the role use the All/Top/Bottom display options. The reports that include these display options are: Summary Metrics - Pages, Community Metrics - Traffic, Community Metrics - Response Time, Portlet Metrics - Usage, Portlet Metrics - Views, Portlet Metrics - Response Time, Other Metrics - Documents, Other Metrics - Projects, and Other Metrics - Content Items.
|
|
This section discusses the configuration of Analytics Administration's Partition Settings page. For guidelines on archiving and restoring partitions in your Analytics database, see Archiving and Restoring Partitions.
Analytics data is segregated into month-by-month partitions in the database. The Partition Settings page lets Portal Administrators specify the number of data partitions that are accessible to Analytics reports. The Analytics Engine regularly scans each data partition that is accessible. For this reason, you can have more control over system performance by limiting the number of accessible partitions to only those that are needed.
At the beginning of each month, the system creates a new partition and stores all new Analytics data in that partition until the month ends.
| Note: | You also use the Partition Settings page to refresh database views after archiving or restoring partitions. To do so, click Finish. If you do not refresh the database views, Analytics reports will fail. |
The Scrolling View Window, which you configure on the Partition Settings page, is a rolling database view that changes month-to-month. For example, suppose that on August 5, you enable the Scrolling View Window and set its size to 4 months. The following occurs:
The Scrolling View Window makes data from 4 months available: May, June, July, and August. (Note that even though the month of August has not completed, the Scrolling View Window makes data from the August partition available so that the most current data appears in Analytics reports).
On September 1, the Scrolling View Window scrolls one month forward and makes data from the June, July, August, and September partitions accessible. Though the Scrolling View Window removes the May partition from view, the partition and its data is still stored in the database. In this example, if in December of the same year the Portal Administrator wanted to make the data from the May partition available to reports, he or she would increase the Scrolling View Window size to 8 months so that it includes the May to December time frame.
To set the number of months, that are accessible to Analytics reports, first enable the Scrolling View Window, then specify the number of months: between 3 and 60. Data from monthly partitions that do not fall within the Scrolling View Window size is made unavailable to Analytics reports.
| Note: | If you do not enable the Scrolling View Window, all data from all partitions is accessible to Analytics reports. |
At any time, you can click Preview on the Partition Settings page to view a chart that displays a representation of all partitions and indicates whether they are available or unavailable to Analytics reports:
The Event Registration feature lets Portal Administrators and developers register custom portal and non-portal events that are sent to Analytics using the OpenUsage API. Event data is saved to the Analytics database, which can then be queried for reporting to a non-portal application. This feature's user interface includes the Event Registration and Create Event pages.
Use the Event Registration page to:
| Note: | This topic only discusses the Event Registration user interface. To utilize the full capabilities of this feature, you must use the OpenUsage API. For details on using the OpenUsage API, see the document Using the AquaLogic Interaction Analytics OpenUsage API at http://dev2dev.bea.com/pub/a/2006/08/openusage-analytics.html |
An event typically defines one user action that you would like to capture. Each event is composed of several event parameters, which defines the various kinds of data that is generated by the event. By default, each event includes the USERID, TIMEID, VISITID, and OCCURRED event parameters (for more details on these parameters, see Delivered Parameters).
Event Registration also lets you create your own event parameters to capture data that is not defined by the delivered defaults. To capture data of type Date, Integer, or Float, simply create an event parameter for that data type. To capture data of type String, you must create a dimension to define this data. After you create the dimension, you must create a new event parameter of type String, and associate it to the dimension that you created.
| Note: | We recommend that you do not create too many dimensions, since they slow down the speed of data collection and reporting. |
Event Registration also lets you use dimensions from your own application's tables. To do so, create a parameter of type Integer. Then, using your database schema, map the parameter to the ID column in your dimension table.
The Managed Dimensions section of the Event Registration page lets you create custom dimensions to define data of type String.
To use a dimension, you must associate it to an event parameter on the Edit Event page. You can associate a dimension to multiple event parameters and use that dimension in multiple events.
Dimension names can be up to 20 characters in length and can only include letters, numbers, spaces, and underscores.
The names that you create only define how dimensions appear on the Event Registration page. In the database, custom dimension tables use the following naming convention: ascdim_<dimension_name> (spaces in dimension names are replaced by underscores).
| Note: | You cannot remove or change the name of a dimension after clicking Finish on the Event Registration page. To do so, contact the Support Center for assistance. |
To store only unique values in this dimension's table, check Unique?.
The Create Event page lets you define the event name and parameters that are included in the event. After you define the event and its parameters, click Finish to save an event and create its fact table in the database. Access the Create Event page by clicking Add on the Event Registration page.
| Note: | After you save an event, you cannot change the names of the event and its parameters; you also cannot delete parameters from an event. To do any of these, contact the Support Center for assistance. You can, however, add parameters after saving an event. |
Event names can be up to 14 characters in length and can only include letters, numbers, spaces, and underscores.
| Note: | You must set the OpenUsage API to send data to the fact table using the event name that you specified on this page, not its column name in the database. |
Table names are read-only, and define the name of the fact table that will store the event's data. Custom event tables use the following naming convention in the database: ascfact_<event_name> (spaces in event names are replaced with underscores). For complete details on the fact tables that are delivered with Analytics, see Working with Delivered Fact Tables.
Parameter names can be up to 14 characters in length and can only include letters, numbers, spaces, and underscores. Use this parameter name when passing parameters with the OpenUsage API.
| Note: | You cannot remove or change the name of a parameter after clicking Finish on the New Event page. To do either of these, contact the Support Center for assistance. |
The following table describes the parameters that are delivered with Analytics which are, by default, included in every event:
|
|||
To begin saving an event's data, select the check box next to an event on the Event Registration page and click Enable. By default, the BEA AquaLogic Interaction Analytics Collector Service starts saving the event's data 30 minutes after you click Enable.
To stop saving an event's data, select the check box next to an event on the Event Registration page and click Disable. You can edit events even when they are disabled. By default, the BEA AquaLogic Interaction Analytics Collector Service stops saving the event's data 30 minutes after you click Disable.
Users who have access rights to the Analytics Administration web service have the ability to access the Analytics Administration console by way of its URL, even if these users are not administrators (administrators have access to the Analytics Administration console by way of the portal user interface).
To prevent users from accessing Analytics Administration by way of its URL, remove the users' access rights to the Analytics Administration web service. For details, see Administrator Guide for BEA AquaLogic Interaction (Plumtree Foundation).
If you want users to access Analytics Administration by way of its URL, you must grant these users (at minimum) Read access to the Analytics Administration web service.
|