Oracle® Application Server Personalization User's Guide
10g Release 2 (10.1.2) B14052-01 |
|
Previous |
Next |
Oracle Application Server Personalization (OracleAS Personalization) enables 1:1 marketing for businesses by dynamically serving personalized recommendations in real time to both registered customers and anonymous visitors. OracleAS Personalization uses data mining technology to analyze the large amounts of data gathered from Web sites and other applications to find patterns within purchase, demographic, ratings, and navigational data. OracleAS Personalization answers such questions as "Which items is this person most likely to buy or like, and with what likelihood?", "People that bought this item are likely to buy which other item?", and "What should I offer this customer to retain his or her business?"
This chapter first explains what personalization is and then introduces OracleAS Personalization.
Personalization provides relevant and specific recommendations for individuals, taking into account personal preferences, demographics, and behavior. Personalization permits delivering recommendations with the touch and timing of someone who knows you well.
OracleAS Personalization is an integrated software product that provides a way for businesses to derive or generate recommendations for their customers.
OracleAS Personalization makes recommendations using data mining technology without the need to explicitly define manual rules. It should not be confused with similar processes such as customization, business rules, or memory-based collaborative filtering.
Customization requires users to explicitly state preferences such as which stocks or sports teams to track. Personalization automatically deduces the customer's interests from the customer's behavior.
Business rules, such as "people who buy digital cameras buy many batteries for the cameras," are created from the experience of human beings running a business. They are not automatic and do not normally apply to a particular customer.
Memory-based collaborative filtering considers a customer's site usage history in locating like-minded customers for purchases. The entire dataset or summaries are searched which can adversely impact performance.
OracleAS Personalization recommendations are personalized for each customer. A customer can be an anonymous visitor or registered customer at a Web site, or can also be a customer calling in to a call center, using an ATM machine, or using a wireless phone. To serve recommendations, applications make Java-API calls to OracleAS Personalization.
OracleAS Personalization collects customer profile data and uses them to build predictive models that support personalized recommendations. The underlying rules derived through data mining can be more sophisticated and thus yield better results than the other techniques noted above. For example, "a person who has clicked links x and y and who has demographic characteristics a and b is likely to buy z."
OracleAS Personalization incorporates customer activity into its recommendations in real time, for example, during a customer's Web session. Using OracleAS Personalization, the application records a customer's navigation through the Web site noting the links that are clicked, customer responses to requests to rate items such as books or movies, customer purchases, and any updates to customer demographic information. All this data becomes part of the customer's profile which is stored in the Oracle database. OracleAS Personalization uses all customers' profiles to build predictive models. This data can be updated with data collected in subsequent sessions, thereby increasing the accuracy of predictions when new models are built.
OracleAS Personalization can work in conjunction with an existing Web application or other customer applications. The application asks OracleAS Personalization to produce a list of items likely to be of interest to the customer. A scored list of recommendations is returned to the application.
Although recommendations to Web site users is one important use of OracleAS Personalization, OracleAS Personalization can provide recommendations in other situations. Any application that collects customer data and needs to provide personalized recommendations can use OracleAS Personalization.
In addition to the real-time recommendations interface, OracleAS Personalization also has a batch interface that can be used to generate recommendations offline. Such recommendations would be useful in, for example, marketing campaigns.
The OracleAS Personalization components consist of:
Recommendation Engine Application Programming Interface (REAPI): A collection of Java classes that enables an application to provide profile data used to build OracleAS Personalization predictive models and to obtain recommendations in real-time from OracleAS Personalization from Recommendation Engines.
Recommendation Engine (RE): An RE consists of programs and tables (RE schema) in an Oracle database. The RE supports an application written in Java for collecting and preprocessing customer and visitor data, and for providing recommendations to those customers and visitors. Access to the RE is provided through the REAPI. A given RE may support one or more Java server processes in a Web application.
Recommendation Engine Farm (RE Farm): A logical grouping of one or more REs that are populated with the same predictive model package. An RE Farm is generally treated as a single unit for management from the Administrative UI. Also, the REs in the RE Farm can be in separate databases for improvements in scalability and availability.
Administrative UI: A browser-based user interface that permits the OracleAS Personalization Administrator to schedule package builds, deployments, and reports, manage RE Farms and REs, and otherwise manage OracleAS Personalization. Chapter 2 describes the Administrative UI in detail.
Mining Object Repository (MOR): The MOR holds all the programs and tables that are responsible for OracleAS Personalization's administrative functions. Access to the MOR is provided by the Administrative UI. MOR is the schema that maintains the predictive model packages, package settings, and build and deployment schedules for packages. It contains the algorithms that build the predictive models.
Predictive Model Package: An object created using the Administrative UI. A predictive model package contains data mining predictive models derived from historical customer profile data. The administrator defines the package, which is scheduled for deployment through the Administrative UI. After the package build is complete, the package consists of the predictive model tables that are deployed to the recommendation engines in the specified RE Farm (see Figure 1-1). This is also referred to as just "package" in this document.
Mining Table Repository (MTR): The MTR contains the schema and all data to be used for data mining. The MTR has a fixed schema designed to support the building of predictive models.
Batch Recommendation Engine API: A collection of Java classes that permits users to obtain recommendations in batch, that is, offline.
OracleAS Personalization requires both Oracle Database and Oracle Application Server. Oracle Databases and Oracle Application Server can either be installed on the same system or on different systems.
The Administrative UI runs on the same system as Oracle Application Server.
The REAPI and RE Batch API exist on the same system as the applications using them. These applications need not necessarily run on same system as Oracle Application Server.
All other components are installed on the system where the database is installed. The MTR, MOR, and RE need not be installed in the same database. For improved scalability and availability, they may be installed on separate Oracle databases.
OracleAS Personalization's components and process are depicted in Figure 1-1. The diagram is a flow chart of the entire OracleAS Personalization process.
Figure 1-1 OracleAS Personalization Process
Existing customer data is mapped to the MTR schema (step 1). The data in the MTR is used to build a package in the MOR (step 2). Once that package is built, it is deployed to the recommendation engine farm (step 3), where it is used to generate recommendations that are then passed to the application (step 4). The application collects data through the REAPI data collection methods, which are passed back to the REs (step 5) and are eventually synchronized back to the MTR (step 6).
Populating the MTR
There are two ways of getting data into the MTR. The first way is to map existing customer profile data (navigation, purchasing, ratings, and demographics) from application databases onto the MTR schema using database views. This method enables you to build packages immediately and start generating recommendations. However, if you do not have existing profile data, you can use the seed data that is optionally installed with OracleAS Personalization to initialize the MTR. A predictive model cannot be built without data in the MTR.
The second way to get data into the MTR is through the REAPI data collection methods, which are called by an application. As a customer or visitor interacts with your application, your application makes calls to the REAPI to collect data in the RE. The RE then synchronizes the data back to the MTR. Subsequent package builds are made using this data.
Note that to collect data using REAPI calls, there must be a deployed package in the RE. Once you have built and deployed a package, you can collect data using the REAPI. Figure 1-2 provides a graphical depiction of the process cycle.
Figure 1-2 Data collection, package build and deploy, generate recommendations cycle
OracleAS Personalization collects the following kinds of data:
navigation data
ratings data
purchasing data
demographic data
Of these, navigational data allows the most flexibility. It can represent anything an application wants to consider that is of interest to the customer. For example, in a Web application, a "hit" may be a customer viewing a page or clicking a link/item.
Navigation, ratings, purchasing, and demographics data are also known collectively as customer profile data.
OracleAS Personalization collects the data using Java calls provided by the REAPI. These calls add information for the specific session, identified by a session ID. The RE finds the correct session ID by looking up one of the following arguments passed in the REAPI calls:
appSessionID -- used by stateful Web applications (that is, an application that stores an identifier for each session)
customerID -- used by stateless Web applications (that is, an application that does not store an identifier for each session)
The data temporarily stored in the REAPI cache is periodically flushed and sent to the appropriate RE. The session data is then used, combined with the customer's historical profile data and predictive models, to generate recommendations. Finally, the RE instance periodically flushes the data to the Mining Table Repository (MTR) for sessions that have concluded or timed out. The OracleAS Personalization administrator can set configuration parameters to indicate what data is saved to the MTR. The data in the MTR is then used to build predictive models for future deployment via packages.
OracleAS Personalization uses custom profile data, data preparation specifications such as binning and item classification taxonomies to build predictive models. The data mining algorithms used by OracleAS Personalization analyze customer historical data resulting in the predictive model.
As more and newer customer profile data is collected and made available to Oracle Application Server, the accuracy of the recommendations generated by the models can improve. Hence, predictive models should be rebuilt whenever significant amounts of new profile data is added to the MTR. OracleAS Personalization provides the option to include the most recent n days of data from which to build a predictive model. This sliding window may, for example, specify the most recent 90 days.
The OracleAS Personalization administrator creates and manages schedules for building the packages, and for deploying the packages to the recommendation engines (REs). For ease of management and reliability reasons, recommendation engines with the same package are grouped together in recommendation engine farms (RE Farms).
OracleAS Personalization uses two algorithms: Transactional Naive Bayes (TNB) and Predictive Association Rules (PAR). For ratings-related recommendations, the model produced by TNB is used. For cross-sell related recommendations, PAR is used. See Appendix A for a description of the algorithms.
A taxonomy, also known as concept hierarchy, defines classifications for a set of items, for example, products, Web pages, or documents. In OracleAS Personalization, an item can be a member of multiple categories, and each category can be a member of another category. For example, the catalog of a Web site using OracleAS Personalization has taxonomies with the most general category at the base (for example, "clothing"), and branching to increasingly specific categories (for example, from "clothing" to "shoes" to "sneakers" to "tennis shoes").
Items and categories can belong to more than one category and at different levels of the structure. For example, "tennis shoes" can be a category in "clothing" and also a category in "sports equipment."
The OracleAS Personalization taxonomy type is a direct acyclic graph (DAG), which can contain multiple top-level nodes, but there cannot be a path that connects a node's child back to the node itself. The different portions of the taxonomy can be disconnected too. The example in Figure 1-3 is a DAG.
Figure 1-3 Example of an OracleAS Personalization taxonomy
OracleAS Personalization also supports multiple taxonomies (different ways of organizing the items). Each unique taxonomy can be specified with a unique taxonomy ID. You can define each taxonomy according to how you want to retrieve recommendations (see Section 1.7.3, "Filtering Recommendations"). A taxonomy is implemented using a group of tables in the OracleAS Personalization MTR schema. The predictive models built in OracleAS Personalization use the taxonomies to generate category-to-category and category-to-item rules in addition to item-to-item rules.
In OracleAS Personalization, recommendations can be filtered to include or exclude items under a category level for a taxonomy. An application can filter recommendations using the FilteringSettings
class in the REAPI. This class allows the filtering of categories and category subtrees through to the leaf items.
As an example of using the REAPI for filtering, consider the taxonomy illustrated in Figure 1-3. If you desire to obtain recommendations from the "Shoes" category, your Web application can use the FilterSettings.setCategorySubTreeFiltering()
method to obtain recommendations among "Sneakers," "Tennis Shoes," "Running Shoes," and items in their subtrees.
See Also: FilteringSettings class in Oracle Application Server Personalization Programmer's Guide and Oracle Application Server Personalization Java API Reference.
|