Hotel recommendation sufers from a severe sparsity problem. Travelers only book hotels once or twice a year, and one booking dataset may not gather all the bookings done by one user. Cross-domain recommendation can be leveraged to face the sparsity problem by exploiting knowledge from a related domain where feedback can be easily collected. In this paper, we propose to leverage check-ins data from location based social networks to learn mobility patterns and use it for hotel recommendation, considering that the choice of destination is an important factor for hotel selection. We present our developed solution, where we map items and users from both domains based on a number of observations, learn preferences for regions and for hotels, and combine the results to perform the final recommendation. Experiments on a real booking dataset using a dataset of geolocated posts show the interest of using data from other domains to boost hotel recommendation.
Recommendations in the travel and tourism domains have
become essential with the exponential growth of available data
on the Web which have turned trip planning into a tiring and
time-consuming task [
While RS have been deployed in many domains, hotel
recommendation must take into account the constraints
considered by users when choosing a hotel, which are not present
in other domains. In addition, hotel recommendation
suffers greatly from sparsity since traveling is not a frequent
activity [
One way to address the sparsity problem is to leverage
knowledge from other related domains where it is easier to get
information regarding the behavior of users. Cross-domain
RS [
When organizing a trip, travelers usually select the destination to visit before choosing the hotel where they will stay and the choice of accommodation highly depends on its location. Choosing a destination to visit is in turn related to several factors. First, the majority of trips are meant to explore destinations which are close to the place of residence of travelers. Then, users tend to follow the actual trends running locally which are also likely to change with time. In addition, the timing of the trip has an impact on the chosen destination. Some destinations are more popular during summer than winter, and leisure trips are more frequent during vacation periods.
Since hotel bookings are collected by organizations managing a subset of hotels and accommodations, hotel booking datasets do not cover all trips done and destinations visited by users. On the other hand, recent years have witnessed the emergence of Location Based Social Networks (LBSN), e.g., Flickr and Foursquare, where the mobility of users is captured through their check-ins. When exploring points-of-interest, users share their experiences on LBSN, making them a rich data source to analyze travel experiences.
In this paper, we address the problem of hotel recommendation sufering from sparsity by leveraging check-ins data from LBSN. We learn mobility patterns from the check-ins which are easily shared on LBSN and use them in combination with hotel preferences in order to boost hotel recommendation. We first map check-ins and hotels to a common space of geographical regions based on the density of hotels spread worldwide. We learn preferences for geographical regions based on check-ins data, link users from both domains, and combine the preferences in order to generate recommendations. Experiments on a dataset of hotel bookings extracted from the hotel industry show the interest of using LBSN data.
The rest of the paper is organized as follows. In Section 2, we discuss related work on hotel recommendation and crossdomain recommendation. In Section 3, we present our approach for hotel recommendation leveraging mobility data from LBSN. Experiments and results are discussed in Section 4. Finally, Section 5 concludes the paper. 2
Hotel recommendation. Several data sources have been
exploited in previous work to address the problem of hotel
recommendation. Saga et al. [
Even though destination is an important parameter for
hotel selection, the problem of hotel recommendation is diferent
than the one of point-of-interest recommendation [
Cross-domain recommendation. Cross-domain RS [
Passing from one domain to the other requires
considering the overlap between users and items or the similarities
between item features and user behavior, in the diferent
domains. Cremonesi et al. [
Several techniques have been developed to perform
crossdomain recommendation. Cantador et al. [
In this work, we use basic approaches for cross-domain recommendation to leverage data from LBSN and we show the interest of using them for hotel recommendation.
Motivation. In order to cope with the sparsity problem faced in hotel recommendation, we propose to learn mobility patterns from check-ins shared on LBSN and combine it with hotel preferences in order to generate recommendations. In the source domain , we have active users on LBSN, , who share their check-in activity. The items ℐ are the geolocated points visited. The target domain is the hotel domain where the users are the one booking hotels and the items to recommend, ℐ , are the hotels. In the problem we are considering, there is no overlap between users from both domains as we are not able to link users posting on LBSN and users booking hotels. However, a mapping can be done between check-ins ℐ and hotels ℐ based on the corresponding location, and similarities between users from both domains, and , can be computed based on the visited locations.
Our work is motivated by a number of ideas. First, our approach is inspired from the real decision-making process of users when choosing a hotel: They first select a destination to visit, and then a hotel where they can stay. The source domain contains users’ paths through their check-in activity. We try to use the knowledge from the source domain to learn accessible destinations for users based on their history. Accessibility usually relies on distance, cost, value, and other hidden variables.
We are therefore interested in the mobility patterns at a high scale. In our problem, preferences for regions are more relevant than preferences for specific points-of-interest. Based on data from LBSN, we can get the set of cities visited by one user, for example, and use this information for recommendation. Once the destination is selected, the hotel choice is more likely to depend on its features. On the other hand, hotels are not equally spread worldwide. When considering regions where we have a high density of hotels, it would be relevant to learn preferences for diferent subregions. Since all the neighborhoods in a specific city do not have the same characteristics, travelers may prefer one over the other.
We consider therefore a decomposition of the world map in several regions, where the region size depends on the corresponding hotel density. Items from both domains, ℐ and ℐ , are mapped to these regions. Using the behavior of users on LBSN, we learn the preferences of users to the defined regions.
To benefit from these insights, and since there is no overlap between users from both domains, we associate users from the target domain, , with the ones that are the most similar from the source domain, , with respect to the visited regions. Preferences for geographical regions and hotels are ifnally combined to generate hotel recommendations.
In the following, we detail each part of our approach. In
this Section, a recommendation method designates any latent
factor model [
Mapping items from both domains. As mentioned before, we decompose the world map into several regions denoted as ℐℛ and map check-ins and hotels to these regions based on their location. The world map decomposition depends on the density of hotels in each area: Regions with high density of hotels should be further decomposed into subregions.
We rely on a hierarchical division of the space into
rectangular spaces used in [
We cluster hotels using a top-down approach based on the hierarchical structure of cells. The density of hotels in one cell is defined as the number of hotels located there divided by the area of the cell. For every level, starting with the first one, we compute the density of hotels in each cell. We then compare it to the density of the parent cell: If it is higher, we consider it as a cluster, otherwise, we move to the next level and repeat the process. This process is maintained until all the hotels are clustered or until we reach the maximum level.
Each cell containing a cluster of hotels is included in ℐℛ. Each item from the sets ℐ and ℐ can be associated to a region from ℐℛ. Using the feedback from the source domain (i.e., LBSN data) and ℐℛ, we learn preferences for diferent regions.
Mapping users from both domains. Our aim is to use the preferences of users in to regions in ℐℛ to infer the preferences of users in to these regions. In order to do so, and for each user from , we compute its neighbors (i.e., most similar users) contained in using a similarity measure. denotes the set of most similar users in for the user ∈ . The similarity measure handles user profiles from both domains defined as a binary vector which dimension is equal to the cardinality of ℐℛ. If the user visited a check-in or a hotel located in a specific region, its value in the vector is 1, otherwise it is 0. We aggregate the region scores computed for each neighbor to get the scores for the target user.
Hotel recommendation. Performing hotel recommendation for a target user ∈ requires computing hotels’ scores, denoted by , for each hotel ∈ ℐ . Hotels are then ordered according to their scores and the hotels having the highest scores are selected for recommendation.
The score computed is the combination of two scores: one from the source domain denoted by , i.e., a score revealing the region preference for region ∈ ℐℛ, and the other from the target domain denoted by , i.e., a score revealing the hotel preference for hotel ∈ ℐ .
In the source domain, we build a recommendation model modeling the preferences of users in to regions in ℐℛ and enabling the computation of scores of regions ∈ ℐℛ for each user ∈ , i.e., . In the target domain, we build a recommendation model modeling the preferences of users in to hotels in ℐ and enabling the computation of scores of hotels ∈ ℐ for each user ∈ , i.e., .
Final recommendations are performed for users from . The score revealing the region preference for a user ∈ is the aggregation of scores for the most similar users in . The score revealing the hotel preference for a user in , , is directly computed using the built model. Both scores are combined and the final score for hotel located in region is given as follows, having a predefined weight parameter : ∑︀∈
|| = . + (1 − ). (1)
In this work, we use a matrix factorization method, Bayesian
Personalized Ranking [
In this Section, we present the experiments we conducted to prove the interest of our approach.
Datasets. We used one dataset from each domain in order to test our approach. The hotel booking dataset is extracted from the hotel industry and contains bookings done by users during the last 3 years. It consists of 7.8M users, 4.5k hotels, and 34M bookings. Users come from all the world and hotels are spread in more than 90 countries.
We use YFCC [
Experimental setup. We split the booking dataset into a training and a test set. We sort the bookings of each user in a chronological order and select the first 80% of bookings as the training set and the rest as the test set. We also select 20% of the users who have only done one booking and add them to the test set in order to evaluate the performance on new users. We use the data from the training set to train our recommendation method and evaluate its performance on the test set.
Evaluation metrics. We consider that we recommend hotels to each user and we note which of these hotels were actually visited by the user. We use @ and @ for measuring the performance. @ is defined as follows: ℎ ℎ ℎ ℎ ℎ (2)
The Normalized Discounted Cumulated Gain (NDCG)
measures the ranking quality and @ is the
normalized @ which is computed as follows:
@ = ∑︁ 2 − 1 ,
=1 log2( + 1)
(3)
where is a binary variable for the -th hotel of the
recommendation list, that is equal to 1 if the corresponding hotel
is visited by the user and 0 otherwise. The @ and
@ for the entire system are the average @
and @ over all evaluated users respectively.
Parameters. We performed a grid search over the
parameter space of the methods in order to find the parameters
that give the best performance. We report the performance
corresponding to the parameters that lead to the best results.
Compared methods. We include in our comparison
traditional recommendation methods that are listed in the
following:
∙ MostPop recommends the most popular hotels to the
users.
∙ CB is a content-based method where hotels and users
are represented in the space of hotels’ features using
vector space models and tf-idf weighting [
Results. Figure 1 shows the performance of the methods we consider. The results are represented for each category of users, defined by the number of bookings present in the training set. By definition, the metrics we use decrease when the number of bookings increases.
MostPop is the only method able to recommend hotels to inactive users (i.e., users with zero bookings in the training set). The inferiority of CB shows that users do not attribute a great importance to all the hotels’ features considered. Further investigations showed that the location of the hotel is one of the few factors that greatly afect the decision. Knnu performs well for users with few bookings while BPR outperforms the other methods when the number of bookings increases significantly.
The results obtained for CD show the interest of using data from LBSN to alleviate the sparsity problem. CD outperforms all the other methods when the number of bookings is less than or equal to 10 bookings. The interest of using crossdomain information decreases when the number of bookings increases: BPR outperforms CD when the number of bookings is greater than 30.
One explanation may be due to the fact that the behavior of users actively sharing content on LBSN is not fully representative of the behavior of all travelers. In particular, people having done more than 30 bookings are more likely to be businesspeople which behavior is not necessarily similar to users on LBSN. In addition, once enough feedback about hotels is collected, it may be suficient to learn hotel preferences and generate good recommendations. The interest of using CD is highlighted in the cold-start setting where hotel bookings alone are not enough to infer preferences. We note that the majority of users in the booking dataset have done less than 10 bookings and therefore, CD improves the global performance.
Discussion. This is the first work proposing to apply crossdomain recommendation in the hotel sector using, in particular, abundantly available data from LBSN. While it can be a promising approach especially in a sparse data environment, it opens several interesting challenges.
First, not all users have their mobility behavior represented by active users posting on LBSN. These users will not directly benefit from the proposed approach. A finer analysis of users posting on LBSN, i.e., users in the source domain, and users booking hotels, i.e., users in the target domain, may help identifying relevant user segments which behavior can be similar in both domains in terms of mobility and probably underrepresented in one or in both domains. As a first basic approach, we tried addressing this issue by defining segments based on the number of bookings made and comparing recommendation performances in each one, considering that the number of bookings made may reveal a certain aspect of the user category. Other alternatives including more advanced techniques may be applied. One possibility to benefit from cross-domain recommendation may be then to learn local models by user category.
Second, further advances in this direction should consider evaluating the recommendation diversity in terms of proposed locations. It is important to generate diverse recommendations and avoid suggesting hotels located in one same area. This may occur when one region gathering several hotels is promoted for a particular user.
Transferring knowledge from LBSN to the hotel sector may go beyond the mobility aspect by also considering temporality, i.e., periods during which one region is visited by specific users, and context of visits for example by analyzing metadata associated to the posts. In addition, while we used a clustering component to map both domains, other approaches for integrating knowledge may be exploited. For example, we may be considering to rely on a multi-task approach and to train models in both domains simultaneously.
In this paper, we propose to use data from LBSN to boost hotel recommendation. Hotel selection largely depends on the visited destination and some destinations are more accessible to users than others. Using the check-in activity from LBSN, we learn preferences for regions and use these preferences for hotel recommendation in order to address the sparsity problem. Mapping of items from both domains is done through a space of regions which definition is based on the density of hotels. Mapping of users from both domains is done by computing the similarity between users based on the visited locations. Hotel recommendation accounts for region preferences and hotel preferences. Experiments show the interest of using cross-domain information for users with few observations, i.e., in the cold-start setting.
Temporality plays an important role in the decision-making process: One destination is not considered by the same user in all periods of the year. Future work will involve adding the time dimension and taking into account in which period of the year the check-in was made in order to distinguish between users visiting the same destinations at diferent periods or seasons.