Bhadri Madapusi

Subscribe to Bhadri Madapusi: eMailAlertsEmail Alerts
Get Bhadri Madapusi: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Getting Personal

Comparing WebSphere Commerce 5.5 and WebSphere Portal content publishing 5.0 Personalization

Whether you are a business user, an IT architect, or a developer using WebSphere Portal content publishing general personalization framework and WebSphere Commerce, you will need to know the difference between the personalized marketing campaigns created using these two sets of tools. Furthermore you can enable WebSphere Commerce server to make use of the WebSphere Portal content publishing personalization framework to provide marketing campaign capability. In order to enable WebSphere Commerce server to use WebSphere Portal content publishing personalization framework for organizing and delivering marketing campaigns, you must first know the difference between the two tools.

IBM WebSphere Portal content publishing provides a general personalization framework that you can use to organize and implement sets of personalization behavior such as Web page personalization and the delivery of personalized marketing campaigns. IBM WebSphere Commerce marketing tools make use of the Blaze personalization engine and its internal personalization engine as a means to organize and deliver personalized marketing campaigns.

This article compares the WebSphere Portal content publishing general personalization framework and WebSphere Commerce marketing tools on the following criteria: concept, capability, and usability. The article concludes by summarizing the trade-offs in using one tool over the other.

Both approaches consider a personalized marketing campaign to be a mapping between a set of contents and a set of customer segments (see Figure 1). The two differ in the way this mapping is organized (at creation time) and carried out (at runtime).

WebSphere Commerce Marketing Tools

WebSphere Commerce marketing tools use two fundamental components to deliver personalized marketing functions: initiative and campaign. An initiative defines the mapping between content and segments. A campaign is a logical container for groups of related initiatives that have a common business objective; a campaign exists within the scope of a commerce store. Figure 2 illustrates the relationship between campaign and initiative.

Each initiative maps the content to be displayed to theshopper, the segment (shopper segmentation group), and some additional condition (see Figure 3), which includes days on which the initiative must be active and the shopper's purchase behavior, among others. Initiatives are essentially used to achieve the business objective of showing particular content to certain users. Figure 3 illustrates the relationship between an initiative and its entities.

