The application of process mining techniques for analyzing customer journeys seems promising for di erent stakeholders in the tourism domain, i.e., the tourism providers are enabled to, e.g., nd nice o ers or partner services and the guests can improve their holiday experience. One precondition for mining processes (high quality) logs. This paper reports on experiences in implementing a data warehouse component for storing process logs in the tourism information system oHA. It shows which analysis questions can be answered by applying process mining and analysis on the logs. Finally, lessons learned are discussed.
This business case shows how we designed a sustainable and scaleable data warehouse architecture as well a log concept for the tourism-information system "oHA" (online Holiday Assistant)1, which provides information and digital services for tourists. In more detail, oHA is a digital e-service, accessible for the tourist in form of a web app, mostly in a public WiFi, which is designed for tourism agencies and hotels to make more revenue with guests and provide a better service level to their guests. Fig. 1 shows three examples how the web app oHA looks like for a tourist guest. In the following we explain some technical details about oHA and go through the three displayed screenshots. This is important for understanding our application terminology and thus for understanding our log concept, later in this work.
The rst screenshot shows the main menu of oHA with possible menu items to be selected by a guest. Every menu item corresponds to at least one digital service in oHA. There are lots of services in oHA and to name some of them, a ? \M. Brambilla, T. Hildebrandt (Eds.): BPM 2017 Industrial Track Proceedings, CEUR-WS.org, 2017. Copyright 2017 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors." 1 https://www.luxactive.com/ service can be a hotel information (second screenshot), a activity search (third screenshot), a daily post, a regional news, the weather, or a GPS navigation. For instance on the rst screenshot, by selecting Hotel Info, the second screenshot and by selecting Activities, the third screenshot shows up. Each of the displayed screenshots shows a di erent view in the application which has technically a place name for the current displayed view and we name the statistics behind that, place usage. The rst screenshot shows, e.g., the place name HomePlace and the third SerachActivityPlace. On the third screenshot, a semantic search function for touristic activities is provided. The tourist can search for location based and time related activities like events near by, POIs (points of interest) or tours to navigate with oHA. We record the user entered search terms and try to generate processes out of the users search behavior (search process ) with our stored data which will be covered in more detail later.
Analyzing the guest behavior is an opportunity to distinct oHA from competitive tourism information systems. For this reason the CustPro2 project was initiated between the company LuxActive and the University of Vienna. Some of our presented concepts and techniques are already blueprinted and developed and others are still in development. With this work, we will show how we solved the main challenges when starting to implement process mining in a tourist information system. As rst step, we designed a data warehouse for storing and preparing logs, to discover further research elds like process mining, aiming to analyze the customer journey process through the tourism platform oHA. Fig. 2 shows the di erent stages of a customer journey in the tourism domain and how it could be interoperated with process mining. 2 http://cs.univie.ac.at/project/custpro
The rst stage Interest / Booking bears the challenge to gure out preferences of the guests for booking a stay. The next stage Arrival is for providing all relevant information for the stay which is relevant for the individual guest. In stage Activity it is important to provide suggestions for individual activities and an easy way for consuming and booking them. In the stages Departure and Stay in relation it is important to get feedback about the stay and to encourage the guest and his surrounding people for booking again. For the latter, individual content marketing can can be one method for achieving recurring bookings. Today oHA focuses strongly on the stages Activity and Departure but in future we want to cover all stages of the customer journey with oHA. As described before, every stage has di erent characteristics which require research and implementation. Also recorded logs from the di erent stages may in uence each other. For example, recorded logs from the stage Activity may have in uence to the stage Interest / Booking by serving the right information for promotion, out of historical data from guests.
The rst step is to answer the following business process related questions based on the stages Activity and Departure for customers of oHA as the information can be useful for tourism companies when searching for niches, business partners, or increasing their revenue by providing new activities for tourists.
Which digital services are used by guests mostly?
Which searched activities like tours, events or POIs are most interesting for guests at the stay and after stay?
What is a typical search process of a guest (cf. Fig. 3) and how to display it? When are the guests searching for services and activities and what are their peak periods? Which services and activities are missed by the guests? Which services and activities are mostly liked by the guests?
Who will be a best tting strategic partner for providing services and activities, e.g., a tour guide?
The problem is that the original log implementation in oHA had no cases
to answer questions on di erent levels and views. Hence it was not possible to
mine processes from the level of individuals, because we could not distinguish
between di erent guest devices. Furthermore, all logs were distributed in les on
di erent local le systems. Thus, log preparations and modi cation tasks were
time consuming and the logs were hard to access due to security restrictions on
di erent servers. Also state changes in our system, which might in uence the
user behavior, were not recorded and thus taken into account by the logs. Such
changes could be for instance hidden or shown menu items in the main menu or
new data sources for oHA. Lastly, we had no high-quality maturity level of our
logs, which is recommended for instance by the process mining manifesto [
A literature review suggested process mining [
This section presents design decisions and methods used for enabling process mining and analysis in oHA.
The previous situation in oHA was, that all logs including the user behavior were distributed over di erent le systems and in di erent le formats. So there was no possibility for tracking the user behavior of the tourists in an e cient way, without time-consuming manual interventions in logs on di erent le systems. Such interventions include manually gathering the logs, modifying them by removing outliners or test data, and converting them into a format which can be used for statistical calculations or process mining. This was overcome by implementing a central hub for our logs, which acts as data warehouse in our application landscape. An overview of our data warehouse architecture with its main work ow is depicted in Fig. 4.
We opted for an extra physical server environment with its own web server
for managing and handling the logs in the data warehouse due to several reasons.
Processing logs can be resource consuming and our production systems should
not be impacted with performance issues because of resources like memory
running out. A data warehouse database is designed to answer complex queries
rather than performing a high throughput for updating transactions [
Regarding the presence of (high quality) logs, in oHA some important data was missing, i.e., di erent cases from a session level to a region, the users language, additional timestamps, and search results of activities from tourists. Thus as shown in Fig. 4 for data transformation and data enrichment processes, the raw log data is processed by separate web servers or micro services. This is also an advantage for a loosely coupled architecture as implemented with our data warehouse web server, which is responsible for the whole data management and communicates via API calls. New web servers or micro services are easy to integrate now into the data warehouse. For instance we currently implement a web service, which uses semantic technologies for handling synonyms and di erent languages of logged search terms and converts them into a normalized form for improving the quality to further carried out process mining. The processed data is stored back in an extra database table in the data warehouse.
The oHA data warehouse database consists of the tables shown in Fig. 5. Because we use an iterative development approach which is still ongoing, not all following presented details are implemented now.
Fig. 5: Relational database tables from data warehouse.
Every table which contains logs has stored cases for region (case region), a
customer (case hotel ) and a device (case device). For the latter, we implemented
a client based solution to store a unique id in the local storage of the clients
device which is mostly owned by a tourism guest. This id represents the case for
the device and can be also used to identify a session. A session can be calculated
together with timestamps of executed actions from the client. E.g, if there is
no action with the same device for more than 10 minutes, we can infer a
session. Identi ed sessions can be very useful for process mining. [
Every client related log table also contains a language eld which seems important for performing further analysis tasks. The data warehouse also includes a universal log table client actions, which should log every action from the client in future implementations. It contains three relevant elements. The rst is an action type action, which could be a selected button or focused text eld. The second is the content of the action item, which contains, e.g., the title of a selected activity or an entered text. Finally, the third element contains a unique view name, like the place usage, form the client place for identifying where the action has taken place. 4
With the enriched log concept and the central data storage, most popular search activities and services by tourists in oHA, on di erent locations and in di erent regions can now be determined. Moreover, analysis questions can be answered from di erent views due to the di erent implemented cases, i.e., regions, tourism companies (where every company has its own oHA instance), guest devices, and guest sessions. Fig. 6 shows, how mined processes for used digital services in oHA on di erent cases can look like. The rst process shows the user behavior of a single user session, the second process shows the same user along the period of one month and the third process shows, how all users in a hotel used the system in an one month period.
We can also show which digital services are interesting for the guests on di erent cases (cf. Fig. 7). The rst chart shows statistics from one device, the second shows the same type of statistics from the case of a hotel and the third one from the case of a region. In the rst pie chart, the user was most interested in searching for activities. Looking for hotel news was less important. Indirect assumptions about missing services can be derived as well.
In the following, Fig. 8 (left) shows an example for a mined search process of a device which identi es a single guests behavior. One path of the process shows, that the user rst searched for a tour and then for di erent variation of sights. We can also identify peak hours of a day, where guests are demanding di erent services in our system. This can be a useful information for coordination tasks in service for tourism companies. Fig. 8 (right) shows such an example how peak hours can look like on a hotel, after investigating logs for one month in the data warehouse. At noon, there was most demand of the service oHA and thus guests were looking for information. 5
This work reported on the implementation of a data warehouse in a tourist information system. The primary goal was to improve the quality of logs for analysis tasks such as process mining and to nally understand the customer journey for tourism companies. This can help them in developing attractions, marketing activities, and nally nding their niches.
For storing logs, we would always prefer a relational database over a le system. It is much easier to deal with outliers or excluding test data on productive instances. Log modi cations become easier and less time consuming as well. Also, transferring the logs from the data storage into a process mining tool (a) Search Process (b) Peak Periods can be done faster now. The database in oHA is realized by a service running on a (web-)server, which is responsible for managing the data and receiving the logs from di erent systems. Doing so we have achieved a loose coupling between di erent systems and instances, which are reporting to a central data warehouse. The decision to separate the data warehouse server physically from the log generating applications bears advantages with respect to security, because there is only one server to protect. This is particularly challenging with respect to data from user applications where di erent regulations for di erent countries exist. Another recommendation is to create a scaleable architecture to be prepared for answering further questions and to integrate new systems. It was also useful to design non-time-critical micro services in the data warehouse for enriching and processing the stored log data, e.g., for mining and visualizing search processes. Finally, automating the log processing task reduces the failure rate with respect to conclusions on the guest behavior. Apart from technical aspects we recommend to identify relevant cases and to de ne analysis questions before starting to mine processes. The more cases are identi ed, the more expressive the questions can be as most questions can be asked from di erent viewpoints, e.g., for a region, a hotel, a device, or a user session.
One future goal in CustPro refers to improving the quality of the mined models based on semantic technologies in terms of, e.g., complexity. We also want to study the transferability to other industries.