Location-based social networks (LBSNs) are rich sources of studying travel mobility of people. With more users sharing updates about their activities in LBSNs, there is a high availability of data to learn about their travel mobility patterns. This can help to improve travel recommender systems, as we get a realistic impression of travelers' travel behavior. We propose a system that recommends personalised city trips to diferent users by employing data-driven approaches. Our web-based system recommends composite trips of 138 cities all around the world. The application elicits user information and preferences like home region, destination region, traveller type, maximum travel duration and fondness for diferent types of venues in a city, as inputs. Satisfying the user preferences and constraints, a suitable trip including an ordered list of cities with duration of stay at each is determined, to be recommended to the user.
Destination recommender systems (DRSs) can help travellers to
discover destinations to travel to. Depending on the type of data
utilised, a recommendation model can be collaborative filtering
(CF) or content-based filtering (CBF). The former model is typically
based on explicit or implicit user feedback. CBF-based recommender
systems (RSs) use the characteristic features of the items and the
preferences of a user before generating the recommendations for
them. The design of RSs, which earlier relied only on
intuitionbased models, is now employing more data-driven approaches [
City tourism, also known as urban tourism involves travelling to
the urban cities of diferent countries. It facilitates the development
of the cities to attract tourists. Moreover, with more than half of
the world population staying in urban areas [
Google Trips1 collects data from Gmail account of a user and combines it with other features like crowd-sourced reviews about destinations for suggesting trips to her. However, this is not personalised for users without prior Gmail accounts. Due to the inherent complexities, there is no application in the market that uses datadriven approaches for determining personalised, composite city trips for all users, motivating us to start working further in that direction. To tackle this challenge, we discover travel mobility patterns from LBSNs and utilise them for computing personalised composite city trips.
Traditionally, destination recommendation was subdivided into
recommending regions [
POI recommendations by Yu and Chang [
We discuss the system in three broad stages – the data engineering & analysis (pre-processing), CBF-based recommendation (periprocessing), and user-centric evaluation of the web application (post-processing). 2.1 Initially, we collect, analyse and clean the data to make it ready to be used for the CBF-based recommendation. 2.1.1 Mapping of World Regions. We divide six continents of the world (except Antarctica) to 10 global regions, viz., North America, South America, North Europe, Southwest Europe, Southeast Europe, North Africa, South Africa, West Asia, East Asia and Oceania. Figure 1 displays these regions on the world map. 2.1.2 Datasets – Cities & Trips. We consider 138 cities to be recommended to travellers of diferent types. The cities are attributed with diferent features. Those involving the frequencies of venues, with diferent types of touristic values located in the cities, are called arts & entertainment (AE), food (FD), nightlife (NL), and outdoors & recreation (OR). The types of these venues are based on four of the Foursquare venue categories2. We divide each of the frequency values by the total venue counts of all four types considered in the respective cities. This is done to avoid bias due to the varied range of venue counts in diferent cities and check the prevalence of the diferent types in each of the cities. Finally, for each city, stemming from a number derived from Numbeo3, the cost index (CI) values are normalized between 0 and 100.
Trips are identified out of the check-ins from Twitter using a
data-mining approach [
Í
=1 ∗ = Í , (1)
=1 where is the distinct number of blocks (cities) within the trip, denotes the number of times block is visited 2https://developer.foursquare.com/docs/resources/categories 3https://www.numbeo.com/cost-of-living/ Roy and Dietz within the trip, denotes value of the feature for block , and designates , , , , or .
After this characterisation, some of these trips are removed based
on their poor qualities to assure a better quality of the dataset.
2.1.3 Identification of Regional Traveller Types. Unlike the previous
papers for clustering travellers [
In the trips we consider, not all traveller types visit all the cities. However, we can find visits to all of the 138 cities in our database, if we consider the travellers of all types. We do not intend to omit the possibility of recommendation of any of the 138 cities to any traveller type. We update the duration of stay at a city with the average stay by the travellers of all types belonging to the particular home region, if it is found to be zero by the current traveller type. If it is still zero, we update the duration again with the mean duration of stay in the city by the travellers of all types from all the home regions. This is done for every city, for the 47 traveller types. 2.2
This section explains the user inputs, CBF-based recommendation algorithm and the overview of the web application. 2.2.1 User Inputs. A user needs to input her preferences based on which a CBF-based recommendation is provided to her. Following are the inputs required for our algorithm: (1) Home region of the user, chosen from the 10 world regions. (2) Traveller type of the user that suits her the best, chosen from the list of traveller types for those having their home same as the user’s home region. (3) Destination region for the user’s desired trip, chosen again
from the 10 world regions. (4) Maximum duration for the desired trip.
(5) The preference levels for the diferent city-based features. 2.2.2 Recommendation Algorithm. After calculating the duration of stay at diferent cities for diferent traveller types, and after TripRec – A Recommender System for Planning Composite City Trips Based on Travel Mobility Analysis having the inputs from one user, we utilise the following steps as part of the recommendation algorithm to plan a composite city trip for her: (1) Filtering Cities According to Destination Region – From the 47 lists of cities with diferent duration of stays for different traveller types, we select the list based on the current user’s home region and her travelling type. From that list of 138 cities, we remove the ones which do not belong to the region chosen by the user as her destination region. As a result, we are left with a subset of cities considered further for recommendation. (2) Assigning Scores to Cities – For each city in the filtered subset, we find the Euclidean distance between the city-based feature vector ( = [ , , , , ]) and the user preference vector ( = [ , , , , ]).
This is followed by using equation 2 to assign a score to each of them. The simple score metric used here serves the purpose of giving higher values to the cities whose feature values are closer to the preferences of a user.
1 ← + 1 (3) Selection of Cities – The filtered cities are sorted based on the scores assigned to them. Then the greedy selection of the highly scored cities is done until the total duration of stay at the selected cities does not exceed the maximum travel duration input of the user. This constitutes the initial list of selected cities. Some of the cities, that are far away from others in the list and have only a single day as the duration of stay for the current user, are removed from the list. After the removal, if the constraints permit, more cities are considered to be added to form the final list of selected cities. (4) Ordering of Cities – For ordering the selected list of cities, we initially find diferent orders starting from each city in the list as source and moving to the nearest one next. Then we calculate the total distances to be covered for visiting the cities in the diferent orders, and pick up the specific order with the shortest distance to be covered. 2.2.3 TripRec Web Application. We develop TripRec , a data-driven prototype web application to recommend composite city trips to diferent types of travellers using the discussed recommendation strategy. A user interface (UI) facilitates the interaction between a user and the system. Figure 2 shows the interaction flows between a user and the system through the UI for TripRec.
While prompting a user to provide diferent inputs for eliciting
her preferences, the system also guides her with helpful information
in every step while she uses the application. As a trip
recommendation, the UI displays the cities, its corresponding countries, and
the duration of stay at each city in the order returned by the
recommendation algorithm. This is also accompanied by presenting
the order of visits to the recommended cities using Google Maps4.
If no recommendation is found for the specified inputs, the user is
asked to modify them and try again. Figure 3 shows an exemplary
recommendation result to a user from Southwest Europe, opting to
visit some cities in North Europe within 16 days as Eurotrotters [
The user needs to specify their level of agreement to the diferent
statements on a five-point likert scale [
We conducted a user study for TripRec to examine the behaviours of
its users, their opinions about the system, and some characteristics
of the services provided to them. Within a span of two weeks,
we accumulated 217 recommendation requests from 113 unique
users, 75 of whom provided feedback used for the evaluation of the
application.
2.3.1 Diferent Users and their Behaviours. The application
received the maximum number of requests by people from West
Asia, followed by those from Southwest Europe and Southeast
Europe, whereas there were no users from Oceania. Other than West
Asia, users wanted to go to the European regions, viz., Southwest
Europe, Southeast Europe, and North Europe the most. Irrespective
of home regions, the users usually tend to visit cities with low to
medium cost index. A lot of the users chose to follow the traveller
type vacationers [
Next, we compare the users’ agreement levels to the various feedback questions. Users seem to have mostly agreed to the provided questions in favour of TripRec. However, looking at the responses closely, we note the following points: (1) Most of the users were satisfied with the individual recommendations (1). However, the number of users satisfied with the composite recommendations (2) was comparatively lower. Roy and Dietz (2) Users dissatisfied with the recommended duration of stays (3) were comparatively more than those dissatisfied with the recommended cities (1, 2). (3) Maximum number of users have strongly agreed to having clear layouts and labels for the interface (7), followed by those strongly agreeing to being able to specify their preferences to the system (5) and then modify them (6) as well. (4) A lot of users have agreed to have overall liked TripRec (8).
However, comparatively lesser people agreed to use the system again (9) in real-life. People were more neutral about the latter, possibly because of the system being a research prototype that can recommend from just 138 cities.
Finally, we determine how long the users interact with the system in terms of interaction time and feedback time. We consider only the final interaction time by each user. Eliminating an outlier record with interaction time of about 10 hours, we plot the histogram for interaction time as shown in Figure 4:Left, the mean interaction time being 4 minutes and 40 seconds with 6 minutes standard deviation. Figure 4:Right shows the histogram for feedback time, the average being 5 minutes and 45 seconds with standard deviation 12 minutes and 25 seconds. for any user, after analysing mobility data from location based social networks. The overall complexity of composite destination recommendations is very high, which is reflected in our system, which employs various data engineering steps, including characterisation of cities and trips, mapping of the diferent cities to 10 world regions and identification of regional traveller types. We presented a novel algorithm for content-based composite city trip recommendations, which we deployed in prototype web application that served as an user-centric evaluation platform.
For the upcoming versions of TripRec, we can incorporate
features like the budget information of the recommended trip and the
lfight booking options, which were out of scope for our present
research and the prototype application. POIs specific to user
preferences should be shown to the users, when demanded, for each
of the recommended cities. This might enhance user satisfaction
and ensure recommendation transparency. Furthermore, we plan to
develop strategies for computing recommendations when the user
has specified a set of preferences that would currently return an
empty set. Such empty recommendations could happen due to the
limited availability of only 138 cities for our prototype application.
We can add more cities to our database to provide more realistic
recommendations. The world divisions could then also be made
more granular using a touristic region model [
Finally, we can also make our next prototype more responsive for more devices other than web. More options can be provided to the users to elicit their interests, priorities, and posteriorities, for greater user satisfaction.