In this paper, we summarize our previous work in the eld of event recommendations and give an outlook on future work. We developed a recommender system which implements a hybrid recommendation technique to provide accurate recommendations. A two-week user study showed that our system delivers promising results. Nevertheless, we believe that this approach mainly supports users who are looking for recommendations a long time in advance. Other possible situations in which people could be open for recommendations are more spontaneous, for example, when they are already out exploring the city. We give an overview of aspects which have to be considered fur such spontaneous recommendations on the go and the role of social context in this scenario.
Recommending future events is more di cult than recommending items of other
domains such as movies or points of interest. Events are often unique because
they take place only one-time under the exact same conditions. Visitors cannot
rate the event before it takes place and their ratings are no longer of importance
for other potential visitors when the event is over [
Our previous work presented rst approaches to recommend events but these systems mainly support users who want to receive recommendations a long time in advance, before the actual event takes place. Nevertheless, when talking to selected experts from the event and ticketing industry, we found out that especially young people often decide spontaneously to join events they might like. One important factor in their decision making are the opinions of other important persons like close friends.
During our research in the eld of event recommendations, we developed a mobile, context-aware event recommender system. In this paper, we present the results of our previous research which are the basis for our future work. Our goal is to nd out under which circumstances (e.g., while driving a car or during a sightseeing trip) users are open for joining recommended events spontaneously. After identifying the context for such spontaneous recommendations, we want to optimize them collaboratively, for example, by taking other people nearby or friends' opinions into account. 2
Previous Research Focus and Results
After conducting expert interviews with four selected representatives from the
German event and ticketing industry, we developed our rst event recommender
system. In order to provide accurate recommendations, we implemented a
hybrid recommendation algorithm based on Content-boosted Collaborative
Filtering (CBCF). CBCF is a recommendation technique which uses the output from
a content-based (CB) prediction to generate recommendations in the subsequent
collaborative ltering (CF) phase. Studies show that this combination promises
better recommendations than a pure CB or CF recommender [
The contextual pre- ltering reduces the number of possible recommendations before the actual recommendation process takes place. Events are ltered by a set of context factors we evaluated during the expert interviews like the geographical context, temporal factors and temporarily wanted or unwanted genres. The user can set thresholds like the maximum distance to a venue and if the context of a potential recommendation exceeds this threshold, the corresponding event will not be considered for recommendation.
After excluding events which do not satisfy the context constraints, the CB
prediction phase takes place. For this, we adapt the classical CBCF approach
to the special case of event recommendations. We analyze event attributes rated
by the user in the past in order to estimate ratings for events comprising these
attributes. Based on the expert interviews we conducted, events are mainly
characterized by structured data. This is the reason why we propose a case-based
approach for the CB prediction of ratings, as presented by [
The calculated value is stored in the pseudo user-item rating matrix and used
for the upcoming CF phase. Its goal is to extend the matrix by taking ratings
of other users with similar preferences into account. For this purpose, we apply
a User-Based Nearest Neighbor algorithm [
In the end, the events with the highest value for the user are recommended. Only recommendation with a value of at least 0.5 on a scale from 0 to 1 are considered. Furthermore, we limit the maximum number of recommendations at one request to 10 to avoid overwhelming the user with events.
We implemented the presented algorithm in a real working Android application we developed. A Munich based event and ticketing company provided a dataset with approximately 3700 real events which were used to conduct a two-week user study. During this study, 16 participants tested and rated the recommender system. Overall, they were satis ed with our solution (?: 3.75, : 0.83, on a scale from 1 to 5 with 5 representing the best possible rating). The recommendations met their expectations slightly above average (?: 3.38, : 0.60) and the study shows that they can be called su ciently diversi ed (?: 3.63, : 1.05). A majority of the participants, 87.5%, mentioned that they would like to continue using the system to nd interesting events in the future. In general, they were satis ed with the choice of settings which allowed them to modify the context-awareness, for example by de ning thresholds like a radius or possible time slots. Nevertheless, the participants requested further options to modify the context-awareness, for example, the user's current budget for events which was not taken into account as this information was not available in our dataset. 3
Requirements for Spontaneous Event Recommendations on the Go Even though the presented algorithm takes context into account, we believe that the recommender system mainly supports users in receiving recommendations a certain time before the actual event takes place. The developed application can be used at home and the geographical and temporal context settings allow to adapt the recommendations to future conditions. This approach covers a big share of potential visitors but it does not deliver further support for people who are open towards spontaneous event visits. Examples are tourists who visit a city for a few days and have some time left or young people going out in the evening without having any concrete plans.
As a next step in our event recommendation research, we want to focus on
recommendations for events which take place in the same conditions as the
current user context. We call these recommendations spontaneous recommendations
on the go because the events take place shortly after the recommendation is
generated and the venues have to be located in a reasonable distance to the user's
current position. These kinds of recommendations demand the consideration of
additional context factors which were less important in our previous work. For
example, the current weather plays a critical role as bad weather may exclude
some outdoor activities. In addition, the duration of events is critical as, for
example, tourists usually have only a little time for visiting events. The fact that
the user is driving a car or taking the subway could have a signi cant in uence
on the acceptance of recommendations. Sensors in mobile phones area already
precisely enough to determine which means of transportation the user is using
[
Social context is another relevant context factor which should be considered in future work. For example, the user's companions might in uence her or his decisions in regard to spontaneous event visits. Furthermore, our solution could be improved by taking more sophisticated, collaborative methods into account. Instead of regarding all users in the user-item rating matrix, only friends or people nearby could be considered in some situations.
The goal of our research now is to identify all relevant context factors for spontaneous recommendations on the go and to understand which kinds of event recommendations are desirable under which circumstances. We want to implement the new algorithm in another prototype and test it again in a larger user study. The results of this study then can be compared to our previous results in order to measure the algorithm's performance.