|
|
Overview of Events and Behavior Tracking
To help personalize campaigns and to effectively analyze customer interactions with a Web site, you need a comprehensive event tracking and logging system. To fulfill this requirement, BEA WebLogic Portal and BEA WebLogic Personalization Server include an Event and Behavior Tracking system. Events identify how a customer is currently interacting with an e-commerce site and the Behavior Tracking system records the event information. With these systems you have the ability to specify, customize, and record selected information. Event data can be used by leading e-analytics and e-marketing systems to evaluate behavioral and transactional data from your online customers. With this analysis you can create and enhance personalization rules, customize product offers, and optimize interactive marketing campaigns. This topic introduces you to Events and Behavior Tracking and provides a general survey of the elements that make up this system.
This topic includes the following sections:
What Are Events?
In general, an event is a notification that something has happened in a computer program. WebLogic Portal and WebLogic Personalization Server provide various points for generating events. Events provide a detailed and comprehensive view of the entire customer life cycle across your e-commerce site. These points can be tailored for your applications.
You can use events with campaigns to enhance promotion of products and services. Additionally, you can use events to gather intelligence to evaluate the effectiveness of a campaign. Underlying campaigns are scenarios. Scenarios are executed in the context of a campaign. Scenarios are a set of rules, called scenario actions, that allow you to personalize customer experiences on your e-commerce site. For example, if a customer clicks a Subscribe Me link on your Web site, you may want to send that customer an e-mail confirming the subscription. Using events and scenarios, you can choreograph the interactions between customers and your Web site.
With regard to tracking visitor behavior for analysis, the primary interest is in what the customer saw and what the customer did. Inherent in this investigation is information about when customers came to the site and when they left it, plus knowledge about which rules were fired during their visit.
Behavior Tracking
The Event service passes messages to Behavior Tracking. When Behavior Tracking is turned on, this data is recorded in a relational database. This information can then be used by data-mining systems to provide Web site customer information for e-marketing analysis. Behavior Tracking provides the following kinds of information:
The information generated from these events allows various kinds of behavior analyses, such as the following:
Standard Events
This section provides information about the standard events provided by BEA. Specifically, it contains a description of each kind of event, what generates the event, the class where event generation occurs, which product contains the event, and the elements of the event. Events elements comprise the data that is present within each event object.
Events are organized into categories. The following list presents each type of event category along with a brief description of what actions generates the event:
Session Events
Session events fire at the start time, end time, and if executed, the login time of a customer's session.
SessionBeginEvent
SessionEndEvent
SessionLoginEvent
Registration Event
Only one registration event exists. It is described in the following table.
UserRegistrationEvent
Product Events
These events occur when customer is presented with a product or clicks (selects) the presented product.
ClickProductEvent
DisplayProductEvent
Content Events
These events occur when the customer is presented some content, such as an advertisement, or clicks the presented content.
ClickContentEvent
DisplayContentEvent
Cart Events
These events indicate that one or more items are added or removed from a customer's shopping cart.
AddToCartEvent
RemoveFromCartEvent
PurchaseCartEvent
Buy Event
Only one buy event exists. It is described in the following table.
BuyEvent
Rules Event
Only one rule event exists. It is described in the following table.
RuleEvent
Campaign Events
These events occur when a customer participates in a campaign.
CampaignUserActivityEvent
DisplayCampaignEvent
ClickCampaignEvent
Servlet Lifecycle Events and Servlet Filter Events
The following events are generated using the Servlet 2.3 API:
These events are defined as part of the Servlet 2.3 lifecycle events. They are listeners on the session Created() and session Destroyed() events, which are generated by the servlets defined in the web.xml file. This file is located at:
PORTAL_HOME\applications\wlcsApp\wlcs\WEB-INF
where PORTAL_HOME is the directory in which you installed BEA WebLogic Portal or BEA WebLogic Personalization Server.
The following events are generated by JSP tags and filtered by the Servlet 2.3 <filter> element:
For each Web page displayed, the Web Application servlet checks for the presence of a click event in the HttpServletRequest. Each page click is then filtered by Web Application servlet as defined by the Servlet 2.3 filter <element>. The click events are generated automatically when the <filter> element is called on each invocation of the servlet. The ClickThroughFilter determines which type of event is generated by checking the event type in the HttpServletRequest. The valid types are defined at:
PORTAL_HOME\classes\clickthrough-event-types.properties
where PORTAL_HOME is the directory in which you installed BEA WebLogic Portal or BEA WebLogic Personalization Server.
Event Generators
The standard events supplied by BEA are generated at important points in an e-commerce site. The components that enable events include Java APIs, JSP tags, JSP scriptlets, Webflow input processors, Pipeline components, content selectors, and classification advislets. You can add or customize generators for each of the following events:
Note: DisplayProductEvent and ClickContentEvent are available in WebLogic Portal only.
Each of these events are generated by JSP tags. You can use the JSP tags that initiate these events to specify which products and what content generates these events. For example, in the wlcsApp E-Commerce Application, the JSP tag for the DisplayProductEvent is located in the details.jsp.
The tag shown in Listing 1-1 generates an event for any product displayed on a catalog detail page. If you want to generate an event for one particular product, you can write a scriptlet that keys off the SKU for that product.
Listing 1-1 JSP Tag
<%-- once the product is displayed, fire off a displayProductEvent --%>
<productTracking:displayProductEvent documentId="<%= item.getName() %>"
documentType="<%= DisplayProductEvent.ITEM_BROWSE %>"
sku="<%= item.getKey().getIdentifier() %>" />
When you add a JSP tag for an event, you should include a reference to the tag library descriptor, as shown below:
<%@ taglib uri="productTracking.tld" prefix="productTracking" %>
Notes: For more information about JSP tags, see JSP Tag Library Reference for Events and Behavior Tracking.
The details.jsp is located at:
PORTAL_HOME\config\wlcsDomain\wlcsApp\wlcs\commerce\catalog\details.jsp
where PORTAL_HOME is the directory in which you installed WebLogic Portal.
Login and Creation Events
This section discusses different methods for generating login and user registration events.
You can generate the SessionLoginEvent in either of the following ways:
If you are manually using the <um:login> tag or weblogic.servlet.security.ServletAuthentication to handle login, use the com.bea.p13n.tracking.TrackingEventHelper.dispatchSessionLoginEvent() method.
If you are directly using j_security_check FORM-based login, register the com.bea.p13n.servlets.P13NAuthFilter as the <auth-filter> in your Web Application's WEB-INF\weblogic.xml file. You do not need to code a JSP or Webflow Processor.
Use the com.bea.p13n.tracking.TrackingEventHelper.dispatchUserRegistrationEvent() method to generate the UserRegistrationEvent. You should generate this event after the SessionLoginEvent (which should occur during user creation). You can use either an Input Processor or in a JSP.
If you are using the Portal Webflow framework, the SessionLoginEvent and the UserRegistrationEvent are generated automatically from the com.bea.portal.appflow.processor.security.PostLoginProcessor in the security webflow as needed.
Event Mechanism
The Event service is an extensible, general purpose, event construction and propagation system. As shown in Figure 1-1, an event is generated by a trigger, such as a JSP tag, which creates the event object, locates the Event service bean, and passes the event object to the Event service. The Event service works with plug-in listeners that disseminate events to listeners interested in receiving the events. At creation time, each event listener returns the list of event types that it wants to receive. When the Event service receives an event, it checks the type of the event and sends the event to all listeners that are subscribed to receive that event's type.
The Event service has two sets of listeners: those that respond to events synchronously and those that respond to events asynchronously. The synchronous listeners use the thread of execution that created and transmitted the event to perform actions in response to that event. Behavior Tracking listeners use only the synchronous listeners. The asynchronous listeners receive the event from the thread where it was created and some time later, handles the event in a different thread of execution. The asynchronous service exists so that long-running event handlers can execute without delaying the application from a Web site visitor's perspective.
Whether a particular plug-in listener is installed on the synchronous or the asynchronous side of the Event service is based on the requirements of the application and is specified in the application-config.xml file.
Note: To edit the application-config.xml file, use the WebLogic Server Administration console. For more information, see Installing a Listener Class in the Event Service.
Figure 1-1 Event Mechanism
Event listeners implement the com.bea.p13n.events.EventListener interface. The interface defines signatures for two public methods:
The first method returns a list of event types that the listener is interested in receiving from the Event service. For example, if a listener is designed to receive events of type Foo, the listener returns Foo as an item in the array returned from invoking getTypes() on the listener. The second method is invoked when an event is passed to the listener. A listener has no knowledge of whether it is synchronous or asynchronous.
If you wish to create a listener interested in only campaign events, you would list the listener's fully-qualified classname in the application-config.xml file in either the eventService.listeners property or the asynchronousHandler.listeners property (for synchronous or asynchronous handling, respectively). The listener would implement the EventListener interface and return the following event types:
{"ClickCampaignEvent","DisplayCampaignEvent","CampaignUserActivityEvent" }
when its getTypes() method is invoked.
Warning: For proper operation, the WebLogic Server requires that changes to the application-config.xml file be made using the WebLogic Server Administration Console.
To edit the application-config.xml file, use the WebLogic Server Administration console. For more information, see Installing a Listener Class in the Event Service.
After the listener is installed, events of one of these three types arrive through the listener's handleEvent( Event theEvent ) interface.
The Asynchronous Delivery graphic in Figure 1-1 indicates that the asynchronous event handler receives events transmitted asynchronously from the synchronous side of the Event service. It then dispatches events to the pluggable asynchronous listeners based on the event types each listener is subscribed to receive.
Event Sequence
Figure 1-2 and Figure 1-3 provide a sample of the firing of events. These figures are intended to give you a sense of the order in which events fire, not a comprehensive examination of event sequencing.
Figure 1-2 Event Sequence Sample—Part 1
Figure 1-3 Event Seqeuence Sample—Part 2
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|