> Oracle WebCenter Analytics Development Guide > About the Oracle WebCenter Analytics OpenUsage API > Defining Your Event Model

Oracle WebCenter Analytics Development Guide

     Previous Next  Open TOC in new window   View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Defining Your Event Model

The first step to using Analytics functionality in a custom application is deciding which events are useful and what information you want to track. The Analytics database uses a standard star schema, providing almost unlimited flexibility in data storage.

Follow the steps below to define your event model:
  1. Identify the events you want to capture. An event typically defines one user action, for example, clicks, page visits, or downloads. In many cases, you can use portal events to capture the information you need. The OpenUsage API provides access to the following standard portal events:
    • Directory views
    • Document views
    • Page views
    • Portlet views and use
    • Search query and results
    • Login/logoff
    You can also raise custom events and define your own parameters. A new fact table is created in the Analytics database for every custom event. For details on the Analytics database implementation, see the Oracle WebCenter Analytics Database Schema.
  2. Identify facts about the event you want to track, for example, date, time, page, user, group, or member status. Each event includes several facts, represented by event parameters, which define the types of data generated by the event. By default, every event includes the following event parameters:
    • 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. 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.
    All the interfaces in the OpenUsage API include methods to get and set standard parameters, including user ID, portlet ID, page ID, URL, and referer. For a complete list of the standard parameters for each event type, see the OpenUsage API documentation (javadoc). You can also create your own event parameters to capture data that is not defined by the delivered defaults.
  3. To capture non-numeric data, define a dimension table, for example, URL, page name, user name, group name, or membership level. You can use dimensions from your own application's tables or create new ones in Analytics Administration (see Registering and Configuring Events in Analytics Administration).
The following examples describe event models.

#1: User interest statistics

Palo Alto Golf Course (PAGC) is setting up new classes and wants to see which topics users are most interested in. They decide to post a portlet listing three problem-specific articles on Golf Digest's Web site and track which of the links users click on the most. They also want to track users' skill levels since it is defined as a user property in their portal. Since the users are divided among three portal groups, PAGC also wants to track the users' group membership.

Solution: PAGC creates a portlet that displays links to the three articles. Each link points to a redirect page that calls the sendEvent method in the OpenUsage API, passing the event type ID for that page, the date-time, and user ID. The redirect page redirects to the actual link target. An administrator registers a custom event for the article click in Analytics Administration, along with the corresponding event parameters (event type ID, date-time, and user ID). The user ID parameter corresponds to the existing portal user dimension table, which includes skill level and group membership. PAGC creates a report that displays which links were clicked most often, grouped by skill level or portal group.

# 2: Customer follow-through statistics

BMW is working on a portal application for ordering car accessories online. The application allows users to browse a catalog of items, view details, add the items to a shopping cart, and purchase the items added to the cart. BMW would like to track the following statistics: Number of times a user clicked to browse the catalog. Number of times (by item) a user selected to see each item's detailed description. Number of shopping cart sessions initiated. Number of times (by item) each item was added to a shopping cart. Number of times (by item) each item was converted into an order.

Solution: All events can be captured by calling the OpenUsage API from the portal application. The VIEW_ITEM event could also be captured by placing an OpenUsage event tag on the details page. An administrator registers the five custom events in Analytics Administration:
  • BROWSE: Sent when a user clicks the catalog browse button.
  • VIEW_ITEM: Sent when a user views the details of a particular item. Item ID is passed as a parameter.
  • NEW_SHOPPING_CART: Sent when a new shopping cart session is initialized.
  • ADD_ITEM: Sent when a user adds an item to a shopping cart. Item ID is passed as a parameter.
  • CONVERTED_ITEM: Sent when an item is converted into an order. Item ID is passed as a parameter.
BMW creates reports to display how many users clicked to browse the catalog, to display how many initiated shopping cart sessions, and to show details on how many times each item was viewed, added to a cart, and/or purchased.

# 3: Content repository usage statistics

Netformx Software has a knowledge base search portlet on its support page that allows users to search for a term in user manuals, articles, marketing material, and/or white papers. Netformx would like to know which of these four repositories is searched the most via the portlet.

Solution: The portlet calls the OpenUsageAPI when the Search button is clicked, passing in the appropriate knowledge repository as the event parameter. If more than one repository was selected, an event is sent for each selected repository. If the portlet uses either the ISearchEvent or the IDirView interface to raise a standard portal event, there is no need to register a custom event in Analytics Administration. Netformx creates a report to compare usage of the four repositories.

# 4: Advertising campaign statistics

St. Paul Brewing Company is rolling out a new beer that has no carbs, no calories, and no taste. They plan on promoting the beer via e-mail and advertisements on Google and Yahoo. They would like statistics for the following:
  • Number of emails read.
  • Number of click-throughs from each campaign (that is, email, Google, Yahoo).
  • Number of new user accounts created due to click-throughs from campaigns, per campaign.
  • Number of community visits to the new beer community generated from each marketing campaign.
  • Number of free beer coupons (document in KD) downloaded due to each marketing campaign.

Solution: As with the other examples, all events can be sent via an OpenUsage API call with appropriate parameters. Page visits can be tracked using OpenUsage tags. An administrator registers any custom events and custom event parameters in Analytics Administration. A range of reports can be created to display statistics from the campaign.

The next step is to register any custom events in Analytics Administration. For details, see the next page, Registering and Configuring Events in Analytics Administration.
Parent topic: About the Oracle WebCenter Analytics OpenUsage API

  Back to Top      Previous Next