Existing e-commerce personalization tools based on on-line decision support use rules languages that are quite limited in expressive power. For example, Manna [15] provides an event-condition-action rules language, where the actions result in side effects outside of the rules system. There is no chaining of rules, which limits the expressive power. For example, it is not feasible in these systems to use a cluster of rules to compute a business opportunity score, another cluster of rules to compute a customer frustration score, and a final cluster of rules that combines the two scores and other information to select an appropriate action. The scripting language of Blaze [2] provides flowchart constructs, where a node in a flowchart may contain a set of rules. Inside such flowchart nodes there is no chaining of the rules. And so any rule chaining that needs to be expressed is explicit in the use of flowchart constructs between the rules nodes. As a result, users must explicitly specify essentially all flow of control for the decision-making process. For complex decisions this is too cumbersome for business analysts and managers.
What about using some other, existing decision specification system to support e-commerce personalization? Decision trees are too confining in their logic. Logic programming [14], including variants that incorporate negation (e.g., [21,10]), while Turing complete, is both too expressive (because it is hard to develop reports that easily explain how decisions are reached) and too confining (because it forces a single semantics for combining rules which makes it hard to directly express both formal and heuristic styles of reasoning). Expert systems (e.g., OPS5 [3]) are also too expressive, because it is difficult to explain how decisions are reached, and difficult to predict the overall effect of modifying a rule. One candidate that met several of the user requirements is the RAISE system [9]; however, the adherence to a logic-programming style of rules did not support directly expressing both formal and heuristic styles of reasoning.
Personalization based on off-line decision support (e.g., Epiphany [8], Net Perceptions [17]) performs periodic bulk data analysis using data mining and statistical techniques to infer correspondences between, e.g., customer types, products already selected, and products that would be appropriate for targeted promotion. As with other on-line approaches, DFP is complimentary to the off-line approach, and decisions made using DFP can access the results of off-line analysis.
Another tool that can be used for on-line decision support is described in [16], which presents a formalism for scoring the quality of data assembled from multiple sources. The formalism uses vectors giving scores to various criteria, along with operators to combine vectors; these combinations correspond to combinations of scientific data performed in the underlying workflow. The Decision Flow paradigm can express this formalism, because it supports direct manipulation of record types, and can include the operators for combining vectors as named combining policies.
We contrast our approach with another popular approach for customizing web-sites, that is based on guiding the customer through a series of questions that are used to identify customer preferences and their relative weights (e.g., Personalogic [19]). More generally, [1] presents a framework for specifying and combining preferences, that provides high flexibility and satisfies mathematical properties such as closure under certain operations. The Decision Flow paradigm can simulate this preference model by using record structures and specialized combining policies.
The DFP approach consists of using an on-line decision engine that is separate from the web server. An alternative would be to use some form of server-side scripting language (e.g., ASP, JSP, or PHP), that could hold the business logic for on-line decision making. The fundamental problem here is that these scripting languages do not satisfy several of the requirements on the decision specification language, such as the explicit presence of rules, the ability to combine information in different ways, or the correspondence between programs and reports.
Finally, the MIHU system presented here differs from previous systems for presenting live CSR assistance to customers. For example, iContact [13] uses a simple rules mechanism to identify customer sessions on a web store-front that are ``good'' candidates for live CSR assistance. However, with iContact the CSRs are given a listing of these candidates, and the CSRs make the final decision about whether or not to offer live intervention. With the MIHU system the entire decision can be automated (taking into account not only the business opportunity afforded by the customer, but also the current availability of CSRs to help realize this opportunity). This permits treatment of customers which is more uniform than with the iContact approach. The MIHU system also permits more careful selection of a CSR whose skill matches the expected needs of a given web-based customer. Finally, it can support more sophistication in the use of ``blended'' CSRs, who spend some time with web-hosted customers and other time with traditional telephone-based customers.