# Administrator Guide

# Using Analytics Administration

This chapter provides information on accessing and working with the Analytics Administration console. It includes the following topics:

- Accessing Analytics Administration
- Using Analytics Administration
- Limiting Access to Analytics Administration

## Accessing Analytics Administration

To access Analytics Administration:

1. Log in to the portal as an administrator.
2. Click Administration.
3. From the Select Utility drop-down list, choose Analytics Administration.

## Using Analytics Administration

This section contains the following topics:

- Configuring Runtime Settings
- Configuring Security Settings
- Configuring Partition Settings
- Registering Events

### Configuring Runtime Settings

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.

Table 4-1 Timeout Settings
Setting | Description
--- | ---
Visit Timeout (seconds) | Type the maximum number of seconds that a user must remain inactive during a portal visit in order for Analytics to report subsequent activity as a new portal visit. Analytics reports this data on the Duration console page. The default is 120 seconds.
Note: | If you upgraded to Analytics 2.0 from a previous version, the Visit Timeout default setting from the previous Analytics version remains. For example, if you upgraded from Analytics 1.1, the default Visit Timeout is 600 seconds, since that was the default in Analytics 1.1.
Active User Timeout (days) | Type the maximum number of days that a user must remain inactive in the portal in order for Analytics to report the user as an inactive user. Analytics reports this data on the Users console page. The default is 7 days.
Note: | If you install the portal while Analytics is running, Analytics restarts the calculation of portal user activity after you have completed the installation. This may impact Analytics user timeout reporting. For example, if you set the active user timeout to 7 days and the user goes on vacation and remains inactive in the portal for eight days, Analytics reports the user as an inactive user on Day 8. However, if you install AquaLogic Interaction on Day 3 of the user's eight-day vacation, Analytics calculates Day 3 as the first day in which the user is inactive. For this reason, the seven-day active user timeout period does not occur and Analytics continues to report the user as an active user.
Note: | If you upgraded to Analytics 2.0 from a previous version, the Active User Timeout default setting from the previous Analytics version remains. For example, if you upgraded from Analytics 1.1, the default Active User Timeout is 30 days, since that was the default in Analytics 1.1.

The following table describes the portlet view/response time settings that you can configure.

Table 4-2 Portlet Views/Response Time Settings
Setting | Description
--- | ---
Capture portlet views/response times | 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.

Table 4-3 Export Report Settings
Setting | Description
--- | ---
Maximum rows to export | Choose the maximum number of rows that you want to allow in an exported report. By default, the maximum size is 500 rows. This setting affects all reports that are exported from Analytics console pages and portlets.

### Configuring Security Settings

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.

#### Super Users Role

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.

#### Capabilities

The following table describes the capabilities that you can assign to roles.

Table 4-4 Analytics Role Capabilities
Capability | Description
--- | ---
Export User Details Report | Lets the role export user-level data from reports. User-level data is exported into an .xls file that can be used with Microsoft Excel. By default, this capability is not granted. The option to export user-level data exists in these reports: Summary Metrics - Traffic Summary Metrics - Logins Community Metrics - Traffic Portlet Metrics - Usage Other Metrics - Search Other Metrics - Documents Other Metrics - Projects Other Metrics - Content Items
Select All/Top/Bottom Options | 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. When a role is not granted the capability to select All/Top/Bottom options, the role must choose one community or project; the option that is available depends on the report. By default, this capability is not granted.
View Portal Document Related Data | Lets the role view the Other Metrics - Documents report, as well as view document details in the Other Metrics - Search report. By default, this capability is not granted.

### Configuring Partition Settings

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.

#### Working with the Scrolling View Window

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.

#### Previewing Partitions

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:

- Green squares indicate partitions whose data is available to Analytics reports.
- Red squares with an X indicate partitions whose data is unavailable to Analytics reports; these partitions still exist in the database.
- Grey squares indicate partitions for months that currently fall within the Scrolling View Window's date range, but whose data is unavailable to Analytics reports. This usually occurs after a partition has been archived out of the database.

### Registering Events

#### Overview of Event Registration

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:

- Launch the Create Event page, which you use to create events and their parameters.
- Enable and disable the storage of data generated by individual events. Once event data is stored in the database, you can query the data for reporting in a portal or non-portal application.
- Create dimensions, which are discussed below.

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

#### Overview of Events, Event Parameters, and Dimensions

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.

#### Creating Custom Dimensions

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?.

#### Creating Events

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

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

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

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.

##### Delivered Parameters

The following table describes the parameters that are delivered with Analytics which are, by default, included in every event:

Table 4-5 Parameters Delivered with Analytics
Parameter | Description
--- | ---
USERID | The ID of the user who triggers the event. You must use the OpenUsage API to set the User ID.
TIMEID | The unique ID number that is created for each occurrence of the event. This value is set by Analytics.
VISITID | The portal visit ID of the user who triggered the event.
Note: | This parameter is only compatible with events that occur in the portal. This value is set by Analytics.
OCCURRED | The date and time when the event was generated. The format of the date/time stamp is determined by your database type. This value is set by Analytics.

#### Saving Event Data

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.

#### Stopping Event Data Storage

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.

## Limiting Access to Analytics Administration

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.