Personalization - Personalization

Personalization

Portal Personalization provides automatic customization of website content for individual users and user groups.
Personalization can recognize a specific user based on a profile or can determine characteristics of a user based on previous purchases, products or pages viewed, and so forth. Personalization then selects content that is appropriate for that profile. If a person has a high salary range, Personalization can be configured to retrieve information about a commercial website premium product. If an individual belongs to a particular geographic region, content specific to that region may be targeted to the individual. The page is assembled with the proper personalized information, and the user sees her personalized page.
Personalization is composed of

Personalization browser - The Personalization user interface:

registers resource collections

authors rules, campaigns, and content spots

maps rules into content spots for a particular campaign

Since objects are authored through the Personalization server, the Personalization browser can display rules in production as well as view rules in a staging environment.

Rules engine - The rules engine executes rules created in the Personalization browser. A programming interface exists for Personalization to invoke rules, Personalization rules may be invoked through the Personalized List portlet, or rules may be invoked through Web Content Manager Personalization components. Rules associated with pages or portlets through Portal Administration are also automatically triggered.

LikeMinds Recommendation engine - The recommendation engine evaluates recommendation rules created in the Personalization browser.

Resource engine - The resource engine resolves the queries produced by rules into content pieces to be returned. Content for Personalization is created and approved using whatever content management tool we choose, or may come from an LDAP or any other database. Content is accessed via has a set of Resource Collection classes.

A logging framework - The logging framework is used to record information about website usage to the feedback database and the recommendation engine. It is entirely up to the site developers to decide what information is logged.

The engines are sometimes collectively referred to as the Personalization run time server.
The engine identifies the particular user. Personalization retrieves that person's profile. For example, a person may have a salary range included in her profile. Personalization then selects content that is appropriate for that profile. If a person has a high salary range, region code, or other information, Personalization can be configured to retrieve information about a commercial website premium product. The page is assembled with the proper personalized information. The user sees her personalized page.

Types of Personalization

There are three types of Personalization:

Simple filtering

A site displays content based on predefined groups of site visitors. For example, if a site visitor is in the Human Resources department, the site provides access to URLs containing Human Resources policy manuals.

Rules engines

In a rules based system, the site owner defines has a set of business rules which determine what category of content is shown when a certain profile type visits the site. An example would be: Display all four wheel drive SUVs to visitors in the northeast in the 21 to 35 age group.
This approach has the advantage of driving the site's behavior with the business objectives of the site owner. The site owner is usually the owner of a marketing campaign or some other business manager.

Collaborative filtering

A site visitor rates a selection of products, explicitly or implicitly. Those ratings are compared with the ratings offered by other visitors. Software algorithms detect similarities. For example, a visitor receives book recommendations based on the similar purchases of others.

Rules versus collaborative filtering

When complex filtering is required, a rule-based system may work better than collaborative filtering, and vice versa. The following table details examples where one type of personalization is better than the other.

Scenario Which filtering type to use Reason
If the number of items offered and users who purchase them are rather low. Rules Very little room to compute user similarity necessary for collaborative filtering.
If price points are high or purchasing frequency is low. Rules Finite, limited arenas - collaborative filtering fails because of the inherent lack of diversity.
If there is a pre-existing dependency between items. Example: Disability policy required for homeowner Rules Recommending a disability policy just because collaborative filtering says many others "like this user" also bought a policy is incorrect--one must have the homeowner policy first.
If number of items offered and users who purchase them are rather high. Collaborative Cannot write rules covering all items.
If price points are low, all quite dissimilar, or the products offered have a wide range of user appeal. Collaborative The wide variance fits the collaborative filtering approach. Collaborative filtering also lowers the risk of making "bad" recommendations.
When not much information is gathered about the user, but the user can be identified, possibly by a login or cookie. Collaborative In this case, user attributes on which to base rules may be lacking. Collaborative filtering can compare the user's experiences on the site to other users.

How a site is personalized
Use this topic to understand how to define a personalized list of new articles for a website, such as a section of an intranet site for targeted employee bulletins or where the content of the site is tailored to the particular user.

Personalization terms
The concepts and principles for working with Portal Personalization require an understanding of terminology.

The Personalization interface
The Portal Personalization user interface consists of three portlets: the Personalization Navigator, Personalization Editor, and the Personalized List.

Publish personalization rules overview
Portal Personalization sends published rules across HTTP to a servlet which resides on each personalization server. This servlet can receive publishing data or initiate new publishing jobs. When a user begins a publishing job from the personalization authoring environment, the local servlet is provided with the set of information necessary to complete the job. The local servlet contacts the destination endpoint servlet (which could be the same servlet) and sends its data to it. The destination servlet reports success or failure.

The Web Content resource collection
The Web Content resource collection is installed and configured out of the box. This predefined collection allows us to write rules that select lists of content from IBM Web Content Manager. Rules specify which Web content to show in a Portal Personalization component in Web Content Manager.

The Portal User resource collection
Portal Personalization comes with a Portal User resource collection. This collection uses public APIs provided by HCL WebSphere Portal to access user information.

LikeMinds Recommendations
Personalization contains a dynamic recommendation system based on LikeMinds. LikeMinds is software used with the e-commerce applications. LikeMinds analyzes user interactions that occur on the Web site and generates real time predictions and recommendations to the Web site users.

Feedback and analytics
Personalization provides a complete logging framework for collecting data on how visitors are using the Web site. If Feedback is enabled, data is automatically collected about each Personalization rule that is fired. In addition, development tools enable Web sites to collect a variety of data related to visitors' actions and behavior. By default this data is logged to a standard database schema for later analysis and reporting. The framework is also extensible, allowing Web sites to customize and supplement the way data is collected and stored to more fully meet their needs.

Develop a personalized portlet
This exercise demonstrates how to use Personalization features of HCL WebSphere Portal and Rational Application Developer to build your first personalized portlet. Your final result is a working portlet that uses Personalization rules and content spots to display personal news based on user attributes (or profiles).

Personalization programming reference
HCL WebSphere Portal provides the programming model, processes, and APIs for the Personalization rules and resource engines.

Parent: Set up a site
Related:
Develop a personalized portlet

Scenario	Which filtering type to use	Reason
If the number of items offered and users who purchase them are rather low.	Rules	Very little room to compute user similarity necessary for collaborative filtering.
If price points are high or purchasing frequency is low.	Rules	Finite, limited arenas - collaborative filtering fails because of the inherent lack of diversity.
If there is a pre-existing dependency between items. Example: Disability policy required for homeowner	Rules	Recommending a disability policy just because collaborative filtering says many others "like this user" also bought a policy is incorrect--one must have the homeowner policy first.
If number of items offered and users who purchase them are rather high.	Collaborative	Cannot write rules covering all items.
If price points are low, all quite dissimilar, or the products offered have a wide range of user appeal.	Collaborative	The wide variance fits the collaborative filtering approach. Collaborative filtering also lowers the risk of making "bad" recommendations.
When not much information is gathered about the user, but the user can be identified, possibly by a login or cookie.	Collaborative	In this case, user attributes on which to base rules may be lacking. Collaborative filtering can compare the user's experiences on the site to other users.