You can display the following content types to shoppers using the WebSphere Commerce solution: a set of product SKUs, a set of categories, or a set of collateral images to achieve business objectives such as suggestive selling (upselling or cross-selling products to a customer based on their purchase behavior) and awareness advertising (displaying advertisements to increase customers' awareness of a product or to inform customers about upcoming events or discounts). Figure 4 illustrates these content types.

An e-Marketing Spot is a JavaBean used on a JavaServer Page to display the content returned by an initiative. Marketing managers select the initiatives they want to show and map them to an e-Marketing Spot. This mapping is called a schedule. Each initiative has an active lifetime, which is specified during the mapping. Figure 5 illustrates the relationship between an initiative and an e-Marketing Spot.

Figure 6 is a conceptual model of a WebSphere Commerce personalized marketing campaign.

WebSphere Portal Content Publishing Personalization

WebSphere Portal content publishing personalization provides rules-based filtering, i.e., content definition and segment definition are maintained as rules. There are three fundamental types of rules: action, profiler, and binding.

The content definition rules, known as action rules, are used to select content for display. The segmentation rules, known as profiler rules, are used to categorize a Web site visitor or the characteristics or circumstances of his or her visit, such as the time of day in which it occurs. A profiler rule contains one or more profiles, each of which defines an individual segmentation rule. The profiler rule acts as a container for related profiles. A binding rule combines profilers and actions into sophisticated conditional clauses that cause actions to be performed based on evaluation by the profilers. Binding rules essentially are used to achieve the business objective of showing particular content to certain users. Figure 7 illustrates the relationship between actions, profilers, and bindings.

WebSphere Portal content publishing uses strongly typed JavaBeans called content spots to display the content returned by a binding. You can select the content to be shown by a content spot by mapping an action rule or binding rule to the content spot. Each such mapping has an active lifetime that must be specified during its creation. If a content spot is mapped to more than one binding or action during the same time period, then contents will be selected at random based on the weights assigned to individual mapping. Figure 8 illustrates the relationship between a content spot, a binding, and an action.

A campaign in WebSphere Portal content publishing is also a container that groups mappings (binding-content spot mappings or action-content spot mappings) that have a common business objective. Unlike a WebSphere Commerce campaign, a personalization framework campaign has the following attributes: active lifetime, priority, and splits.

Multiple campaigns can be active during the same time period. In that case a user must specify a priority for each campaign so the framework can determine which campaign to use. In case a user specifies multiple campaigns with the same priority, a random campaign is chosen based on the weights assigned to individual campaigns. Figure 9 illustrates the conceptual model of a WebSphere Portal content publishing personalization framework.

Comparison of Concepts Between the Two Models

Table 1 lists the conceptual differences between the two models. A number of capability and usability differences between the two models arise from these conceptual differences. I will discuss these differences in later sections.

Some of the concepts of the WebSphere Portal content publishing personalization framework can be abstracted and mapped to concepts in the WebSphere Commerce Marketing tool. Table 2 describes these mappings.

Differences in Capability

The conceptual difference between the models affects the capability of each model. The following sections discuss the capability differences during personalized marketing campaign creation (setup) and runtime (execution time).

CAMPAIGN CREATION
Being a general framework, WebSphere Portal content publishing has a free-form query interface to create actions (content rules) and profiles (segmentation rules). This interface allows the creation of a rich set of complex actions and profiles. Conversely, WebSphere Commerce uses a wizard to create content and segments. This interface restricts the creation of content and segment rules to a limited set.

The profile in WebSphere Portal content publishing can be used to monitor the runtime behavior of the user, including pages visited or actions performed, and show appropriate content based on these runtime behaviors. WebSphere Commerce allows runtime monitoring of user actions using additional conditions but this is restricted to items in the customer's shopping cart and purchase history.

In WebSphere Portal content publishing, actions can be directly mapped to content spots, so all of a store's customers can view the content related to an action when an associated content spot is executed; the content is no longer restricted by user profile. In WebSphere Commerce, content cannot be implicitly mapped to an e-Marketing Spot; only an initiative can be mapped to an e-Marketing Spot. In WebSphere Commerce, if you want to show content to all customers, you must explicitly state that during creation of the initiative.

WebSphere Portal content publishing not only allows creation of rules to display content to customers (based on customer profile) but also allows the creation of rules to update underlying data in the data store. WebSphere Commerce allows only the creation of rules to display content to customers.

WebSphere Portal content publishing allows you to create default content to be shown (called Normal View); this default is used by the runtime environment unless superseded by an active campaign. WebSphere Commerce does not have a mechanism to show any default content.

WebSphere Portal content publishing also offers a preview mode. It is possible to test the operation of rules and campaigns, and to see how the rules will respond to customers with various attributes, or at different times or dates. This preview functionality is not available in WebSphere Commerce. Table 3 summarizes the differences discussed in this section.

CAPABILITY DIFFERENCES AT RUNTIME (CAMPAIGN EXECUTION TIME)
Content spots in WebSphere Portal content publishing are typed, meaning that at runtime a content spot can retrieve content of only one type. The e-Marketing Spots in WebSphere Commerce are typeless. At runtime a spot can retrieve content of multiple types.

In WebSphere Portal content publishing, only the campaign with the highest priority is evaluated. If this campaign does not have a mapping (binding or action/content spot mapping) for the content spot used in the store page, the runtime will move on to the campaign with next-highest priority until it finds a campaign with a mapping for the content spot that can return at least one content item. If none of the campaigns for the content spot can return content, the runtime defaults to Normal View. In WebSphere Commerce, all of the active campaigns are evaluated. The e-Marketing Spot combines the content retrieved from all of the active campaigns for display.

Campaign splits and mapping splits play a significant role in WebSphere Portal content publishing. When multiple active campaigns have the same priority, the splits are used to calculate a percentage chance that one mapping will be used instead of the others. In a campaign, multiple bindings or actions can simultaneously map to a content spot. The mapping splits are used to calculate a percentage chance that one mapping will be used instead of the others. The decision made by this split percentage is valid for the entire customer session. WebSphere Commerce does not use the split concept, as it executes all active campaign initiatives.

A marketing manager may want to suspend active campaigns due to business reasons. WebSphere Commerce offers the capability to suspend active campaigns at runtime. Because WebSphere Portal content publishing does not offer this capability, in order to suspend a campaign it must be republished with a new timeframe.

WebSphere Portal content publishing uses the BRBean rules engine to evaluate the content rules and segment rules. WebSphere Commerce uses the Blaze rules engine and its internal engine to evaluate the content rules and segment rules. Table 4 summarizes the runtime differences discussed in this section.

DIFFERENCES IN USABILITY
The WebSphere Portal content publishing personalization framework is meant to be a generic model, and can be plugged into any Web application. The WebSphere Commerce marketing solution is meant to work within the scope of WebSphere Commerce. This basic difference gives rise to the following differences in usability between the two models.

The pluggable framework provided by WebSphere Portal content publishing expects certain resources to be provided by the application into which the framework is plugged. These resources are wrappers to the base product data store and are used in the creation of actions and profiles. WebSphere Commerce campaigns, on the other hand, are self contained; the resources used in the rules are provided out-of-box by WebSphere Commerce.

One of the major differences between WebSphere Portal content publishing and WebSphere Commerce is the user interface. WebSphere Portal content publishing uses a structured hypertext query builder interface to build actions (content rules), profiles (segment rules), and bindings. WebSphere Commerce instead uses a wizard-based business user interface to build initiatives. In WebSphere Commerce, content rules, segment rules, and content-segment mappings are constructed automatically, and the end user is sheltered from building the query logic directly.

As WebSphere Portal content publishing uses a free-form query builder, creating new rules requires only the resources that are required to construct rules. To create new rules in WebSphere Commerce requires changes to the user interface and probably changes to the Blaze rules engine as well (depending on the type of change). Table 5 summarizes the differences in usability discussed in this section.

Conclusion

There are trade-offs in using one model over the other. To conclude the article, I list these tradeoffs below.

The WebSphere Portal content publishing personalization framework has a powerful content and segment rule creation mechanism compared to that of the WebSphere Commerce Campaign model.

WebSphere Portal content publishing operates in an author-publish environment, and has a preview mode to preview all of the campaign rules before publishing to the production server. The WebSphere Commerce campaign solution does not operate in an author-publish environment. An initiative becomes active as soon as it is created, and does not have a preview mechanism.

The Normal View feature in WebSphere Portal content publishing acts as a default campaign, whereas there is no default initiative in WebSphere Commerce. However, default content can be built into the JavaServer Pages.

One of the major differences between WebSphere Portal content publishing and WebSphere Commerce is the runtime behavior. At runtime with WebSphere Portal content publishing only the campaigns with the highest priority that can return content are evaluated, and if these campaigns do not have mappings (binding or action-content spot mapping) for the content spot specified in the store page, then the runtime will default to the Normal View. WebSphere Commerce always evaluates all of the active initiatives and returns the union of content that is targeted at the customer in a random order.

WebSphere Portal content publishing does not have a mechanism to suspend a campaign at runtime, whereas WebSphere Commerce does have a mechanism to suspend an initiative at runtime.

The WebSphere Portal content publishing personalization framework is a pluggable solution, so it is highly customizable and flexible compared to the WebSphere Commerce campaign model. However, with the WebSphere Portal content publishing campaign model you cannot create rules out of the box. WebSphere Portal content publishing expects the application it is plugged into to provide resources to create content and segment rules. For WebSphere Commerce, all the resources required to create basic content and segment rules are provided out of the box.

WebSphere Portal content publishing provides a free-form query user interface to construct content rules (action), segment rules (profile), and bindings. This user interface may be suitable only for technical users, and business users may find it difficult to use. WebSphere Commerce provides a wizard-based business interface to create initiatives. The low-level rules are created automatically. But the downside of this is that customization requires extensive modifications to the user interface.

For more in-depth information on how campaigns are organized and executed, refer to the WebSphere Portal content publishing online help documents and the WebSphere Commerce help documents online help.

Notice: All the opinions expressed in this document are views of the author and not of IBM Canada Ltd., or any other individual or organization.

Trademarks: IBM and WebSphere are registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Other company, product, and service marks may be trademarks or service marks of others.

More Stories By Bhadri Madapusi

Bhadri Madapusi is a software developer working in the IBM Toronto Lab's Electronic Commerce Division. He earned his MSc in information systems from BITS, India, and his MSc in computer science from Queens University, Canada. Bhadri's interests include software modeling, design patterns, and data management.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.