|Oracle® Real-Time Decisions for Siebel E-Commerce Installation and Reference Guide
Part Number E12261-01
Oracle Real-Time Decisions (Oracle RTD) enables you to develop adaptive enterprise software solutions. These solutions are adaptive because they use rules and predictive models to continuously learn from business process transactions as those transactions are executing. By continuously learning in real time, the adaptive solutions that you develop can optimize the outcome of each transaction and of the associated business process.
This chapter presents an overview of Oracle RTD, and of the Oracle RTD features that are used when Oracle RTD is integrated with external applications.
This chapter consists of the following topics:
The heart of Oracle RTD is a "decision engine" that helps users make decisions, by recommending the best options when they make their choices.
To illustrate the principles of the decision process and how these are incorporated in the Oracle RTD "decision engine", consider a common real-world decision: whether or not to accept a job offer from one of several companies that you have been investigating?
The data involved in the decision making process can be extensive. For example, a small subsection of job-related data to collect and evaluate could be:
Company offering the job
|VeriLeaf||Quality Manager||Green Acres||220,000||Good|
|FaunaFlex||Project Manager||North Elk||200,000||High|
As well as gathering as much specific information as possible about the job, there are a number of key general questions that you as a prospective job hunter should address:
What are your choices?
As a simplification, assume that the choices in this example are to accept a single job offer, from one of the companies.
What are your goals?
You may have one or more goals that need to be compared and evaluated, for example:
Minimize your daily travel time
Maximize your financial compensation
Improve your quality of life
What are the criteria for evaluating your choices against your goals?
In the real-life job-hunting situation, you typically have your own personal evaluation criteria, based on your requirements and past experiences. The process of evaluating your choices is often intuitive. However, the evaluation process can include satisfying more formal, numeric conditions, such as the requirement for a particular minimum salary.
In the Oracle RTD decision process, evaluation criteria are implemented by an ordering algorithm that prioritizes choices by assigning scores to them.
The scores for each Oracle RTD choice are computed using one or more of the following scoring methods:
The rule driven scoring method uses explicit business rules, such as "Salary must be at least 200000" or "Promotion Prospect must be Good or High"
The model driven scoring method uses implicit rules discovered from analyzing historical data stored in an Oracle RTD predictive model
When there are several performance goals for a decision, you can weight the goals. For example:
|Maximize your daily travel time||30|
|Maximize your financial compensation||50|
|Improve your quality of life||20|
Oracle RTD can score each choice against each performance goal or weighted combination of goals.
The net effect is that Oracle RTD provides a numeric score for each choice, such as in the following table:
|VeriLeaf||Quality Manager||Green Acres||220,000||Good||Accept VeriLeaf job||60|
|PlentiSol||Research Director||Balmington||250,000||Fair||Accept PlentiSol job||50|
|FaunaFlex||Project Manager||North Elk||200,000||High||Accept FaunaFlex job||80|
Oracle RTD Decision Making Features Overview
The overall principles and underlying elements described in the job hunting example are incorporated as basic features of Oracle RTD, as shown in the following table:
|Questions in the Decision Making Process||Oracle RTD Features|
|What are your choices?||Choices|
|What are your goals?||Performance Goals|
|What are your criteria for evaluating those goals?||Rules and Models|
The following diagram shows a high-level overview of how these features interact to fulfill the basic objective of Oracle RTD, namely to provide recommendations from a number of alternatives or choices.
For more information on these features and how to use them in Oracle RTD, see the following sections:
In general, Oracle RTD connects with other applications, and passes its recommendations to these external applications. See the next section for more information about how Oracle RTD integrates with external applications.
Applications that you develop to interact with Oracle RTD are referred to as external applications. Typically external applications consist of many processing steps and stages. The points at which external applications communicate with Oracle RTD are generically known as Integration Points.
There are two main types of Integration Point:
An Informant is a process that passes data from the external application to Oracle RTD
An Advisor is a two-way process, that both passes data from the external application to Oracle RTD, and also receives data sent back from Oracle RTD to the external application
Advisors are the main method by which an external application requests and receives recommendations from Oracle RTD.
Each external application can have many Informants and Advisors.
Many applications are based on a dialog with a user, which leads to the application presenting alternative strategies or choices to the user.
Typically, the dialog between the application and the user proceeds as follows:
The user starts a transaction.
The application retrieves information about the user.
Optionally, the user provides extra information concerning the transaction.
The application presents the user with one or more choices.
The user accepts or ignores the choice or choices.
Optionally, the previous two stages may be performed several times during the course of the transaction.
The user ends the transaction.
To determine which choices to present to a user, external applications can use various factors, such as:
Profile information about the user
Current information about the transaction
The user's preferences, if known
Past activities or transactions associated with the user
User access method, such as the Web or a custom interface
Time of day, month, or season
Oracle RTD provides a set of tools that can analyze all these factors, and recommend the best choices to the external applications. Through these recommendations, Oracle RTD enables the companies that run the external applications to make better business decisions.
Figure 2-1 shows, in outline form, how a typical application interfaces with Oracle RTD.
Figure 2-1 shows one Advisor and four Informants, the Informants corresponding to the following key stages in the application:
The user has started the transaction.
The external application has acquired more information about the user.
The user has accepted or rejected a choice.
The user has ended the transaction.
This section shows the general Oracle RTD decision process flow. For details about the Oracle RTD features and elements used in the process flow, see Section 2.5, "More About the Oracle RTD Decision Process Elements."
The Oracle RTD decision process is based on a framework that takes into account the following factors:
The overall performance goals with which an organization is concerned
The action required to score each of the available choices
A weighting of the performance goals based on segments of the population
Decisions are called by Advisors to score Choices, and return one or more Choices from a Choice Group. The set up of a Decision must include at least one Choice Group from which Choices are selected, and a function or rule to score the Choices. At run time, the Decision collects all the eligible Choices that exist in each of the Choice Groups. Then, the Choices are scored to finally determine the ranked order to send back through the Advisor.
Figure 2-2 shows the basic Oracle RTD processes, which include session start and finish, as well as the Oracle RTD decision process steps.
The steps represent the different stages in the overall process of acquiring the necessary data and processing a decision, as follows:
The system initiates the session.
When a user log on, and the external application connects to Oracle RTD, Oracle RTD establishes a session.
The external application generally acquires as much information about the user as possible, and passes it to Oracle RTD using one or more Informants.
Oracle RTD may also retrieve further information from Data Sources and Entities defined in the Inline Service associated with the external application.
The Advisor calls a Decision.
A request through an Advisor call initiates the decision process. The set of choices to evaluate for the decision is then determined for each of the associated Choice groups.
The eligibility of Choices is determined.
The eligibility rules for the Choices are invoked, to determine which Choices pass on to the next stage of the decision process.
The user segment is determined.
Filtering rules, if created, are then used to segment the user population. Based on the segment, the designated weightings for each of the Performance Goals is used in scoring each eligible Choice.
The Choices are scored.
All eligible Choices are scored for each associated Performance Goal.
The Choice scores are weighted.
Based on the segment, different weights are applied to the Performance Goal scores.
The Choice or Choices are returned to the external application.
Oracle RTD returns one or more Choices to the external application, passing Choice names and any designated Choice attribute that the external application needs. The requesting application then displays the Choices or processes the information accordingly.
The session information is updated.
This step can take place at any stage of the decision process. Its main effect is to update the Oracle RTD server with any new available information about the given session.
In addition, Models can be updated from the session information either at specified integration points or at the end of the session.
The session is closed.
The active Oracle RTD session is closed and any wrap up logic is executed, including learning on any Models defined to learn at session close.
This section provides more details about the following Oracle RTD elements used in the decision processing framework:
Designers creating a decision process for an organization must consider the overall Performance Goals of the organization. Performance Goals consist of the specific metrics with which the organization has chosen to measure its success. These goals are then associated to choice groups and decisions to identify how each choice will be scored against those them. Some common performance metrics are revenue, costs, number of products per customer, and customer satisfaction.
If you set more than one Performance Goal in an Inline Service, you must specify the relative importance of each one by assigning normalization factors for each Performance Goal.
Decisions score eligible Choices and rank them based on the weightings given for associated Performance Goals.
Oracle RTD supports the following types of Decisions:
Rule-driven Decisions are defined in business related terms expressed by business users. An example could be the business rule not to sell credit cards to customers when their credit rating is low.
Model-driven Decisions are driven by scores calculated and determined by Models formed from empirical data. An example could be the decision to present an Overdraft Protection offer to a call center user who lives in California, whose occupation is graphical artist, and who has called to change his address. Based on its previous learnings, the model has determined that similar users are 61% likely to accept the Overdraft Protection offer.
Hybrid Decisions use the scoring methods of both the Rule-driven and the Model-driven decisions.
In general, each Decision may be associated with:
One or more Choice Groups
One or more Performance Goals
One or more segments of the user population, where each segment can have different weightings for each Performance Goal
Choice Groups and Choices are the Inline Service elements from which Decisions draw their possible Choices, and which become targets of analysis for Choice and Choice Event Models.
Choice Groups and Choices form a hierarchy, where:
Each Choice belongs to one Choice Group only
Each Choice Group can have one or more sub-Choice Groups
Choices exist only at the lowest level of a Choice Group hierarchy branch.
Choices can be used by a Decision, so that they can be returned by Advisors, and can be registered to either Choice or Choice Event models through Informants.
Choice Group and Choice Attributes
Choice Groups and Choices have attributes, that is, data used in the processing and presentation of Choices.
Typically, you define the attributes of Choices at a higher Choice Group level, where you can also specify default values for the attributes. The Choice Group attributes are inherited by lower level Choice Groups and Choices. You can override default values at the lower levels.
Static and Dynamic Choices
Choices can either be static or dynamic.
Static Choices are explicitly defined in the Inline Service.
Dynamic Choices are Choices that are stored and maintained in an external application, such as promotions stored in a separate marketing application. When required for the decision process, Dynamic Choices are retrieved from the external application. The mechanisms for retrieving and using Dynamic Choices are defined in the Inline Service, but the actual Dynamic Choice values may vary for each user session.
For more information about Dynamic Choices, see Oracle Real-Time Decisions New Features Guide Version 2.2.1
Choices and choice groups have rules that determine their eligibility to participate in a decision.
You can define eligibility rules at the Choice Group and Choice levels.
Choices inherit rules from higher levels, and may also have their own rules. At each level, a logical AND is performed between the higher-level rules and the current-level rule, with the result placed in the current-level element.
Choices and Choice Groups can use filtering rules as another form of eligibility. In addition, a filtering rule can also be used to segment the user population for which Decisions are being made, and controls the effect of each Performance Goal associated to the Decision.
Scoring rules are similar in setup to eligibility rules, but rather than evaluate the rule to a TRUE/FALSE outcome, a numeric score is returned instead. A score can be computed for a given Performance Goal tied to a Choice, and can affect the rank of the Choices in the decision process.
There are two standard types of model in Oracle RTD:
Choice Event Model
Each Choice Model or Choice Event Model is always associated with a single Choice Group.
Both types of model can be used for prediction and for generating analysis reports.
The main objective of any model is to show, for each choice of the associated choice group, what factors influenced a particular choice.
Models are updated with, and "learn" from the following data:
All the data in the Session entity - specifically, all the Session attributes, unless specifically excluded from analysis through the Inline Service configuration
In addition, Choice Event Models also require event-related details. For more information, see Section 188.8.131.52, "Choice Event Models."
The update and learning process happens in a transaction either at session close or at any integration point.
Both types of model can be used for prediction and for generating analysis reports.
The outputs generated directly and indirectly from a model are as follows:
Model scores for a given Choice which can be used as part of the decision process
Analytic reports in the Decision Center
Model snapshots that enable users to generate their own analytic reports
The main objective of a Choice Model is, for each choice, to derive meaningful information from the data associated simply with the choice itself. A Choice Model does not need the extra dimension of base and positive outcome events, which are required for Choice Event Models.
For instance, in a call center application, one of the key data elements is the reason for a call. After collecting more information about the call and the caller, you can provide this information to a Call Reason Choice Model, and then use this in Oracle RTD Decision Center to analyze and compare the driving attributes of different call reasons.
Another example of a Choice Model is an Abandonment Model, with two choices, Abandoned and Not Abandoned. For both choices, the model stores data associated with the user and the transaction, and whether the user abandoned the transaction before completion. You can use the model not only to analyze potential abandonment factors, but also to predict the likelihood of whether subsequent users will abandon their transactions.
For each Oracle RTD Choice Event Model, in addition to specifying a Choice Group, you must also specify one Base event and one or more Positive Outcome events.
In the simplest case, there are two significant events in a transaction, the presentation of a choice and the acceptance of the choice.
In Oracle RTD, events are defined at the Choice Group level, and selected within the Model to describe "base" and "success" parameters.
For each Choice Event Model, you must define:
One Base event, used as the base for analysis.
Typically, this is the event associated with the presentation of the choice.
One or more Positive Outcome events, each of which indicate a successful prediction.
Typically, the standard positive outcome event is the event associated with the acceptance of the choice.
Some Oracle RTD objects have a general usage within and across Oracle RTD processes. This section describes the following general Oracle RTD elements and features:
A Data Source is configured in an Inline Service to access data from an outside source. The structure and format of Data Sources can vary, as follows:
The rows and columns of a database table or view
The output values and result row sets from a stored procedure
A Data Source can be configured to retrieve either a single record or multiple rows.
Each Data Source contains Input and Output columns:
The Input columns are used in the WHERE clause of the query to the Data Source to select the rows to retrieve.
The Output columns are the data that is retrieved and used by Oracle RTD in the decision process.
An Entity is a logical representation of data, that can be populated from one or more Data Sources, through data retrieved by an Integration Point, or through functional derivations. Entities are the data objects that can be used by the other Oracle RTD elements, and form a logical level of abstraction from Data Sources and Integration Points.
An Entity is a set of named attributes and methods to access the attributes. One attribute per Entity is usually designated as the Entity key.
An attribute of an Entity is analogous to a column of a database table, with one important distinction: an Oracle RTD attribute may consist either of one value or many values. The type of attribute that can have multiple values is called an Array attribute.
The integration of Entities and their component attributes to the appropriate data is implemented by mapping. You can explicitly map Entity attributes to Data Source columns, or you can implicitly map them through the use of Java functions that populate the Entity attributes.
An Entity, while it contains its own attributes, may also be an attribute of another Entity. For example, a customer can have many orders. In Oracle RTD, you can define Customers and Orders as separate Entities, mapped from corresponding Data Sources. You can then specify the Orders Entity to be an attribute of the Customers Entity.
The Session is the fundamental Oracle RTD unit of run-time data. Data is kept in memory for the duration of the Session. Every Inline Service contains one Session Entity.
For a Model to be able to learn from the attributes of a non-Session Entity, that Entity must be defined as an attribute of the Session Entity.
For example, in an Inline Service, you can define Customer, Call, and Product as logical Entities, and then add these as attributes to the Session Entity, so that the Oracle RTD server can use these Entities as inputs to the Models.
Functions, written in Java, provide extra processing capabilities to many Oracle RTD elements. For example, selection functions can be used by decisions as a custom way to make a choice.
Functions can also serve as general-purpose code, for example, to determine date differences, or to convert data into different data types.
Other users of functions include:
Populating derived entity attributes
Comparing values in choice eligibility rules
Retrieving lookup values
Writing to log files
Functions may also call other functions.
An Oracle RTD Inline Service consists of all the Oracle RTD elements necessary to interface with an external application and model the desired business process.
The main elements of an Inline Service are the following:
Choice Groups and Choices
Not all Inline Services have all of these elements. The specific requirements of each external application determine which elements are needed in the associated Inline Service.
In Oracle RTD, you define the Inline Service elements in the Oracle RTD Decision Studio. You must first configure, then deploy an Inline Service to the Oracle RTD server before the Inline Service can be used by an application.
Figure 2-3 shows some of the elements of an Inline Service, called Cross Sell, as displayed in the Decision Studio.
For more information about how to define and deploy Inline Services, see Oracle Real-Time Decisions Decision Studio Reference Guide.
Oracle RTD Decision Center is a client tool for business users to explore, analyze, examine, and even modify the structure and data gathered by a deployed Inline Service.
The Oracle RTD Decision Center provides a variety of analytic reports, both for performance analysis and model analysis.
For example, there are several reports at the choice group and choice level, such as the following examples from a Cross Sell application:
Choice Group Performance Counts
The Choice Group Performance Counts shows the total counts for each choice or choice event occurrence in a choice group.
Choice Analysis Drivers
The Choice Analysis Drivers report identifies the attributes that are influential as drivers of predictiveness for each of the choices.
Predictiveness is a measure of the relationship strength between entity attributes, that are the model input, and choice and choice events, that are the model output.
A drilldown on any of the attribute hyperlinks will reveal additional reports about the attribute values themselves.
Choice Analysis Trends
The Choice Analysis Trends report shows the change of predictiveness for each of the attributes for a choice over two selected model time windows.
Choice Analysis Best Fit
The Choice Analysis Best Fit report shows all the attributes and values that are most likely to predict the specified event outcome.
Oracle RTD also provides a variety reports that show the effectiveness of entities and entity attributes for predicting choices.
For more information about how to view, analyze, and modify the structure and data of Inline Services in the Decision Center, see Oracle Real-Time Decisions Decision Center User Guide.