|
|
|
|
|
|
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 Campaign Manager for WebLogic, BEA WebLogic Commerce Server, 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. Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Serverprovide various points for triggering 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 the 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 configured, the Behavior Tracking 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:
Event Details
This section provides information about the standard events provided by BEA. Specifically, a description of the event, the type of trigger, the class where triggering 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:
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
Event Triggers
The standard events supplied by BEA are triggered 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, the Flow Manager, content selectors, and classification advislets. You can add or customize triggers for each of the following events:
Note: DisplayProductEvent and ClickContentEvent are available in only Campaign Manager for WebLogic and WebLogic Commerce Server.
Each of these events are triggered by JSP tags. You can use the JSP tags that trigger these events to specify which products and what content triggers these events. For example, in the WLCS Web Application, the JSP tag for the DisplayProductEvent is located in the details.jsp.
The tag shown in Listing 1-1 triggers an event for any product displayed on a catalog detail page. If you wanted to trigger an event for one particular product, you could 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:
where WL_COMMERCE_HOME is the directory in which you installed Campaign Manager for WebLogic and WebLogic Commerce Server.
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. The asynchronous listeners receive the event from the thread where it was created and some time later, handle 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 weblogiccommerce.properties file.
Figure 1-1 Event Mechanism
Event listeners implement the com.bea.commerce.platform.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 weblogiccommerce.properties 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.
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 Sequent Sample—Part 2
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
