A Recommender System for Mobility-as-a-Service Plans Selection

Abstract

Transportation and mobility in smart cities are undergoing a grave transformation as new ways of mobility are introduced to facilitate seamless traveling, addressing travelers’ needs in a personalized manner. A novel concept that has been recently introduced is Mobility-as-a-Service (MaaS), where mobility services are bundled in MaaS Plans and offered to end-users through a single digital platform. The present paper introduces a recommender system for MaaS Plans selection that supports travelers to select bundles of mobility services that fit their everyday transportation needs. The recommender filters out unsuitable plans and then ranks the remaining ones on the basis of their similarity to the users’ characteristics, habits and preferences. The recommendation approach is based on Constraint Satisfaction Problem (CSP) formalisms combined with cosine similarity techniques. The proposed method was evaluated in experimental settings and was further embedded in real-life pilot MaaS applications. The experimental results showed that the proposed approach provides lists of MaaS PlanMaaS Plans that users would choose in a real-life MaaS setting, in most of the cases. Moreover, the results of the real-life pilots showed that the majority of the participants chose an actual MaaS Plan from the top three places of the recommendation lists.

1. Introduction

Mobility-as-a-Service (MaaS) is a novel concept for smart mobility ecosystems that aims to integrate the various transport services available within a city/area, accessible on demand and through one single digital platform, according to Datson [1] and Moura [2]. A fundamental objective of MaaS is to serve the transportation needs of people by providing personalized mobility solutions in tailored bundles adjusted to user’s requirements, as per Kamargianni et al. [3]. Recent investigations by Sochor et al. [4] and Robinson [5] show that MaaS can offer “something to everyone”, highlighting its social inclusion character. From this perspective, it is commonly believed that MaaS will enhance the traveling experience, diminish travelers’ expenditure and effectively coordinate travel demand, albeit refining the environmental and social impact of mobility in accordance with Durand [6]. As reported by Arias-Molinares & García-Palomares [7], there is an increasing number of MaaS concentrated scientific articles released through years, yet there are principal queries to be resolved, in the path of implementing its visions and sustainable character.

MaaS has emerged as a result of profound transformations and disruptions in smart cities’ transport systems driven by mobility and technological innovations. Transport options, which until recently commonly relied on public means (bus, metro, rail) and the private car, are now being expanded with the emergence of new mobility solutions that are characterized by greater flexibility and take advantage of sharing economy concepts (e.g., bicycles, electric scooters, car sharing, etc.), of which travelers aspire to be a part of, by exploiting the advantages of sharing their mobility assets [2]. As Sakai [8] distinctly claims, MaaS can be reflected as all the modes of transport other than private automobiles. Such solutions lead to optimized use of resources and contribute to sustainability targets with lower greenhouse gas (GHG) emissions, in line with Eliot et al. [9] and Cruz and Sarmento [10], and energy consumption, following Becker et al. [11], while allowing travelers to reach their destination with different options or by even combining different options in what is commonly termed multimodal mobility. In terms of technological advancements, the advent of intelligent and integrated transport systems as well as the ubiquitous use of smartphones and related transport applications provide the means to address the inherent complexities of modes’ integration and related challenges with respect to seamless payment, booking and journey planning, as well as sharing of revenue between the distinct modes and operators, while the competitiveness among the various engaged operators may contribute to upgraded services [2]. Besides, Kamargianni et al. [12] argue that higher mobility integration is preferable by the travelers, whereas user-friendly MaaS apps could increase users’ aspiration to get involved with this innovative scheme.

MaaS is provided by MaaS Operators, i.e., transport companies that are engaged with the duty of mediating and entering into agreements with public and private mobility operators on a city, intercity or national level in order to provide bundled transport services, referred as “MaaS Plans” or packages or mobility products [6]. The MaaS Operator incorporates the various mobility service providers’ offerings, creates the MaaS products and merchandises them to end-users based on Kamargianni et al. [13]. MaaS operators deploy specially designed mobility apps and relevant back-end platforms that offer to travelers a single point for MaaS Plans selection, route planning, booking and payment, while recent work of Esztergár-Kiss et al. [14] conveys the continuous growth of the MaaS market in multiple layers from new geographical deployment areas to new business models.

In a MaaS context, there can be a variety of MaaS PlanMaaS Plans with diverse transport services levels, which are designed to address the needs of dissimilar categories of travelers within a specific area (e.g., a MaaS PlanMaaS Plan may consist of a monthly public transport pass, a number of taxi and bike sharing rides). Essentially, MaaS PlanMaaS Plans are mixtures of the transport services offered by mobility operators of a city/area and its distinct characteristics with whom MaaS operators have engaged into agreements based on Esztergár-Kiss and Kerényi [15]. Instances of relevant transport services aggregated within MaaS PlanMaaS Plans may be public transport, taxi, car sharing, bike sharing, car rental, ride-hailing, e-scooters and/or other related services such as parking or e-vehicle charging stations. It is evident that the set of MaaS Plans for a particular city constitutes a selection space that grows depending on the available transport services, the combinations of which can produce large choice assortments with compound configurations, a setting that is often present in numerous e-commerce cases and is tackled by the theory of recommender systems (RS) that copes well with such information excess challenges as said by Ricci et al. [16].

The first step that travelers need to follow when enrolling in MaaS is to identify and buy a MaaS PlanMaaS Plan that fits their transport needs and desires effectively and adequately. However, travelers are commonly accustomed to using single transport services, and in the newly introduced concept of MaaS that delivers bundled mobility services, the cognitive assignment of identifying the proper MaaS PlanMaaS Plan can be cumbersome, may not be easily handled and can hinder the widespread adoption of MaaS. As Felfernig et al. [17] observe, the task of addressing the best-matching products is a compound decision-making process due to the users’ limited awareness of the domain and calculation efficiency. Under this prism, tools and mechanisms are needed that facilitate end-users to select MaaS PlanMaaS Plans by identifying and recommending those that are relevant to users’ specific characteristics, habits and preferences.

