Figure 1: Roles and their application in personalization
Published on dev2dev (http://dev2dev.bea.com/)
http://dev2dev.bea.com/pub/a/2006/04/personalization.html
See this if you're having trouble printing code examples
by Michael Padilla
06/29/2006
Content personalization seems simple: Certain users should be able to access certain content while others should not. The concept, however, is deceivingly complex. While you may be tempted to jump in and start assigning entitlements to users based on arbitrary classifications, taking the time to properly classify users and content with an extensible model will go a long way in meeting your personalization needs far into the future. Classifying distinct users and content is a challenge. How can you best classify users such that you can easily and accurately target broad and finely focused audiences? How can you minimize the administrative overhead of maintaining the classification information of both users and content? To what level of granularity should the content be divided to support personalization? Finally, how can all this be implemented with BEA WebLogic Portal 8.1? Content personalization is certainly complex, but by logically tackling its issues, it need not be complicated.
Personalization sounds like a great concept. I'm a unique user, with unique interests and needs (and perhaps even purchasing power). Wouldn't it be great if a Web site somehow knew those applicable characteristics so it could selectively filter content based on those characteristics? I could be spared from having to wade through content that is of no personal interest. The Web site publisher could selectively push content based on the intersection of site goals and the user's characteristics. Even more importantly, content that absolutely must not be exposed to certain users for security purposes can be filtered so only permissible users may view it.
Personalization is powerful and complex, so let's start with the basics. Conceptually, you have a pile of content and many users. You need to place locks on each piece of content and have custom keys created for each of those locks. Users are given a key ring with a collection of keys with which they can access content deemed applicable to them. If none of a user's keys fit a lock, that user can't access the content.
Locksmithing the locks and keys can be tricky. The content locks and keys are made of characteristics that describe the user and the content. For example, a message about a scheduled office fire alarm should be viewable only by users at that office location (123 Main Street). The lock for the message is simply Location = 123 Main Street. Users may have many attributes in their profiles, but as long as they have Location = 123 Main Street, they have the key to view the content.
You can further decouple users and content by applying the locks and keys to groups of users and groups of content. If several users fit the same profile, you can define a user group and define a single profile for that group that all users who are assigned to that group will automatically inherit. Likewise, you can assign metadata to your content and define groups of content based on the metadata. For example, if you have 100 pieces of content that are all about sharks, you can define a metadata attribute "Subject = Sharks". You can then set all users who belong to the user group "Marine Biologist" to be allowed to see any content whose subject equals shark. This decoupling of individual users and specific pieces of content provides highly dynamic and targeted content.
User characteristics describe the users, but understanding the content targeting needs drives which characteristics must be captured on a user's profile. The personalization model reflects how the characteristics should be organized to achieve the desired personalization goals. Users can be described in innumerable ways, by age, height, sex, eye color, department, location, even shoe size. But unless there is a need to filter content based on a particular characteristic, that characteristic does not need to be captured. You need to determine the minimal set of characteristics required to definitively describe who can access a particular piece of content. Taken across your entire pile of content, you'll have your initial pass at the characteristics that must be included in your user profiles.
When defining the necessary user characteristics, you need to avoid using poorly defined, blurred attributes. This occurs most often when two unique types of characteristics have a large overlap. For example, a company may have multiple business lines, each operating primarily from a unique geographic location. Acme Airlines is based in New York, Acme Cigarettes is based in Chicago, and Acme Oil is based in Dallas. While the majority of employees for a particular business line work in the same location, it is not true for all employees. In defining personalized content for Acme's global intranet, it's important to avoid the mistake of categorizing all users as only New York users, Chicago users, or Dallas users. Is it the user's geographic location that drives the content or the user's business line? For weather information it's the former, while for an oil press release, it's the latter. Correspondingly, a user would have to be classified with two sets of information: the user's business line and geographic location.
A user's profile consists of categories containing attributes, each having a particular value based on the user. For example, a category could be Hair Color with the following attributes: a) black, b) blond, c) brown, d) red, e) none. For a company intranet, a category could be Organization with a hierarchical set of attributes including specific business lines, divisions, departments, and working groups. The attributes are the building blocks from which you can forge your locks and keys for your content. Each lock and key consists of at least one attribute, but may consist of many.
Content targeting needs drive how many categories and values within each category are required for your user profiles. Reality checks are important in defining these characteristics. If you find yourself with hundreds of attributes that are apparently required to support highly targeted content, you may want to rethink your content distribution medium altogether. Do you really need all those characteristics defined across both users and content so that you can target content to an innumerable set of small groups? Keep in mind there may be significant administrative overhead in maintaining highly detailed profiles for users and correspondingly classifying content. If you get to the point where you think you may be architecting a replacement for email, it's time to take a step back and look into generalizing some of your categories and/or attributes.
Once you have made your initial attempt in defining categories and their respective attributes you should check the quality of your categorization. All the categories and attributes within a category should be mutually exclusive. If any of the attributes overlap, you may run into issues of targeting content. For example, if your attributes for Hair Color were defined as a) black, b) blond, c) brown, d) red, e) none, and f) dark, you will run into issues accurately classifying both content and users. If a user has black hair do you select black, or dark, or both? You may need to remove attributes, define a hierarchy with the attributes, or create new categories.
The granularity of content for creating personalization also needs to be defined. How small do you need to "chop up the content"? Do you need to limit access to an entire site, a section of a site, a page, a section on a page, or even a single link? As with classification definition, the granularity at which content is targeted comes at price. As you work with smaller and smaller pieces of content, the number of pieces of content multiplies. Each piece of content comes with the administrative overhead required to properly classify it so that it may be targeted to a specific audience. Once again, if you find yourself dividing content into exceedingly small pieces, you may want to consider email as the more appropriate solution to deliver your highly targeted content.
|
If simply planning personalization is so involved, actually implementing it must be a nightmare, right? Fortunately WebLogic Portal 8.1 is equipped with the tools to apply personalization relatively easily. There are two primary modes of applying personalization. You can set entitlements based on roles to the fundamental portal resources, including desktops, books, pages, and portlets. More advanced personalization functionality can be achieved with content selectors and placeholders that work in conjunction with the Virtual Content Repository (VCR). Implementing a well-planned personalization model with these tools can allow you to flexibly target content based on a dynamic set of factors.
Both methods of personalization work with user profile attributes. You must first define which attributes you need to capture. Then you must define the values for the attributes for each user. The maintenance of the user profile information is facilitated by the use of groups. By assigning a set of values to the attributes of a profile that is assigned to a group, all users in that group will inherit those values on their individual profiles. By changing the profile values for a group, you can more easily maintain the profile values for many users.
The following two sections look at each of these approaches in turn.
There are two ways to leverage WebLogic Portal 8.1 functionality to deliver personalized content. One way affects the content container while the other affects the content itself. I'll begin by looking at the simpler of the two forms of applying personalization: setting entitlements to a portal resource. A portal resource is a content container such as an entire desktop, a book, a page, or a portlet. Using the WebLogic Administration portal, you can select any portal resource, the role you would like to administer for the component, and the capabilities (view, edit, remove, minimize, maximize) pertaining to the component.
| View | Minimize | Maximize | Edit | Remove | |
|---|---|---|---|---|---|
| Desktop | X | ||||
| Book | X | X | X | ||
| Page | X | ||||
| Portlet | X | X | X | X | X |
Table 1: Capabilities the can be administered based on the type of portal resource
For example, if you have an Executive dashboard page that should be viewed only by members of the board, you would select the Executive dashboard page, select the "Executive" role, and select the "View" capability. You are directing the system to display the Executive dashboard only to those users who have been assigned the role of "Executive." Any user who is not assigned this role will not see the page.
Roles provide flexibility for applying personalization to portal resources, and Figure 1 provides a summary of the way in which roles can be applied.
Figure 1: Roles and their application in personalization
Roles can be assigned in three ways. You can directly assign individual users to roles. You can group users into groups and assign those groups to a role. Finally, you can create role expressions that dynamically assign roles to users based on characteristics from their user profile. For example, a role expression named "New York Senior" can be automatically assigned to all users who have the attributes of Location = New York and Age >= 65 on their user profile. By applying a view entitlement to the NY Senior Benefits portlet tied to this role, only users from New York who are at least 65 years old will see this portlet.
Portal entitlements apply to the container of the content. It is one-dimensional personalization based solely on the user. With WebLogic Portal 8.1 you can also implement two-dimensional personalization based on both user attributes and content attributes using either selectors by themselves or placeholders used in conjunction with campaigns.
Two-dimensional personalization is powerful because it displays content to users based on both who the user is and what the content is. It is achieved by using a user query that is linked to a content query to render targeted content at a specific location on a page. You can display certain types of content to certain types of users based on user properties and content properties.
Example: If user eye color = blue and size = large, display content that has type = promotion, merchandise = clothing, color = blue, and size = large. By coupling users and content based on how users and content are described, you are able to target content based on complex observations. In this case, people who are large with blue eyes are more likely to purchase blue clothing that is available in large sizes. Concurrently, the same piece of content can be used on another page that lists all blue merchandise where if user = visitor display content that has color = blue.
The user query determines who is allowed to see the content. It operates on the attributes defined in user profiles, system values (for example, HTTP session properties), and/or user events. For frequently used user attribute value combinations, you can define user segments. Referring to the example above, you can define a user segment called "Big Blue" defined by the conditions color = blue and size = large. You can then use this single segment in user queries in place of the two attribute value pairs it represents. If you update the segment definition, all user queries that refer to the segment will be affected accordingly and automatically. User segments work with content selectors and placeholders/campaigns in a manner similar to roles with role expressions working with entitlements/portal resources.
The content query determines what content to display. It operates on metadata assigned to each content file. To query content you must have it described in a well-defined manner. The VCR has the facilities to define and manage content metadata. Just as users are assigned profiles that characterize who they are, content has metadata that describes the content itself. The metadata provides the properties that can be queried. You can define custom types of content by creating sets of properties. Essentially you are creating metadata templates. When you add new content, you select the content type (that retrieves a metadata template that you created), which in turn drives which properties you must assign values for the specific piece of content. The content query operates on the metadata that has been assigned to each content file.
With users described by their user profiles and content described by its metadata, you can target certain types of content to certain types of users. If the user's properties meet the conditions set in the user query, the content that results from the linked content query is rendered on the page.
With WebLogic Portal 8.1 you can target content based on the combination of user attributes and content attributes using mechanisms that link user queries with content queries. Content selectors link a user query and a content query by default. Placeholders have only a content query, but you can associate a campaign to a placeholder to effectively link a content query with a user query. Either content selectors by themselves or placeholders with campaigns can be used to target content.
Content selectors serve as "content buckets" that are placed on a Web page at a specific location. Each selector has a user query and a content query, both of which can reflect compound conditional statements operating on multiple criteria. If the user matches the criteria as specified in the user query, all content that matches the content query will be rendered at the location in the Web page where the selector was placed.
The user query can operate off any combination of the following:
The content query can operate off any metadata assigned to content in the VCR.
In WebLogic Workshop, you can create a content selector file that couples a user query with a content query, as shown in Figure 2. In the example below, all users who have their Graphic Preference equal to "classic" on their user profile will view all content whose name contains "IRACampaign". The content selector file is placed at the desired location on the Web page. All users who meet the user query criteria will view all content that meets the content query criteria at the location on the Web page where the content selector file was placed.
Figure 2: The content selector file in WebLogic Workshop
When a Web page with a content selector is requested, the content selector first checks to see whether the user is allowed to see the selector's content. To do so, it evaluates the conditions as defined in the user query based on the properties of the user. If the user's properties match the critieria, the selector goes to the VCR to evaluate the conditions as defined in the content query. The content query is evaluated based on the content metadata defined for each content file. All content whose metadata matches the criteria is rendered on the Web page. Here is how a content selector works:
Figure 3: How content selectors work
|
Content placeholders work similarly to selectors except they have only a content query and return only the single most highly weighted content. (Content contributors can manually weigh their content based on its importance.) When a Web page with a placeholder is requested, the placeholder directly goes to the VCR to evaluate the conditions as defined in the content query based on the content metadata defined for each content file. Of all content whose metadata matches the criteria, only the single most highly weighted content is rendered on the Web page. Placeholders work as shown below:
Figure 4: How placeholders work
By themselves, placeholders do not serve up personalized content. But they can be coupled with campaigns for content personalization in much the same way content selectors work.
Campaigns provide a broad set of functionality for delivering personalized functionality. They can be used for displaying personalized Web content, triggering email messages, and calculating dynamic commerce discounts. Here I'll just focus on how they can be used to display personalized Web content.
A campaign can essentially assign a user query to an existing placeholder and override its original content query. When you create a campaign, you define a new user query and content query and choose an existing placeholder into which the returning content will be rendered. A campaign coupled with a placeholder works similar to a selector, as shown below:
Figure 5: How placeholders work with campaigns
Campaign user queries can be more advanced than those used by selectors. Whereas selector user queries can operate only on a set of user and system characteristics, campaign user queries can also operate on user events. You can deliver personalized content based not only on whom your users are but also by what they do while interacting with the system. Some of the many conditions you may choose from are shown below:
Figure 6: Using an event to trigger a campaign scenario (click the image for a full-size screen shot)
With WebLogic Portal 8.1 you can know who your users are, what they're doing, and what content you have available. You can tie all that together with content selectors and placeholders or campaigns to deliver targeted content to your users.
Providing users with custom content that is applicable to them based on who they are is invaluable. But it takes planning to tailor content to users based on the characteristics of each if you want to avoid the administrative nightmare of maintaining your user base and content collection. BEA WebLogic Portal 8.1 gives you tools to implement and manage personalized content. Whether you apply personalization with content containers (entitlements/portal resources), the content itself (content selectors, placeholders/campaigns), or a combination of both, you can provide tailored content across a diverse user base. If you know who your users are, and even how they interact with the application, you should reward them with content that is applicable.
Michael Padilla is a user experience design director for Web applications in Philadelphia, where he oversees everything from information architecture to branding integration to rich client UI architecture.
Return to dev2dev.