Domain-Oriented Recommender Applications: A Framework for Intimate Recommending Markus Stolze IBM Research, Zurich Research Laboratory 8803 Rüschlikon, Switzerland
[email protected]
Abstract. The algorithms and technology components used by e-commerce recommender applications are maturing. A central question for online shops in the future will be how to integrate recommender applications into their shop, so as to not only sell goods to new customers, but also to maintain and expand their complex relationship with existing customers. Today most recommender applications are independent add-ons to an online shop. As such, they can only provide isolated recommendations that either only relate to a single interest of a visitor, or have visitors explicitly state their current preferences – which are forgotten the next time the customer comes. In this paper we propose domainoriented recommender applications as a conceptual framework that can guide designers of online shops in creating recommender systems that have a more intimate knowledge of customers and their evolving areas of interest.
1 Introduction E-Commerce recommender applications are an important technology for online retailers who want to increase their sales by providing visitors with personalized product recommendations. These applications help to convert browsers into buyers, increase cross-sells, and build loyalty (Schafer, et al., 2001). Retailers use recommender systems together with other personalization technologies to realize adaptive web-based customer relationship management (Kobsa et al., 2001), mass-customization, and oneto-one marketing (Peppers & Roger, 1997). Studies indicate that e-commerce sites that offer personalization convert twice as many visitors into buyers than sites that do not offer personalization (ICONOCAST, 1999, cited in Fink & Kobsa, 2000). E-Commerce recommender applications not only provide useful functionality to online retailers, but are also an active area of research that has attracted researchers from various research communities such as information retrieval and algorithms analysis (Balabanovic & Shoham, 1997; Breese et al., 1998; Sarwar et al., 2001), cased-based reasoning and other AI techniques (Burke et al., 1997; Cunningham et al. 2001; Shimazu, 2001), user modeling and adaptive systems (Ardissono et al., 2001; Kobsa et al., 2001; Stolze & Ströbel, 2001a), decision sciences (Nguyen & Haddawy, 1998), system architecture (Stolze & Ströbel, 2001b), human–computer interaction
(Terveen & Hill, 2002; Steiger et al., 1998; Stolze, 1999), as well as consumer psychology and marketing (Spiekermann & Parachiv, 2002; Häubl & Trifts, 2000). A central ingredient for recommender applications is the establishment of a user profile (or “user model”) that allows predicting what products are of current interest to the visitor. For applications that recommend products relating to long-term interests (such as books), it makes sense to store collected profile information (“persistent personalization,” cf. Schafer et al., 2001). In other product areas (such as appliances or home electronic equipment) buyer interests typically only relate to a single buying session, and profile information is typically not re-used in later sessions (“ephemeral personalization”). However, most recommender applications (persistent as well as ephemeral) tend to ignore that visitors come with particular goals and needs they want to see fulfilled by the product they buy and that these needs are shaped by the context of their buying activity (e.g. the things they own or have given to the person the current buy is a present for). For example, a person who bought books from Amazon for her 14-year old, horse-loving nice might be annoyed by “recommendations” that appear when she, together with a work colleague, log into Amazon to search for a jobrelated book (Stolze & Ströbel, 2001b). Ephemeral recommender applications, by nature, place stronger emphasis on the current interests of a visitor, but many applications focus exclusively on eliciting preferences relating directly to product properties. This is particular problematic for buyers with little product knowledge, who want to receive recommendations based on their personal needs and expected uses of the product (Grenci & Todd, 2002; Felix et al., 2001). Some ephemeral recommendation applications have started to provide also needs-based recommendations of products (e.g. active buyers guide, www.activeBuyersGuide.com) but to our knowledge only a single site (JD Powers Auto Recommendation, www.jdpower.com/auto) shows visitors an explicit evaluation of products with respect to their stated needs (but is less sophisticated in many other respects). In contrast to the above systems, Domain-Oriented Recommender Applications (DORAs) take as their primary focus to help visitors specify their needs, to represent and manage different buying contexts over time, and to analyze and evaluate products with respect to the stated needs. In the next section we will explain the concept of a DORA in greater detail and present a generic architecture. We then give, as an illustration, an example of a DORA for a gardening supply shop, and discuss how the DORA architecture can be used to analyze existing recommender applications. We finish by discussing our plans and directions.
2 Domain-Oriented Recommender Applications The concept of DORAs is derived from the work on Domain-Oriented Design Environments (DODEs) (Fischer, 1994), which provides a conceptual architecture for design support tools. Figure 1 shows the main components of a DODE.
Construction Component Simulation Component
Critiquing Component
Specification Component
Catalog Component
Argumentation Component
Fig. 1. Main DODE Components (adapted from Fischer, 1994)
The most important DODE component is the Construction Component. This is often a domain-oriented graphical editor that allows designers to create their designs (or visual representations thereof.) For example, in the domain of kitchen design, the construction component is a visual floor-plan editor for kitchens. The Catalog Component holds design components, and reusable design cases. The Argumentation Component supports designers in annotating their designs with design rational. The Specification Component lets designers specify high-level properties and criteria their design should fulfill. For example, in the kitchen design domain, a designer might want to specify that the kitchen should be for a large family and that resell value is an important criterion. The Critiquing Component constantly checks the emerging design against the defined goals and criteria and provides the designer with reminders and critiques that point out sub-optimum performance of a design with respect to a set specification or a generic design guideline. So, in our example, the critiquing component might point out that the current kitchen design does not optimize the resale value, as the drip-off area should ideally be to the left of the sink in kitchens designed for the majority of right-handed people. The final DODE component is the Simulation Component. It lets designers simulate, observe, and thereby evaluate their design in action. A DORA is special kind of DODE that supports shop visitors in “designing” a solution (i.e. a set of items to buy) that matches their “specified” needs and goals, and is consistent with their buying context. Product recommendations here are special kind of “critique” provided by the critiquing component. Following this view, the main DODE components to be instantiated in a DORA are the Specification Component and the Construction Component. The Specification Component in the DORA architecture is called “Needs & Context Specification Component”; it lets visitors specify their high-level needs and the current buying context. The Construction Component in the DORA architecture is called “Solution Construction Component”; it lets visitors construct the solution to their current “problem”. The Critiquing component and the Catalog component are integrated in the “Product Evaluation Component”, which performs the needs-based product evaluation and recommendation. We have left out the Argumentation and Simulation components in our current DORA architecture, as they do not seem crucial for most e-commerce recommendation applications. The resulting DORA architecture is shown in Figure 2. It provides a three-layer conceptual
architecture in which the central components provide the business logic. Persistence is provided by a layer of databases, and the components in the User Interface (UI) layer plan the presentation of information and control the user interaction. UI
Specification UI (SUI)
Logic
Needs & Context Specification Component (NCSC)
Product Evaluation Component (PEC)
Persistence
Customer History & Inventory
MultiChannel Statistics
Product Data
Catalog, Recommendation & Solution Construction UI (CUI) Solution Construction Component (SCC)
Marketing Domain Scripts Knowledge
Fig. 2. DORA Conceptual Architecture
Users of a DORA will usually, in a first step, interact through the Specification UI with the Needs & Context Specification Component (NCSC) to provide, select, review, or update their relevant profile information. The NCSC has access to a customer history and inventory database that allows information, e.g. about past buys, long-term interests and tastes, demographic data, as well as skills and capabilities, to be retrieved (c.f. Kobsa et al., 2001, for a more complete discussion of profile data components). Once the user switches to the Catalog, Recommendation, and Solution Construction UI (CUI), the Product Evaluation Component (PEC) uses the information provided to evaluate products and present the best-matching products to the visitor. Presented products should indicate how well they match the visitor’s specified needs and buying context. For generating the recommendations and providing the evaluation information, the PEC has access to the product database, multi-channel sales and interaction statistics, a database with online selling “scripts”, and visitor target-group descriptions, as well as a knowledge base that supports the interpretation of the information in the other databases. By integrating statistical information for collaborative filtering and knowledge-based recommendation techniques, DORAs avoid some problems of purely collaborative filtering systems (Burke, 1999). Moreover, by using accumulated information about a visitor’s needs and buying context, DORAs can provide recommendations that are more exact and “intimate” than those of generic recommender systems.
3
Example: Garden-Design DORA
We will further illustrate the DORA concept by presenting a fictitious example of a DORA for a garden supply shop1. We believe that a DORA in this domain should provide visitors with a NCSC that lets them create the current (or desired) layout of their garden, together with an indication which plants they already possess. In addition to the garden layout, the user should also be able to provide information about his or her personal profile and preferences, such as the relative importance of making the garden easy to care for and preferred uses, such as playing soccer or having young children play in the garden. During the layout process, general recommendations about garden design as well as specific product recommendations are provided by the system. In this DORA the SUI and the CUI would be integrated, as product recommendations are provided during (and in the context of) the elaboration of the visitor’s needs specification. Thus, while the user is creating his or her garden layout, recommendations for matching plants and interesting design alternatives will be delivered by the system. The user can use this information to augment and adapt the design. The advantage of such a DORA would be that the supplier would gain intimate knowledge about the customers needs without getting into “personal matters”. Providing the layout of their garden is likely to be “accepted question” (c.f. Spiekermann & Parachiv, 2002) by visitors to a gardening site. Still, although this information might not be sensitive for the visitor, it is of high value for the supplier. For example, each new season the supplier could use this information to contact the visitor with customized recommendations and suggestions on how to best prepare the garden for the coming season. Furthermore, once customers have invested the time to draw their garden, they are likely to return to benefit from the effort invested. Also customers would benefit directly from such a system because they are provided with a garden-design tool that otherwise is only available to professional gardeners (e.g. GardenComposer, www.gardencomposer.com). Furthermore, they receive high-quality recommendations and tips, which they can follow or ignore if they prefer.
4 Analysis of Existing Systems The DORA architecture is not only meant to serve as a guiding framework for the design of recommender systems in new domains, but it can also serve as a tool for analyzing existing recommender application to identify potentially useful add-on functionality. Most recommender systems today do not support users in specifying their buying needs and the current context of their visit. Adding such functionality would be the first obvious suggestion when comparing these systems with the conceptual DORA 1
A system that goes in the direction of the vision proposed here is the “Own Garden Net” website (www.ognet.co.uk), where visitors can upload a map of their own garden, specify the plants in the various areas of the map, and receive weekly reminders about necessary gardening tasks.
architecture. However, the DORA conceptual architecture goes beyond other publications (Grenci & Todd, 2002) that suggest that recommender systems should be built in a needs-based way. It adds the concept of a buying context that visitors should be able to select and refine over time. The recommender application should let visitors make their product selections within this context, and the application should place and explain product recommendations within the context. The DORA architecture also enumerates potential data-sources to use for deducing and justifying recommendations. Furthermore, it stresses the importance of indicating to which degree each recommended product fulfills the visitor’s indicated needs. Finally, the architecture suggests that buying should not be seen as a simple selection task, but rather as a design task in which the items in the shopping cart provide a “solution” to the needs specified in that specific buying context. A system that provides some of the functionality called for by the DORA architecture is the system run by SmarterKids (www.smarterKids.com). This system allows buyers to maintain multiple profiles for the different children they frequently buy presents for. For each visit, buyers can define their buying goal and choose for which child they want to see recommendations (i.e. specify their buying context). Products are then evaluated against the learning goals that were defined for the particular child. When we compare the SmarterKids system with the DORA architecture, we see that, while needs and context specification is supported, other aspects of the DORA architecture are not realized. So, for example, the system does not explain why certain products are recommended and which needs (i.e. learning goals) they score high on. Also, there is no explicit record of previous presents to that child and also no analysis to which degree multiple items in the shopping cart would represent a more “roundedout” set of presents. Another system that offers some of the functionality called for by the DORA architecture is the JD Power car recommendation engine mentioned earlier. It allows users to provide a high-level specification of the car they are interested in by specifying the importance of desired properties such as performance, safety, and style. These inputs are then used to evaluate the cars in the database. The descriptions of individual cars indicate to which degree the desired benefits are provided. When comparing the system with the DORA architecture, it becomes clear that users should be able to store and manage multiple profiles, and that they should be enabled to “construct” their solution, which would mean that users are allowed to do a more detailed analysis, enabling them to “juggle” with car options. Furthermore, the needs orientation of the system could be strengthened by allowing visitors to describe their personal context and the kind of uses the car should support. A third example of a system that exemplifies some properties of a DORA is the recipe-based groceries recommender system (Svensson et al., 2001). Here again shoppers are supported in defining their deeper shopping needs (i.e. which recipe they want to cook), and the system provides them with product recommendations that match those needs. However, from a DORA perspective, we would suggest that the system should allow users to manage a set of “favorite” recipes as a persistent context, and that it would be useful to relate the choice of recipes to the more personal context, such as the size of the family, budget and time constraints.
5
Discussion and Future Work
We believe that the DORA architecture provides a promising conceptual framework for designing the next generation of “intimate recommender applications” that is able to respond to the needs and interest of a visitor of an online shop and allows online shops to build and maintain long-term, complex relationships with their customers. We have derived the conceptual architecture from a proven blueprint for designing design-support systems such that they profit from the accumulated experiences with these types of systems. The proposed architecture is different from other, more technical recommender architecture descriptions, which, for example, describe the different algorithms and data sources used by recommender applications (Schafer, et al., 2001), or explain the implementation details of a particular recommender application (e.g. Ardissono et al., 2001). We will explore the applicability of the design framework to two online shops (one selling food the other selling books) in the context of a seminar at the University of Bern, Switzerland, in this summer semester. At the time of the workshop we will be able to report first results from this work
References Ardissono, L., A. Goy, G. Petrone and M. Segnan (2001). “A software architecture for dynamically generated adaptive Web stores.” Proceedings IJCAI 2001: 1109-1114. (citeseer.nj.nec.com/454624.html). Balabanovic, M. and Y. Shoham (1997). Fab: Content-Based, Collaborative Recommendation. CACM 40(3): 66-72. Breese, J., D. Heckerman and D. Kadie (1998). Empirical Analysis of Predictive Algorithms for Collaborative Filtering. Proceedings of the Fourteenth Conference on Uncertainty in Artificial Intelligence: 43-52. Burke, R. D., K. J. Hammond and B. C. Young (1997). The FindMe Approach to Assisted Browsing. IEEE Expert/Intelligent Systems & Their Applications 12(4): 32-40. Burke, R. (1999). Integrating Knowledge-based and Collaborative-filtering Recommender Systems. Proceedings AAAI-99 Workshop AI for Electronic Commerce (AIEC99), Orlando, FL (http://www.cs.umbc.edu/aiec/): 69-72. Cunningham, P., R. Bergmann, S. Schmitt, R. Traphöner, S. Breen and B. Smyth (2001). WEBSELL: Intelligent Sales Assistants for the World Wide Web. Proceedings CBR in ECommerce, Vancouver BC: 104-109. Felix, D., C. Niederberger, P. Steiger and M. Stolze (2001). “Feature-oriented vs. Needsoriented Product Access for Non-Expert Online Shoppers.” Proceedings IFIP Conference I3E, Zurich, Switzerland: 399-406. Fink, J. and A. Kobsa (2000). A Review and Analysis of Commercial User Modeling Servers for Personalization on the World Wide Web. User Modeling and User-Adapted Interaction 10(3-4): 209-249. Fischer, G. (1994). Domain-Oriented Design Environments. Automatic Software Engineering: 177-203. Häubl, G. and V. Trifts (2000). Consumer Decision Making in Online Shopping Environments: The Effects of Interactive Decision Aids. Marketing Science 19(1): 4-21. Grenci, R. T. and P. A. Todd (2002). Solutions-Driven Marketing. CACM 45(3): 65-71.
Kobsa, A., J. Koenemann and W. Pohl (2001). Personalized Hypermedia Presentation Techniques for Improving Online Customer Relationships. The Knowledge Engineering Review 16(2): 111-155. (http://www.ics.uci.edu/~kobsa/papers/2001-KER-kobsa.pdf) ICONOCAST (1999) More Concentrated than the Leading Brand. ICONOCAST. http://www.iconocast.com/icono-archive/icono.102199.html Nguyen, H. and P. Haddawy (1998). The Decision-Theoretic Video Advisor. Proceedings of the AAAI Workshop on Recommender Systems, Madison, WI: 77-80. Peppers, D. and M. Rogers (1997). Enterprise One to One: Tools for Competing in the Interactive Age. New York, Currency Doubleday. Sarwar, B., G. Karypis, J. Konstan and J. Riedl (2001). Item-based Collaborative Filtering Recommendation Algorithms. WWW 10: 285-295. Schafer, J. B., J. A. Konstan and J. Riedl (2001). E-Commerce Recommendation Applications. Data Mining and Knowledge Discovery 5(1/2): 115-153. (http://www.cs.umn.edu/Research/GroupLens/ECRA.pdf) Shimazu, H. (2001). ExpertClerk: Navigating Shoppers Buying Process with the Combination of Asking and Proposing. IJCAI 2001: 1443-1450. Spiekermann, S. and C. Parachiv (2002). Motivating Human-Agent Interaction: Transferring Insights from Behavioral Marketing to Interface Design. J. Res. Electronic Commerce (forthcoming.) http://www.wiwi.hu-berlin.de/~sspiek/artikel/ECRJ_final_total.pdf Steiger, P., M. Stolze and M. Good (1998). Beyond Internet Business-as-Usual: Report about a CHI 98 Workshop. SIGCHI Bulletin 30(4): 48-52. (see also http://www.zurich.ibm.com/~mrs/chi98/report.html and follow-up WS at http://www.zurich.ibm.com/~mrs/chi2000/) Stolze, M. (1999). Comparative Study of Analytical Product Selection Support Mechanisms. Proceedings INTERACT 99, Edinburgh, UK. M. A. Sasse and C. Johnson, IOS Press: 4553. Stolze, M. and M. Ströbel (2001a). Utility-based Decision Tree Optimization: A Framework for Adaptive Interviewing. Eighth International Conference on User Modeling (UM2001), Sonthofen, Germany, Springer: 105-116 Stolze, M. and M. Ströbel (2001b). The Shopping Gate – Enabling Role- and PreferenceSpecific e-Commerce Shopping Experiences. Proceedings Web Intelligence (WI) 2001, Proceedings First Asia-Pacific Conference Web Intelligence “WI 2001,” N. Zhong, Y. Yao, Liu, S. Ohsuga, Eds.,LNAI 2198: 549-561, Springer, Berlin. Svensson, M., K. Höök, J. Laaksolahti and A. Waern (2001). Social Navigation of Food Recipes. Proceedings Social Factors in Computing Systems (CHI 2001): 341-348. Terveen, L. and W. Hill (2002). Human-Computer Collaboration in Recommender Systems. Human-Computer Interaction in the New Millennium. J. M. Carroll, Ed. ACM Press, New York: 487-509.