In this paper, we present a hybrid knowledge-based recommender system that supports MaaS users to identify plans suitable for their needs and preferences. The system relies on Constraint Satisfaction Programming (CSP) theory to filter the initial search space of available MaaS Plans into a subset that matches a specific user’s profile and is coupled with a similarity calculation mechanism that considers users’ mobility habits and the filtered MaaS PlanMaaS Plans in order to deliver a ranked list of MaaS PlanMaaS Plans in which the plans that are more similar to the user are placed in top positions. The proposed approach was tested and compared against different variations and recommendation strategies in a controlled experiment in which 262 users participated in a within-subjects study design: they were presented with two lists of MaaS PlanMaaS Plans, each one generated by a different variation, and were asked to evaluate them. Moreover, the approach was implemented as part of a recommender system service that was integrated in a fully fledged MaaS app as part of the MaaS4EU research project (http://www.maas4eu.eu/ accessed on 21 July 2021). The MaaS4EU app provided the means to evaluate the proposed approach in real-life situations where users from the pilot cities of Budapest (Hungary), Luxemburg and Greater Manchester (UK) selected, bought and used MaaS PlanMaaS Plans for their everyday transportation needs. The results indicate that the MaaS PlanMaaS Plans recommendation lists generated by the proposed approach are preferred compared to other recommendation mechanisms as well as that the proposed system is able to suggest MaaS PlanMaaS Plans that fit user preferences and needs, as the plans users selected in the real-life applications were within the top three positions in the majority of the cases.

The remainder of the paper proceeds as follows: Section 2 presents an overview of the related work, while Section 3 provides a detailed description of the proposed recommender system. Section 4 focuses on the design, deployment and results of the controlled experiment, and Section 5 demonstrates the real-life evaluation that was performed in the context of the MaaS4EU pilots. The paper concludes in Section 6 with a discussion of our results, future research directions and final remarks.

2. Related Work

Recommender systems (RS) filter out information and suggest items of interest to users based on their preferences. In many instances, it is required to make choices with insufficient personal knowledge of the available selections as specified by Resnick, P., and Varian [18]. In the present era of information overload, Ricci et al. [16], state that recommendation technologies are being used in many application domains including news, music, e-commerce, movies, etc. A recommendation system relies on methods that model user preferences, which can be captured either explicitly or implicitly, and item characteristics. Recommendation algorithms process the available user and item information and try to identify possible connections between items and users in order to suggest the most relevant items, maximizing the value of the matching between a specific item and a specific user, according to Lops et al. [19]. In addition, Konstan and Riedl [20] convey that a strong point of RS is that they moderate the working load of users, who are deluged by the potential number of alternatives. By approaching the problem of introducing users to the novel domain of MaaS with the goal of recommending them a MaaS package that corresponds to their needs, the RS theory and its successful applications among other domains appears to be a rather ideal solution.

According to Aggarwal [21], the underlying idea of RS is that certain dependencies occur between user- and item-centric actions. In RS theory, there is a long catalog of various learning models used to complete the task of inferring users’ interests around the available items/products. Indicatively, the “collaborative filtering” class concerns the use of ratings collected by several users in a collaborative form to predict absent ratings. “Content-based” RS are grounded on the principle that user interests can be modeled by means of properties of the items they have either rated or accessed in the past. An alternative family of RS is that of “knowledge-based” systems, where users define interactively their interests, and the user requirements are mixed with domain knowledge to deliver recommendations. There are yet advanced models, where contextual information such as temporal data, external know-how, location, social or network information may be utilized to provide recommendations. Data-driven collaborative filtering and content-based RS require past ratings or contextual data that, in the present novel domain of MaaS, are not available; thus, our work focuses on knowledge-based recommenders, including RS for bundles of product or service concepts detailed in the following.

In the initial setup and deployment of a RS, an important issue arises in the absence of past historical data and user input, the so-called cold-start problem. As Felfernig et al. [22] indicate, a type of RS that efficiently addresses this kind of challenge by exploiting explicitly stated user preferences and knowledge of the under-investigation field is the knowledge-based recommender systems. Related approaches explicitly ask users to provide their preferences and needs, which are recorded in a user profile, while knowledge engineers codify the domain experts’ knowledge into a proper and runnable representation; thus, the system generates suggestions based on this information. Our work relies on constraint-based approaches that are grounded on the constraint programming theory. Constraint-based recommenders principally utilize predetermined recommender knowledge bases that incorporate explicit rules about the way that users’ needs are related with item properties. More specifically, a Constraint Satisfaction Problem (CSP) is considered as a task that entails detecting a value for each variable included in a predefined set of variables, where constraints indicate that some subsets of values cannot be used in tandem, according to Freuder and Mackworth [23].

Constraint-based mechanisms have been extensively utilized within recommender systems in a range of business fields. A domain-independent knowledge-based recommender system, presented by Felfernig et al. [24] and named CWAdvisor, assists in the process of product selection through a personalized conversation with successful applications in financial services and the electric goods market. Another system is described by Jannach et al. [25] under the name of “VIBE”, which essentially represents a virtual advisor supporting tourists in their decisions. “VIBE” grounds its implementation on a knowledge-based conversational recommender that delivers personalized plans offered by a spa resort and are adjusted with their potential customers’ preferences. The work demonstrated by Reiterer et al. [26] describes a constraint-based recommender that supports households in selecting the optimal waste disposal strategy. Equivalently, Murphy et al. [27] propose an energy-saving recommender system, which makes use of real-world energy consumption data of appliances and delivers behavioral change suggestions along with an optimal appliance schedule recommendation, with the goal for the users to achieve their energy saving goals. Furthermore, Zanker et al. [28] use constraint-based modeling to approach the complex task of composing product bundles, in particular, travel bundles that collaborate accommodation with activity choices through a generic purpose platform called web configurator. The configurator integrates recommendation mechanisms with CSP principles and delivers a set of personalized product bundles, adjusted to tourists’ requirements while following the e-tourism field constraints, through a hybrid approach that merges collaborative filtering with knowledge-based techniques.

Producing recommendations and personalized assortments of bundles for products or services is a research question that has been studied in domains such as tourism, telecommunications and e-commerce. A review of the frequently used types of RS that solve the problem of real-time touristic services’ (e.g., activities, places to stay) configuration by dynamic packaging is presented by Schumacher and Rey [29], where they present as most useful RS, the association rules, the conversational and preference-based RS. The work of Beheshtian-Ardakani et al. [30] focus on the challenge of suggesting product bundles for e-commerce platforms from a marketing point of view and propose a new model that uses market segmentation variables along with customer loyalty analysis. In particular, the product bundles are specified for each market segment by clustering algorithms and association rules, while further for the recommending task, classification models are utilized. Zhang et al. [31] propose a hybrid recommender system, applied in the telecom domain, that incorporates user and item collaborative filtering techniques with a set of fuzzy methods and knowledge-based rules, tackling the problem of vast assortments of services/products that are available and customers are requested to choose from. More recently, Kouki et al. [32] suggest the use of product hierarchies with transactional or domain knowledge data, leading to possible compilations of product assortments. For the recommendations’ generation, a deep similarity model that exploits the textual embedding is constructed using Long Short-Term Memory (LSTM) networks and is further evaluated for a big online retailer. In addition, Dragone et al. [33] suggest a machine learning recommender system applicable in the telecommunication and multimedia domains that exploits the constructive preference elicitation framework with coactive learning, called Smart Plan. Bai et al. [34] approach the personalized bundle list recommendation challenge as a structured prediction problem introducing the bundle generation network by utilizing encoder–decoder architecture with a range of techniques that ensures the good quality and heterogeneous bundle list with a proper package size.

Tackling the MaaS Plans selection problem, given its significant drawback of past data absence of both users and MaaS packages motivated us in applying recommendation technologies for providing a personalized plans selection process experience in MaaS settings, guiding the travelers through this novel framework of MaaS and eventually recommending MaaS Plans to them. A main contribution of our work is the configuration and application of the selected RS methods to the problem of personalizing the MaaS Plans selection process, as described in Section 3. We have defined a novel approach toward capturing user preferences, subsequently eliminating the search space from the plans that are not in line with the stated preferences of the user and eventually deriving the similarity among the remaining plans and the user’s shaped profile. To our knowledge, the pertinent problem of personalizing the MaaS Plans selection process has not been addressed in prior literature, albeit RS approaches could certainly be proved as a useful tool in solving it.

This work builds on top of our approach previously described in [35], where we introduced the use of constraint models for MaaS Plans recommendations and set the ground for tackling the MaaS Plans selection problem. In this work, we have introduced improvements in the constraint models and the employed similarity metric mechanism, including a data-driven mechanism aiming to exploit past users’ data; we have implemented and integrated the approach in a real MaaS application; we have evaluated the approach in both experimental and real settings; and we have analyzed the results of the evaluation, which provide useful insights for both research and practice.

3. Approach

Figure 1 depicts the place of the proposed MaaS Plans Recommender in a MaaS framework. The recommender has been developed to become a useful tool for MaaS end-users that will be benefited by identifying bundled mobility solutions, in accordance with their individual habits and needs, delivered by the system. The system offers the required operations toward capturing user preferences, subsequently eliminating the search space from the plans that are not in line with the stated preferences of the user and eventually deriving the similarity among the remaining plans and the user’s shaped profile. The final result is a filtered and ranked list of MaaS Plans from which the user is able to choose the plan that better conforms with her/his needs.

More details of the proposed MaaS Plans Recommender are shown in Figure 2. The recommender operates on a set of MaaS Plans which contain varying mode levels depending on the available transport modes and agreements of the MaaS operator with the individual service providers. The MaaS Plans are, in general, received by transport engineers in Excel/CSV format and are further processed by transformation scripts in order to be transformed into JSON format and subsequently be used by the recommender system. It should be noted that the various levels of the transport modes included within the MaaS Plans are provided by the MaaS Operator. The MaaS Plans Recommender utilizes constraint-based filtering that leverages a prespecified knowledge base, including explicit rules (constraints) regarding how to relate user characteristics and habits to the existing MaaS product attributes (cf. Figure 2 “CSP-based filtering”). Moreover, a similarity function infers the proximity between the user and the filtered MaaS Plans list in order to generate a ranked list of MaaS Plans to be recommended to end-users (cf. Figure 2 “Similarity-based Plan Ranking”). The similarity mechanism receives direct user feedback in terms of stated users’ transportation habits and willingness to include different mobility services in their MaaS Plan and, additionally, past data (i.e., past subscriptions) when available. With respect to past data, these can be captured for users who have already subscribed to at least one MaaS Plan and have made use of it; thus, the system exploits this information with the goal to further enhance the results it delivers.

3.1. CSP-Based Filtering

Under the CSP basis, two discrete phases of the problem-solving process are specified: (i) the problem is modeled as a set of product and customer variables, and (ii) a set of constraints are determined and applied on these variables and should be satisfied in order to derive a solution. When the defined constraints are applied, products that do not satisfy these constraints are filtered out. The definition of the Constraint Satisfaction Problem (CSP) as well as its solution are described below:

Definition (Constraint Satisfaction Problem—CSP)—A Constraint Satisfaction Problem (CSP) can be defined by a triple (Vc, Vprod, C), where Vc describes customer properties or requirements, Vprod describe the properties of a given product assortment PROD, and C represents a set of constraints that can include customer constraints restricting the possible instantiations of customer properties; product constraints defining restrictions on the possible instantiations of product variables; and filter conditions defining restrictions on the possible combinations of customer properties and product properties.

Definition (CSP Solution)—A solution for a given CSP = (Vc, Vprod, C) is represented by a complete assignment to the variables of (Vc, Vprod) such that it is consistent with the constraints in C and results in a set S of prod_i ∈ PROD.

The CSP approach could potentially cater to an arbitrary number of product and customer properties as well as constraints. In this work, the customer properties refer to user transportation habits, which are explicitly provided by the user through a MaaS app for the modes included within the available MaaS Plans as provided by the MaaS Operator. For each available mode, users state how often they use it in a four-level scale: (i) Never, (ii) Once/few times per month, (iii) Once/few times per week, (iv) Every day. Moreover, we consider the availability of a driving license as an extra property, which affects modes related to the use of a car such as car sharing and car rental. In terms of product properties, these include the mode levels in the MaaS Plans and related mode types (e.g., car sharing, public transport etc.).

The constraints are divided in two separate groups: the hard and the soft constraints. Hard constraints filter out MaaS Plans that contain specific modes or MaaS Plans that do not contain a specific mode, whereas soft constraints filter out MaaS Plans that contain specific mode levels.

The two principal classes of hard constraints (HC₁…_n) are as follows:

• HC₁, “If user model.driving license = ‘No’, CarSharing = 0”, meaning that, in case a user does not possess any driving license, MaaS Plans including car sharing are filtered out.
• HC₂, “If user model.mode_i_usage = ‘Every Day’, Mode_i ! = 0”, indicating that frequent users of a specific mode will be delivered MaaS Plans that definitely include this mode and exclude the ones that do not include it, with the assumption that mode_i_usage represents a specific mobility mode usage from all the available included modes examined (indicative array (public transport, taxi, car sharing, bike sharing)), while, similarly, Mode_i takes its values from the same array of available services.

Soft constraints are defined for all mobility modes involved in MaaS Plans and are specifically modified as per each city’s provided modal allowances. Soft constraints are executed on the results delivered by the hard constraints and exclude MaaS Plans that contain mode levels that do not make sense for a specific user, e.g., when users indicate they make use of a particular mode of transport “Once/few times per month” (e.g., public transport), MaaS Plans that include maximum levels of that mode are excluded (e.g., for public transport, the maximum level stands for a 30-day public transport pass). Two indicative classes of soft constraints (SC_1…n) for monthly MaaS Plans are shown below:

• SC₁, “If user model.mode_i_usage = ‘Once/few times per month’, Mode_i ! = max values”, conveying that, for users occasionally using a specific transport mode, MaaS Plans that have the maximum level of this particular transport mode are excluded.
• SC₂, “If user model.mode_i_usage = ‘Once/few times per week’, Mode_i ! = 0 and Mode_i ! = min values”, denoting that users who are quite frequently using a specific transport mode, MaaS Plans that do not include that mode or have the minimum level of that mode are excluded.

We opted for maintaining two categories of constraints (hard and soft) for improved conceptualization, maintainability and testing. The formulation of the two constraint models is shown in Figure 3.

3.2. Similarity-Based Plan Ranking

The similarity-based Plan Ranking formula runs in the second step of the approach, processing the outcome of the CSP-based filtering. The goal is to order the MaaS Plans in regard to the user’s profile, as this is shaped by the feedback s/he provides to the system. The formula considers the user’s stated mobility habits with regard to the usage frequency of the transport modes that are part of the MaaS Plans as well as the user’s stated willingness toward including the proposed modes within his/her MaaS Plan. Users’ habits and willingness to include a specific mobility mode in a MaaS Plan are acquired through relevant questionnaires in the MaaS app (see Section 4.3). In more detail, two user vectors are considered: User-Habits and User-Willingness. A similarity value is then calculated between each one of the two aforementioned vectors and the filtered MaaS Plans.

The User-Habits vector represents users’ transportation habits in the n-dimensional feature space, where n refers to the available transport modes. For instance, in a city were the modes considered are public transport (PT), taxi (TX), bike sharing (BS) and car sharing (CS), n equals to four as follows:

$$\overrightarrow{UH}=\left[Habits for PT, Habits for TX, Habits for BS, Habits for CS\right]$$

(1)

In order to derive the values of the User-Habits vector, first, users are asked to state how often they use each mobility mode included within the examined MaaS Plans: (i) Never, (ii) Once/few times per month, (iii) Once/few times per week, (iv) Every day. In the MaaS Plans, there can be modes that commonly include an access pass with a specific duration (e.g., a daily or monthly pass for public transport or a daily or monthly pass for bike sharing) and modes that include distance-based quota (e.g., a predefined amount for taxi or car sharing use). For the latter modes, users are asked to provide an estimate of their average use in the form of average distance traveled per ride, e.g., average distance of taxi or car sharing rides. With the abovementioned information, the User-Habits vector is calculated based on the following formula:

$$U{H}_{mod{e}_i}=\frac{\left(frequencyFactor\ast average\_mode\_usage\right)}{max\_mode\_usage\_frequency}$$

(2)

The frequencyFactor maps the frequency levels of the question asking users to state how often they use each mode to specific values, which can be defined with the support of transport engineers in order to represent the travel patterns of a specific area. The average_mode_usage is set to value one (1) for modes with access passes. For other modes, the user answer that indicates the average travel distance per ride with the specific mode is used. The max_mode_usage_frequency is a normalization factor calculated by multiplying the max frequencyFactor and max average_mode_usage.

By way of illustration, the frequencyFactor for a taxi service is set to {Never: 0; Once/few times per month: 3; Once/few times per week: 7; Every day: 22}, and the options for the average trip distance are set to 2 km, 3 km, 4 km, 5 km, 6 km. For a user that does not use taxi and selects “Never” when asked how often s/he uses taxi, the corresponding feature value of the User-Habits vector will be 0; for a user that uses taxi a few times per week for an average distance of 3km per ride, the corresponding feature value of the User-Habits vector will be 0.15.

In the same way, the User-Willingness vector is populated by the user’s willingness to embody the various transport modes within a MaaS Plan. In particular, this vector is formed by the user’s responses to the five-point Likert scale question, “Please define your willingness to include the following modes of transport in your new MaaS Plan”, for the list of all the included transport services. The user’s answers to the aforementioned question are normalized, and the User-Willingness vector is shaped as follows:

$$\overrightarrow{UW }=\left[Willingness for PT, Willingness for TX, Willingness for BS, Willingness for CS\right]$$

(3)

Next, the vectors of the filtered MaaS Plans are constructed based on the mode levels that each plan contains, as follows:

$$\overrightarrow{MP }=\left[Level for PT, Level for TX, Level for BS, Level for CS\right]$$

(4)

Two cosine similarity coefficients are calculated between the two user vectors described above and the MaaS Plans vectors:

$$similarit{y}_{UserHabits-Plan}=\frac{\overrightarrow{UH}·\overrightarrow{MP}}{\Vert UH\Vert \Vert MP\Vert }$$

(5)

$$similarit{y}_{UserWillingnes-Plan}=\frac{\overrightarrow{UW}·\overrightarrow{MP}}{\Vert UW\Vert \Vert MP\Vert }$$

(6)

In the final step, an aggregated similarity value is computed for each user and MaaS Plan, derived by the two aforementioned similarity coefficients. The list of ranked MaaS Plans constituting the result of the similarity mechanism is formed by sorting the MaaS Plans in descending order with respect to the aggregated similarity value. MaaS Plans presented at the top positions of the list are closer to the user’s habits and willingness. The aggregated similarity formula is given below:

$$similarityAggregated=\sqrt{similarit{y}_{UserHabits-Plan}{}^{2 }+similarit{y}_{UserWillingness-Plan}{}^{2 }}$$

3.3. Data-Driven Preferences Elicitation

Previous user selections regarding the subscribed MaaS Plans throughout his/her engagement with the MaaS app can be considered a valuable source of information that can be exploited and provide reasonable conclusions about the user’s willingness to include the various mobility modes in a potential MaaS Plan they will choose within a next session. With this assumption in mind, a data-driven mechanism was designed to derive users’ willingness to include specific transport modes. The mechanism is applied to already registered users in the MaaS app and, in particular, those who have already selected and used a MaaS subscription. For such users, the recommender system infers the user’s willingness as the weighted average of the user-stated willingness and a system-deduced willingness from previous MaaS Plans subscriptions.

In more details, the system’s inferred user willingness is calculated by considering the MaaS Plans the user has selected in the past, in particular, the transport modes and their related levels included within them. In the event of absence of a particular transport mode within the selected MaaS Plan, the system considers it as a sign of unwillingness to include that mode in future selections. On the contrary, the presence of a transport mode in maximum level is handled by the system as a high user willingness indication to also include it in a future session. The two aforementioned cases represent the two extremes, between which the rest of the intermediate mode levels of a transport mode are considered proportionally for the inclusion of that particular mode. A linear mapping between transport mode levels and willingness has been considered. It should be underlined that higher weights are allocated to latest plan subscription instances or user-stated willingness provisions, i.e., the approach contains a “forgetting factor” that assigns exponentially lower weights to older data (Sugiyama et al. [36]).

Consequently, the recommender constructs a willingness W vector considering a system-inferred willingness W^system that indicates a specific user’s willingness for all included modes, calculated by utilizing the user’s past MaaS Plans subscriptions from n months ago and an explicitly stated user willingness W^user.

W^user is essentially the vector composed by the user-stated willingness to include the available transport modes examined within the current MaaS schema, i.e., the vector $\overrightarrow{UW }$ described in Section 3.2.

W^system is established for all the available transport modes within the MaaS Plans by processing previous MaaS Plans subscriptions.

$$W^{system }=\left(w_{PT}^{system},w_{TX}^{system},w_{BS}^{system},w_{CS}^{system} \right)$$

(7)

We use past subscriptions in an effort to build the W^system and define S_j (j = 0, 1, 2…, n) as the set of past MaaS Plans subscriptions, which are accumulated within W^system. Following this approach, each item is in the W^system vector is specified as follows:

$$w_x^{system}=\frac{1}{S_n}\left({\displaystyle \sum }_{i=1}^{S_n}{w}_x^i\times e^{-\frac{ln2\times \left(d_{today}-d_i\right)}{hl}} \right)$$

(8)

where $e^{-\frac{ln2\times \left(d_{today}-d_i\right)}{hl}}$ is a forgetting factor. More precisely, $d_i$ is the date when the subscription S_i occurs, $d_{today}$ is the current date and hl is the half time parameter set to 30 days, denoting that diminishing factor by half in the period of one month. Additionally, we consider that a user has S_n number of subscriptions. In conclusion, having formed W^user and W^system, the total willingness W is shaped as follows:

$$W=a\times W^{user }+b\times W^{system }$$

(9)

where a and b are weighting factors that satisfy the equation a + b = 1 and allow to control the effect of each of the two vectors. In our approach, we set a = 0.7 and b = 0.3. An illustration of the aforementioned is depicted in Figure 4.

4. Controlled Experiment

The purpose of the controlled experiment was to examine and compare the performance of the proposed recommendation approach against a range of other approaches and understand how these affect users’ decisions in the MaaS Plan selection process. For the purposes of the controlled experiment, we set up a web application that consolidated a set of MaaS Plans recommendation approaches, simulating the process of the plans selection task. The web application provides an adaptable framework within which the testing, comparison and evaluation of all the included algorithms are done, without the necessity for a real-life MaaS application.

4.1. Experimental Conditions—Recommendation Approaches

For the conduction of the experiment, a range of recommendation approaches that provide lists of MaaS Plans were chosen to be compared and evaluated. The intention was to infer conclusions regarding which algorithm provides MaaS Plans and corresponding lists that adhere to end-user needs and preferences.

The included recommendation approaches are described below:

• Price—desc/asc, signifies two approaches that use the basic technique of price ranking of the available MaaS Plans either in descending or ascending order.
• CSP approach, denotes the filtering approach described in Section 3.1, CSP which contains hard and soft constraints that are independently implemented with the latter performing on top of the results of the first. Finally, on the subset of filtered plans delivered by the CSP, a price ranking in ascending order is used.
• CSP with similarity approach, in this case, filtering based on hard and soft constraints is performed, whereas as a final step the similarity-based Plan Ranking technique is used on top of the filtered products and delivers a ranked list of MaaS Plans where, in the top positions, those most similar to the user profile plans are presented.
• CSP with similarity and price filter, the final approach includes approach 3 described above, along with an extra feature of price filtering, allowing users to adjust the plans within a restricted budget. Price filtering is a popular feature among e-commerce applications, which may likely be advantageous in the MaaS Plans selection problem. The feature concerns a specific functionality that provides users the ability to adjust the proposed product assortments within a budget they define and which practically filters MaaS Plans within a user’s price constraints. The user has the option to tune the price filter according to his/her budget in order to filter out plans that are priced higher.
  Table 1. Experimental conditions and examined features in the controlled experiment.

  Approach	Hard Constraints	Soft Constraints	Price Filter	Price Rank	Similarity Formula-Based Ranking
  Price-desc/asc				X
  CSP	X	X		X
  CSP with similarity	X	X			X
  CSP with similarity and price filter	X	X	X		X

  summarizes the different approaches described above, along with their corresponding features.

In terms of the experimental settings, we followed a within-subjects design commonly used in recommender systems evaluations (see, e.g., Ekstrand et al. [37], Paolacci et al. [38]), where participants are presented with pairs of recommendation lists generated by different approaches. The within-subjects approach allowed us to gather more results from the participants and minimize random noise, as explained in Charness et al. [39]. Moreover evaluation is a certainly comparable task, and evaluating each algorithm individually would deprive the users from relating them to one another as stated in Hsee, & Zhang [40]. Note that the pair “Price-asc” versus “Price-desc” was excluded from the list of potential joint evaluations, as there was no point to comparing these two extremes.

4.2. Users and Context

The experiment was deployed and instantiated in three different cities. The first instance was configured for the city of Budapest in Hungary, where MaaS pilots are being deployed and an introduction of a related concept has been already initiated to city inhabitants. Participants included graduate and postgraduate students from the Budapest University of Technology and Economics. A total of 302 users were recruited to participate, out of which 110 successfully completed the survey. The participants’ ages ranged between 21 and 39 years old. The second instance was configured for the area of California in the US and its corresponding mobility options. Users were recruited through the popular crowdsourcing platform Amazon Mechanical Turk (MTurk), which, as stated by Paolacci et al. [38], is viewed as a very practical option for data collection, considering that the participants demonstrate typical heuristics and biases and concentrate to guidelines no less than traditional sources’ participants do. Location-based restrictions were applied in MTurk to ensure that only users from the area of California could participate. In total, 268 users took part, out of which 113 completed the whole cycle of the experiment. In this instance, the ages of the participants ranged between 18 and 69 years old. The third instance was configured for the area of Greater Manchester in the UK. The participants were recruited by Atkins, a company that provides surveying services, and the participants’ ages were between 18 and 74 years old. There were 88 attempts, from which 39 were completed successfully.

4.3. Experiment Survey and Process

The experiment’s survey was developed as a web application, and users had to complete a five-step process. The survey begins with an introductory text and an informative video (Figure 5) that explains the concept of MaaS and tries to familiarize users with MaaS terms, including basic instructions of how to proceed with the experiment. Users press the “Start” button and move to the second step, where a group of sociodemographic questions are presented, intending to construct a user profile for the purposes of the current experimental session. The questions ask participants to provide personal information about their gender, their level of education, their working schedule, their employment status and to indicate if they already own a car and a driving license. The set of questions is displayed in Figure 6a. Subsequently, in the third step of the process, users are requested to complete a set of questions about their mobility habits. The corresponding questions ask users about the frequency of usage of each transport mode included in the MaaS instance examined, indicatively, “How often do you use public transport?” The user answers are used to construct the User-Habits vector; thus, the present questions are mandatory to answer. An indicative example of the set of questions is illustrated in Figure 6b. The various modes of transport included in this set of questions diversify according to the area where the experiment is deployed and conform with the mobility services available in this specific area. In the next step and within the “User Mode Preferences” page, the user is asked to state her/his willingness to include the available modes of transport in their MaaS Plan (“Please define your willingness to include the following modes of transport in your new MaaS Plan”). The potential answers are all shaped in a 1–5 Likert scale as it is displayed in Figure 6c per available transport mode.

Upon completion of all the questions described above, the system has collected all the essential data for the recommender service to run and produce the ranked list of MaaS Plans fitting a particular user’s needs. Prior to displaying the ranked lists of MaaS Plans to the users, a short explanatory message is displayed (Figure 7), clarifying to the user what s/he will be presented with and how s/he is asked to evaluate the given outcome of the system. Moreover, a table with the various levels of the included transport modes is presented to the participant, listing the modal allowances the MaaS Plans consist of. As exemplified in Figure 7, the user is informed about the diverse classes (xsmall, small, medium, large, xlarge) that describe the transport modes, which will be provided according to the user’s level of usage.

After the user finishes reading the aforementioned text, two lists of recommended MaaS Plans appear following the within-subjects evaluation. The pair of approaches is randomly selected each time in a way that ascertains that each approach is presented an equal number of times. Each of the presented lists shows five different MaaS Plans within a table, the rows of which correspond to a different MaaS Plan, and the columns depict the transport mode and the suggested mode level value, along with the price range of the proposed plan. Moreover, a rating column with a 5-star scale is shown, asking the user to rate the presented plans based on their preference. Figure 8 provides an indicative view of the plans recommendation lists for the recommendation approach “CSP with similarity and price filter option” (List 1) and the approach “Price-ascending” (List 2). After having rated the recommended MaaS Plans of each one of the two lists, an “Exit Questionnaire” follows, where the user is asked to respond to a set of questions assessing different qualities of the recommendations and the adoption of MaaS. In more detail, the questions are displayed in Figure 9. The participants’ responses to all the above-mentioned questions, along with the plans’ ratings, are further explored in the course of the evaluation stage of the experiment.

Finally, by pressing the “Save My Preferences” button, the experiment session ends, and the system saves users’ input, including his/her profile, the two distinct algorithms that are displayed each time within the running session, the start and end datetime of the conduction of the experiment, the two lists along with the ranked MaaS Plans displayed per each algorithm, the ratings of the MaaS Plans provided by the user and the users’ answers to the qualitative questionnaire.

4.4. Results

The results of the controlled experiment were extracted from two sources: (i) users’ answers to the question about their choice between the two presented lists, along with the average rating of the MaaS Plans on a list basis (i.e., the preferred recommendation approach), and (ii) the user answers to the five-point Likert scale questions of the exit questionnaire. Before the analysis, data were cleaned in order to remove invalid answers. More specifically, the average time execution of the experiment was calculated in 4 to 4.5 min, shaping the experiment’s median completion time. We removed cases of participants that conducted the survey in less than 1.5 or more than 12 min, as participants provided incomplete responses in these cases. Moreover, we checked the remaining cases and removed those where mismatches were observed following the answer to control question. In particular, we identified and removed cases where users provided high ratings to the plans of one of the two recommendation lists and subsequently stated that they prefer the other list in the control question. In the final dataset, the CSP approach was presented 101 times, the CSP_Sim was displayed 138 times, the CSP-Filter was shown 110 times, the Price-asc approach 94 times and the Price-desc approach 81 times.

Figure 10 depicts users’ answers to the question, “Please select the list that you would choose in a real-life MaaS setting”, in terms of percentages for the different approaches. The “CSP with similarity” approach was selected in 75% of the cases where it was presented either in List 1 or List 2. The approach, “CSP with similarity and price filter option”, is placed second and was preferred in 50% of the cases. This finding amplifies the role of CSP filtering, since the two most preferred approaches embed this filtering method.

A more thorough analysis on how the proposed “CSP with similarity formula” performed over the remaining approaches is provided in

Table 2. CSP_Sim selected when presented with the remaining algorithms.

Presented Pairs	CSP_Sim Selected (%)
CSP with similarity vs. Price-descending	80%
CSP with similarity vs. Price-ascending	82.86%
CSP with similarity vs. CSP	57.14%
CSP with similarity vs. CSP with similarity and price filter	80%

. The first observation conveys that, in the case of “CSP_Sim” versus “Price-descending” pair, the CSP_Sim was selected 80% of the time. Next, for the case of the “CSP_Sim” versus “Price-asc” pair, the “CSP_Sim” was also preferred over 82.86% of the time, whereas, for the case “CSP_Sim” presented with “CSP”, the “CSP with similarity” was chosen over 57.14% of the time. Conclusively, for the case of “CSP with similarity” versus “CSP with similarity and price filter” algorithm, the CSP_Sim was preferred in over 80% of the cases.

Table 3. The MaaS Plans contained within CSP_Sim approach were also rated higher compared the other approaches.

Presented Pairs	Avg Rating CSP_Sim	Avg Rating Other List
CSP with similarity vs. Price-descending	3.84	3.46
CSP with similarity vs. Price-ascending	3.38	2.84
CSP with similarity vs. CSP	3.31	3.29
CSP with similarity vs. CSP with similarity and price filter	3.53	3.43

provides a summarized view of the average star ratings of the MaaS Plans included in the CSP_Sim assortments against those derived from the other algorithms, as they are presented in pairs each time. The MaaS Plans calculated with the “CSP_Sim” approach were, in all cases, rated higher.

Note that the average star rating per list was formed as the average rating of the MaaS Plans contained within the particular list. T-test analysis was performed among the ratings of the different pairs in order to estimate the statistical significance between the mean ratings. The results showed statistical significance of the following pairs: “CSP with similarity vs. Price-descending” (t = −2.69, p < 0.05), “CSP with similarity vs. Price-ascending” (t = −3.54, p < 0.05) and “CSP with similarity vs. CSP” (t = −2.02, p < 0.1). The difference in the case of “CSP with similarity vs. CSP with similarity and price filter” was not found statistically significant for the given sample sizes.

Regarding the users’ responses to the five-point Likert scale exit questionnaire that was presented and filled in at the end of the evaluation process, the results are shown in Figure 11. The specific questions asked users to choose between two lists and identify how their choice better aligned with their preferences. More precisely, users were requested to provide their feedback on a five-point Likert scale, annotated on the left side with “Much more List A”, and on the right side with “Much more List B” (Figure 9). The corresponding results per question are illustrated in histograms containing normalized values and grouped user responses as follows: List A is considered to better comply with the presented statement when the users’ answers are either 1 or 2, whereas List B is considered preferred when the response is either 4 or 5.

Concerning the question, “Which list has more MaaS Plans that are close to your preferences?”, the “CSP with similarity” approach is in first place, while the “CSP” is in second place. More specifically, lists generated with “CSP_Sim” were selected 63% of the time that they were displayed, while lists generated with the “CSP” approach were selected 53% of the time. In the question, “Which list has more plans that you find appealing?”, “CSP with similarity” is placed first with 57%, while the “CSP-Filter” algorithm is second (50%) and in the third place, the “CSP” together with “Price-asc” is observed with 48%. Finally, the user responses to the question, “Which list has more plans that are in line with your budget for transportation?”, shows that lists generated with “Price-asc” were the most desired (57%); thereafter, the lists generated with “CSP” approach follow with 56%, while lists with “CSP with price filter” come in the third place (50%). An interpretation of these results is that, under for this particular question, users consider certain budget constraints, which reasonably leads them to less expensive plans, which can be found most easily within Price-asc lists or in the CSP algorithm, where the plans were also ranked in ascending price order. Moreover, the price filter option gained significant attention, since it provided the opportunity to adjust the suggested MaaS Plans assortments within the user’s subjective price budget.

Figure 12 illustrates the answers to the question, “What were the three main reasons for rating higher MaaS Plans”. The majority of the participants rated higher what resembled “Most similar to what I use today”, then “Best transport mode combinations” is in second place with 26%. Next, the reason “Cheapest” follows, with 24%, and finally, whether a particular MaaS Plan was of the “Best value” is considered as the last reason that affected the users choice to rate this plan higher. The answers to this question highlight the fact that properly identifying users’ habits and transport mode preferences is crucial in the process of recommending meaningful and preferable MaaS Plans.

Moreover, we examined the stated reasons for rating higher MaaS Plans while considering the sociodemographic characteristics of the respondents, aiming to identify differences across user groups. The results showed that full-time-employed participants considered the “Best value” of MaaS Plans in contrast to participants with those with employment statuses of part-time employed, retired or student, whose choices were determined by “Best transport mode combinations”. The differences could be attributed to the fact that full-time-employed persons commute daily and seek to balance cost and benefits. Differences were also observed when we considered the age of the participants. In particular, participants in the age group of 54–72 were more inclined to rate higher MaaS Plans “Most similar to what I use today”. This could be attributed to the fact that such persons are not willing to change their current habits. No major differences were observed when considering the sex and education of the participants.

Additional ideas stated by the participants of the controlled experiment were their replies to the query, “What other information would you like to see in order to support you better to choose MaaS Plans?” The findings are provided in

Table 4. The participants’ responses to the question, “What other information would you like to see in order to support you better to choose MaaS Plans?”

What Other Information Would You Like to See in Order to Support You Better to Choose MaaS Plans?
More details on plans, terms and conditions: ▪ How far the transportation choice is from current location; ▪ Comfort and safety information (wi-fi, phone charger etc.); ▪ Details on how the provided levels are used (e.g., 1 h car rental); ▪ Information about green modes of transportation; Reviews of included transport service; ▪ Details about possible credit refund in case of no usage of purchased services
Total/separate price of the services if not in a package
Add more services (e-scooter, parking, etc.)
Option to build your own plan
MaaS Plans without public transport service
Bonus/rewards
More duration options of provided MaaS Plans (6 months)

, below.

The results show that users would like to have access to additional information about the terms and conditions of the transport modes included within the purchased MaaS Plans, e.g., wi-fi available, etc., or certain instructions of how the mode allowances of the modes should be used (e.g., 1 h car sharing). Moreover, the users would be interested to know the individual prices of the modes if these were not included in a MaaS Plan. There is also a keen interest by the users for more transport services to be included (e.g., parking, e-scooter) or to enjoy the experience of creating their own MaaS Plan. Other propositions include MaaS Plans without public transport services and the promotion of MaaS through potential awards/bonuses.

5. Real Life Pilots

The proposed plans recommendation approach was integrated in a mobile application developed to support real life MaaS pilots in the cities of Budapest, Manchester and Luxemburg as part of a collaborative European research project called MaaS4EU. The MaaS4EU mobile app was available in Google Play Store and App Store for both Android and iOS devices, providing a range of options to the user that facilitate the adoption of MaaS. The MaaS Plans selection process within the app is illustrated in Figure 13. The process starts with a set of questionnaires that extract the user’s mobility habits, asking about the usage frequency of the various transport modes included in the examined MaaS schema (e.g., “How often do you use public transport?”) and other information that shapes a user’s mobility profile (e.g., “Do you have a full driving license?”, “Does your household own one or more cars?”). In the next step, users are asked to indicate their willingness to include the specific available transport modes within their MaaS Plan. At that point, all the required user input has been collected and processed. The recommender runs, incorporating the user input within the predefined constraints and the similarity formula. The system provides a ranked list of suggested MaaS Plans. The top three recommended plans are then displayed, while the user is provided with the option of “Load More” to further browse more plans. The user selects the MaaS Plan that attracts her/him more and has access to a more detailed description, indicating the various levels of the transport modes within each specific MaaS Plan. Finally, the user may decide to buy a specific plan and subscribe to MaaS. Note that, for the case of an existing user that has already provided her/his feedback into the system, s/he is asked during the initial launch of the app whether s/he would prefer to update her/his preferences. Alternatively, the system executes on top of the already registered user’s data input.

Concerning the performance of the proposed recommender service that was integrated and utilized within the mobile app version for the pilot phase, an interesting query that would estimate its efficiency within each MaaS setting and city was the position of the selected MaaS Plan within the presented ranked list of plans. The goal is to present the actual purchased MaaS Plans by the users within the top positions of the list, meaning that the system has the ability to understand a user’s special needs and thus provide the desired MaaS product presented in a distinct place. Figure 14 indicates that the majority of the selected/purchased MaaS Plans were successfully chosen from the top three places in all cases. Note that, in the case of Budapest, the pilot was split in two periods. The first one started in January 2020 but was abruptly stopped due to the COVID-19 pandemic. The pilot restarted in August 2020.

The results show that, in the first period of the pilot in Budapest, 79% of the purchased Plans were included in the top three positions, while for the second period, the purchased MaaS Plans were in the top three positions in 82% of the cases. In the case of Greater Manchester, the selected plans were in the top three positions in 81% of the cases, whereas in the city of Luxemburg, the proportion was 64%.

Last but not least, a supplementary mechanism that intended to gain explicit user feedback about the recommended MaaS Plans was implemented in the form of notification messages that were displayed to the users of the app when they navigated in the plan selection screen (Figure 15). Two messages were defined and integrated in the notifications mechanism, asking users to provide their degree of agreement or disagreement in a five-point Likert scale extending from Strongly disagree (1) to Strongly Agree (5), to the following questions: “The recommended plans are close to my travel preferences” (Q1) and “The recommended plans include transport modes that match my preferences” (Q2).

Figure 16 shows the results of the users’ answers. The results indicate that most users agreed or strongly agreed that the recommended plans were close to their preferences and included transport modes that they prefer.

6. Conclusions

In this paper, we presented the MaaS Plans Recommender, designed and implemented in order to support MaaS end-users in identifying and selecting the mobility plans that fit their transportation needs. The proposed recommender provides filtering functionalities that rely on concepts of constraint programming by leveraging user feedback in a knowledge-based implementation. This approach was chosen due to its ability to tackle the so-called cold start problem, which is apparent within new fields of research or market that lack past data, including MaaS. Moreover, the recommender ranks filtered MaaS Plans with the use of a similarity formula, which considers users’ habits with respect to the use of different transport modes as well as their willingness to include different transport modes in their plan. When past user choices are available, the recommender considers them and infers users’ preferences in a data-driven manner. The proposed recommender was evaluated in experimental settings as well as in real life situations in the context of MaaS pilots, which were deployed in Budapest (Hungary), Luxemburg and Greater Manchester (UK). The experimental results showed that the proposed approach provides lists of MaaS Plans that users would choose in a real-life MaaS setting, in the majority of the cases. Moreover, the results of the real-life pilots showed that most of the participants chose an actual MaaS Plan from the top three places of the recommendation lists.

The proposed recommender can be utilized and fit into potential MaaS applications. When deploying the recommender, practitioners need to perform proper configuration of the recommendation service by performing a thorough study of available transport modes and MaaS Plans. In particular, the available mobility modes and their attributes are the elements that form the constraints of the recommendation model and should be configured and updated for the application at hand. Moreover, the mechanism that infers the similarity between user preferences and MaaS Plans and relies on capturing users’ habits and willingness to include different modes of transport in a MaaS Plan. As the ranges of the various mobility modes included in MaaS Plans depends on the application at hand, the corresponding hard coded information needs to be modeled and configured into the RS on a per city case basis.

Last but not least, future research is needed to examine the following aspects of the proposed approach. First, as already described, the proposed recommender system integrates a data-driven module that infers users’ preferences based on past plans choices. Our pilot studies could not capture enough repeated user choices that would allow us to gather enough data to properly evaluate this aspect of our approach. Longer term and longitudinal studies are needed so that users purchase enough subscriptions and the available data are adequate for generating recommendations based on past user choices, which would allow for proper evaluation of this aspect. Moreover, such studies could be used to understand the effects of seasonality and how user choices change in different times of the year, thus informing the recommendation process. Furthermore, in our approach, we considered item-based similarity measures to infer the similarity between user preferences and MaaS Plans. As MaaS becomes mainstream and more data are available, future research should focus on examining user-based similarity measures that could uncover mobility habits that similar users present, shaping potential clusters of communities within the MaaS schema. Additionally, metrics such as distance, cost, safety and traffic could potentially be incorporated within future versions of the recommender system and amplify its personalization ability.