Oracle9iAS Personalization Programmer's Guide Release 2 (v9.0.2) Part Number A95245-02 |
|
The REBatchProxy methods described in Chapter 8 permit to write Java programs that generate recommendations.
To use REProxyBatch
API calls, you must perform the following steps:
REBatchProxy
.
You will now have a table containing the recommendations that you requested. You can use SQL to examine the table.
The following code sample illustrates obtaining a recommendation:
// Create an instance of REProxyBatch
// Create customer table
// Load customer profiles
// Execute recommend_top
// Purge customer profiles loaded above
// Destroy the database connection held by REProxyBatch
The following code sample illustrates obtaining cross-sell recommendations:
// Create an instance of REProxyBatch
// Create Items table
// Execute cross sell for items
// Destroy the database connection held by REProxyBatch
REBatchProxy
requires at least one recommendation engine (RE) in at least one recommendation engine farm.
We recommend that the REs used for bulk recommendations not be used for any other purpose.
In general, you may want to use more than one RE to get satisfactory recommendation performance. Most applications will use multiple REs on different machines and subsequently different database instances.
Typically, for a given application, these REs will belong to the same RE farm. If a physical system has multiple processors, and the processors can be leveraged effectively by the database, the number of REs required for a given number of users can be reduced, perhaps even to one. See the administrator's guide for more information.
If your application has more than one RE available for use, it must determine which one to use. You can load different sets of customer profiles into different REs, generate appropriate recommendations, and them merge the recommendation tables, if desired.
OP stores currency data in the demographic table (for example, someone's income) as numbers; that is, OP does not store any kind of label. Both ten dollars (US) and ten pounds sterling (UK) are stored as "10".
There are several ways to ensure that currency data is interpreted correctly; the solution that you pick for your application depends on the way your application uses currency data.
This solution allows the country to be taken into account, but it does not closely associate the value with the country.
This solution permits you to compare individual currency values in a meaningful way (10 pounds sterling is more than $10 US) but does not permit you preserve the difference between data such as a salary of $30,000 US in the US, versus the same $30,000 US salary in Brazil. You need such information if, for example, you want to recommend items to highly remunerated individuals in both the US and Brazil; the salary in US dollars of highly remunerated individuals will vary considerably from country to country.
This approach requires that you preprocess the data outside of OP before OP creates recommendations.
This solution would permit you, for example, to determine the highly remunerated individuals for a given country, but it requires that you determine and maintain the bin boundaries appropriately.
This approach requires that you preprocess the data outside of OP before OP creates recommendations.
The schema of the MTR_CUSTOMER table consists of 50 generic attributes that can be mapped to any column in the site database. In order to support all different data types, all attributes are of type VARCHAR. Therefore, the mapped columns should be converted to strings. In this release of OP, these mapped columns are treated as categorical or numeric only. If any of the mapped columns is a DATE attribute, it should be converted to a number using the TO_NUMBER function. The converted values can then be binned just like any other attribute by specifying the bin boundaries.
There is binning for demographic data. The attributes that are binned can be of type boolean
. In OP, the bin numbers are represented internally as integers, but the actual values are passed back to the calling applications. That is, the Web application passes in the actual values and gets back actual values.
For certain items, such as airline tickets, the price depends on when the item is purchased. For example, an airline ticket for a Boston to London flight has one price if it purchased 6 months before the date of the flight and a different price if it is purchased two days before the date of the flight.
If the Web application assigns the same item ID to all tickets for the same trip, regardless of when they are purchased, then the items should have different item types, such as "6 month advance", "2 day advance", etc. Alternatively, the application could define taxonomies on the items and get recommendations on the categories.
If the application assigns different item IDs to the same flight purchased at different times (so that a ticket purchased 6 months before the flight has a different ID from a ticket for the same flight purchased 2 days before the flight), all tickets can have the same item type. In this case recommending item IDs may not be appropriate; therefore, the application should define a taxonomy and request recommendations on the categories.
|
Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|