Personalization Overview

Personalization Overview

Portal Personalization provides automatic customization of Web site 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 Web site's premium products. 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 Management 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 you choose, or may come from an LDAP or any other database. Content is accessed via a set of Resource Collection classes.
A logging framework - The logging framework is used to record information about web site 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 runtime 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 Web site's premium products. 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 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.
When to use rules filtering versus collaborative filtering.
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.

Parent topic:
Personalizing your content

Related concepts

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.