We propose a personalisation solution to recommend tailored restaurant deals for residents or visitors in a city. Unlike previous work on recommendations in the restaurant sector where actual venues are recommended, we focus on suggesting specific products in the form of deals ofered by such restaurants. This is done by jointly filtering relevant information for the end-user based on their food-drink preferences, the popularity of the restaurant, its proximity to the user's location and temporal constraints on the availability of deals. A real case study has been conducted upon datasets provided by Wriggle, a platform for discovering local deals in various cities across England.
Personalisation services for tourism, leisure and
entertainment have been investigated for recommending
Points-ofInterest (PoIs) or sequences of them [
Various research eforts have been made on
recommending suitable restaurants based on diferent forms of user
preferences and contextual factors [
We present a model for recommending temporary deals offered by restaurants, taking account of (i) users’ preferences on food-drink categories, (ii) contextual information and (iii) restaurant popularity. In our approach, the recommendable items are deals ofered by restaurants, rather than restaurants “as a whole”. We investigate the problem of weighting (balancing) and aggregating similarity information for the three aforesaid aspects. In addition, we conduct a case study and a preliminary evaluation with real user and restaurant deal data provided by Wriggle on three UK cities. The results hint that by setting the weighting parameters for balancing the aforesaid sources from user to user, our proposed scheme has the potential for addressing the cold start problem (e.g. ifrst-time visitors to a city with no purchase history), hence becoming adaptable to both local residents and tourists. 2
Let ui ∈ U be the ith user and U the set of all users. Denote
by C = {c1, . . . , cM } the set of existing food-drink categories
in the system, e.g. ’cocktails’, ’tapas’, ’Indian’, ’Chinese’, etc.
Given M categories, every user ui has associated a preference
vector Pi = (pi1 pi2 . . . piM ) where pik ∈ {0, 1} is a preference
indicator towards category ck by ui . In our current version of
the model, the value of pik is binary and determined
depending on whether the user consumed deals under ck or not. A
restaurant deal xj ∈ X , with X the set of all restaurant deals
(item set), can have associated one or more categories ck ∈ C.
Thus, we formally define a deal as a tuple xj = ⟨rxj , Cj , Vj ⟩,
1Wriggle website: https://www.getawriggleon.com/
where rxj is the restaurant that ofers the deal. Cj is the
temporal context of the deal, namely start and end date at which
the deal is available, and whether it is a lunchtime and/or
dinner time deal. Vj = (vj1 vj2 . . . vjM ) is a binary feature
vector associated with the ofer, in which vjk = 1 if the deal
xj is labeled with category ck , and vjk = 0 otherwise. Our
solution consists of two major stages: a context-based item
pre-filtering stage, and a weighted filtering stage.
Item pre-filtering. Unlike rating-based context pre-filtering
approaches in the literature [
Weighted filtering. This stage applies three matching
processes and then weighs and aggregates resulting similarities:
(1) Preference Matching: It calculates the similarity between
ui preferences on food-drink categories, given by Pi , and the
specific categorical features of a deal xj , given by Vj . The
cosine similarity is determined between both one-dimensional
vectors, mα (ui , xj ) = sim(Pi , Vj ). In essence, this filtering
process entails a content-based approach relying on user
preferences and item features of deals, hence it can easily
integrate other content-based models in extant literature.
(2) Popularity Matching: This process takes the restaurant
popularity into account, based on the average customer
rating given to the restaurant. The popularity matching is
calculated as the average customer rating of the restaurant
rxj , thus mβ (ui , xj ) = pop(rxj ). Despite its simplicity, this
solution is not personalised for the end user in question,
because it is only dependent on rxj . An alternative personalised
solution would be to apply a Collaborative Filtering (CF)
algorithm to identify the K most similar users to ui who rated
rxj , based on their preference vectors Pi , and predicting how
popular the restaurant might be for ui .
(3) Location Matching: It takes the distance between
restaurants within a predefined radius and the current user location,
thereby prioritising deals from closer restaurants:
mγ (ui , xj ) = 1 −
dist (ui , rxj )
radius
(1)
One of the contributions in this study is an adaptive
weighting scheme for balancing preferences, popularity and
location. Let α , β and γ be the weighting parameters or degrees
of influence played by the preference, popularity and
location matching, respectively. Without loss of generality,
α , β, γ ∈ [
The influence of α , which refers to the user preferences on food-drink types, should rely on the size of the user’s purchase history, i.e. the number of deals previously consumed. Users with a longer history have more accurately built preferences Pi than (cold) users with a short history, hence α should be higher in the former case. For users with no purchase history, e.g. first-time visitors to a city, for instance), preference information in Pi should be disregarded by setting α = 0. Inspired by fuzzy set theory, we achieve this by setting α ∈ [0, αmax ], 0 < αmax < 1, such that α increases as the user history grows. (3) (4) from the restaurant-related data. For the contextual information, location data and time are inferred by retrieving the temporal information associated to the last purchased deal (test data). Finally, we consider k = 10 for the size of the recommendation list.
Evaluation Metrics. We recommend the top-k matching ofers to the target user and investigate the predictive power exhibited by the model in recommending the (removed) latest deal purchased by each user, or the restaurant which ofered it. For this end, the performance evaluation metrics employed are adapted versions of average recall@k and average NDCG@k on all users, thereby predicting the appearance of each user’s latest deal or visited restaurant in her history in the recommendation list. The average recall is: Í
ui ∈U yi |U | 1 if last deal consumer by ui is among top-k, yi = 21 if last restaurant visited by ui is among top-k, 0 otherwise.
Average Normalised Discounted Cumulative Gain at k: Íui ∈U N DCG@ki
The influence of β relies on the amount of ratings received by the restaurant associated to xj . If rxj has more customer ratings, β should be higher under the premise that frequently rated restaurants have more reliable (less biased) popularity information, and vice versa. Likewise, for a new restaurant with no ratings, we set β = 0. Using a similar principle as the one for α , we set β ∈ [0, βmax ], 0 < βmax < 1 − αmax .
The influence of γ , which refers to the proximity between user and venue, is (without losing generality) determined upon the other two parameters, as γ = 1 − (α + β). In other words, distance becomes more relevant if ui has a smaller purchase history or rxj has less customer ratings. If both α and β = 0, the filtering process between a cold user and a deal ofered by an unrated restaurant becomes purely locationbased, γ = 1. 3
This section presents a case study conducted in collaboration with Wriggle, on a real dataset describing restaurants, deals and purchases made by users who used Wriggle in Bristol, Cardif and Brighton. By using the purchase history and user profile, a sensitivity analysis is conducted on our proposed model parameters.
Dataset Description. The anonymised datasets provided by Wriggle contain a history of purchased deals by every user over a period of five years, between 2014 and 2019. Around 305K purchases are logged by 141K users. Also, a total of approximately 11K deals ofered by 2153 restaurants are included in the dataset, with each deal being associated to one or multiple categories, out of a total of 63 categories describing food or drink characteristics/cuisines. There is also data about every user’s profile, including dietary requirements if any (vegetarian, vegan), and restaurant profiles that contain the restaurant’s average popularity based on users’ rating on deals ofered by that restaurant.
Experimental Setting. We filter users who have at least one purchase in the last 5 months of purchase dataset because real location data exists only for that particular period. Then, we split the user history dataset into a training and test set for three major cities, Bristol, Cardif and Brighton, that Wriggle operates currently. We consider three diferent time span settings for the user purchase history: 6 Months, 12 Months and entire history since 2014. We then separate the latest deal with location information purchased by each user into the test set. Users with three or less items in their purchased history have been removed for the purpose of this experiment, leaving a consolidated purchase history of 2043 Users for Bristol, 249 for Cardif and 643 for Brighton. Category information retrieved from deals in the purchase history is used to built preference vector of user Pi for the preference matching. Likewise, the information about restaurant popularity, opening times and location are retrieved k Õ
|U | 2zi,j − 1 j=1 loд2(j + 1) where zi, j = 1 if the last deal consumer by ui is the jth recommended item, zi, j = 0.5 if the restaurant last visited by ui is at the jth recommended item, and zi, j = 0 otherwise. Results and Discussion. Three baseline approaches, and two versions of the proposed model with non-null weights, are considered: Most Popular: Recommend deals based on venue popularity. User-Preference: Recommend deals predicted on preferences over categories in deals.
Location: Recommend deals based on restaurant proximity. Same Weight: Popularity, preferences and context are equally important for every user and restaurant, i.e. α = β = γ . Optimised Weight: It adaptively sets weights as explained in Section 3, with αmax = βmax = 0.3. Both α (resp. β) become maximum when the user history length (resp. restaurant rating count) is greater than five.
Figure 2 summarises the average results obtained by the ifve models, for users in the three cities considered and the three time span settings considered. Despite a more exhaustive validation is needed, the results provide some interesting insights.
The proposed model with optimised weight scheme tends to slightly outperform the version with same weights, in almost all cases, specially when considering a shorter time span (6 months). Whilst this improvement is not significant, it motivates us to investigate how to further improve it by devising more user-adaptive weight optimisation methods in future work. Both two versions of our model generally outperform the three baseline approaches, however a location based recommendation has better predictive power in two of the three cities for the 6-month case. This suggests that most users may have a scarce purchase history in such a short time span, in which case prioritising restaurant proximity might increase the chances for better predictions.
Finally, the fact that the user preference baseline gently improves for longer time spans, suggests that the more purchase history data are available, the more reliable the extracted (implicit) preference information is. 4
This contribution proposes a recommendation model for suggesting restaurant deals to local and visiting users to a city by balancing their food-drink preferences, the popularity of the restaurant, and the context surrounding the user, such as his/her location. A case study has been conducted with real data provided by Wriggle, with insightful results motivating the need for follow-up research on how to optimally balance multiple information sources.
People often visit restaurants in groups whose members
have diverse preferences. Accordingly, future work involves
investigating preference aggregation for consensual group
recommendations [
The authors would like to thank Rob Hall (CEO, Wriggle) and Clement Debiaune (CTO, Wriggle) for incentivising and fostering the collaboration that made this research possible.