If It’s Convenient: Leveraging Context in Peer-to-Peer Variable
Service Transaction Recommendations
AFSANEH DORYAB,
Carnegie Mellon UniversityVICTORIA BELLOTTI,
Palo Alto Research CenterALAAEDDINE YOUSFI,
Hasso Plattner InstituteSHUOBI WU,
Carnegie Mellon UniversityJOHN M. CARROLL,
Penn State UniversityANIND K. DEY,
Carnegie Mellon UniversityPeer-to-Peer Variable Service Transaction (P2P-VST) systems enable people to offer and receive help with a wide range of task types. However, such services are hampered by the difficulty of finding relevant and convenient opportunities for transactions in a timely fashion. Many transaction opportunities are missed as a consequence of members not being aware of offers and/or requests from people nearby oren routethat match their needs and/or abilities. In this paper, we explore
the impact of context-awareness on P2P-VSTs to address this problem. Using mobile technology and anin situstudy, we
evaluate how recommending service requests targeted at a person’s context impacts their willingness to enter a transaction. Our results show that, even when people have not actively volunteered for a service, they are significantly more likely to accept a transaction opportunity if it is convenient for them in terms of time and location. These findings demonstrate how context-aware technology holds the promise of increasing the efficiency and activity level in P2P-VST systems.
CCS Concepts: •Human-centered computing→Collaborative and social computing;Ubiquitous and mobile
com-puting; Social recommendation; Empirical studies in collaborative and social computing; Empirical studies in ubiquitous and mobile computing;
Additional Key Words and Phrases: Context-aware Computing, Peer-to-Peer Systems, Sharing Economy, Experience Sampling Method, Matching and Recommendation, Data Analytics
ACMReferenceformat:
AfsanehDoryab,VictoriaBellotti,AlaaeddineYousfi,ShuobiWu,JohnM.Carroll,andAnindK.Dey.2017.IfIt’sConvenient: LeveragingContextinPeer-to-PeerVariableServiceTransactionRecommendations.Proc.ACMInteract.Mob.Wearable UbiquitousTechnol.1,3,Article48(September2017),28pages.
%0*http://doi.org/10.1145/3130913
ThisworkissupportedbytheNationalScienceFoundationundergrant1407630.
Authors’addresses:A.Doryab,S.WuandA.Dey,Human-ComputerInteractionInstitute,CarnegieMellonUniversity,Pittsburgh,PA, US;emails:{adoryab,anind}@cs.cmu.edu,[email protected];V.Bellotti,PaloAltoResearchCenter,PaloAlto,CA,US;email: [email protected];A.Yousfi,HassoPlattnerInstitute,UniversityofPotsdam,Potsdam,Germany;email:[email protected];J.Carroll, PennStateUniversity,StateCollege,PA,US;email:[email protected].
Permissiontomakedigitalorhardcopiesofallorpartofthisworkforpersonalorclassroomuseisgrantedwithoutfeeprovidedthat copiesarenotmadeordistributedforprofito rc ommerciala dvantagea ndt hatc opiesb eart hisn oticea ndt hef ullc itationo nt hefirst page.CopyrightsforcomponentsofthisworkownedbyothersthanACMmustbehonored.Abstractingwithcreditispermitted.Tocopy otherwise,orrepublish,topostonserversortoredistributetolists,requirespriorspecificpermissionand/orafee.Requestpermissionsfrom [email protected].
©2017AssociationforComputingMachinery. 2474-9567/2017/9-ART48$15.00
1
INTRODUCTION
Peer-to-peer (P2P) exchange marketplaces are becoming important contributors to our modern economy and lifestyle. The size and scale of services such as Uber and Airbnb have surpassed some of the largest businesses in transportation and hospitality1. Novel services such as Taskrabbit, Wyzant, Freecycle, NeighborFavors, and Couchsurfing provide opportunities for people to share skills, information, assets or living spaces with each other in a way that unleashes value from existing resources. People can now provide support to each other directly via a P2P platform, which provides the means of easily locating and contracting with the desired resource.
The focus of the research reported in this paper is P2Pservice transactionsystems (P2P-ST systems). P2P-ST systems include transportation or task services such as Uber, Taskrabbit and timebanks (in timebanks [6, 8, 13, 53], people provide services to each other in exchange for time dollars, an alternative currency) and they are interesting to us, as context-aware computing researchers, because theyare context-sensitive. Firstly, they usually rely on thetimely coordination of the provider and the recipientof the service, because both partners usually have to be presentat the same time and placeto facilitate the service transaction (e.g.,to hand off the dog to be walked) [12, 14]. Secondly, the services themselves are usually context-sensitive,involving a desired time-range and a place or places(e.g.,clean my garage tomorrow) and so a positive response from a provider is contingent on the convenience of the service’s required time and place for that provider, given his/her own current or future context.
We are interested in developing technology to support P2P-ST platforms that facilitatevariabletypes of service (e.g.,transportationandpet careandshopping) because a key challenge to such platforms is theappropriateness of transaction opportunitiesthey provide. We believe that context-aware technology can be developed to help requestors get what they need and providers to find people who want what they can offer, without imposing too much of a burden by requiring them to go far out of their way to perform a service. It can also address the challenge oftimeliness of service, by finding providers who can respond promptly to posted requests, rather than requestors having to wait in uncertainty for a transaction partner to commit.
In most current commercial P2P-ST systems, most users only receive services and the remainder (micro-entrepreneurs) mainly or only act as service providers, making their participation in the P2P system a kind of occupation (for example as an Uber/Lyft driver or a Taskrabbit Tasker). We, however, are interested in the opportunity to connecttrue peersto each other; ’true peers’ meaning the intention is for everyone to provideand receive services regularly as do, for example, Scoop or Waze carpool service participants. But, as mentioned above, we are especially interested in platforms wherevariabletypes of services are offered, since they require matching people not only on time and place, but also on abilities and needs; this type of service includes timebanks (two timebanking networks, hOurworld and TimeRepublik have over 70,000 users between them who could benefit from our work; there are many more timebanks in other networks distributed all over the world [52]).
The critical challenge fortruepeer-to-peervariableservice transaction(P2P-VST) systems is that non-specialist-provider users must be given transaction opportunities that match their abilitiesandthat are convenient for them to satisfy without too much of a detour, since they are not earning a living from the service and have other things to do in their busy lives. With thestatus quoin current service exchanges, to take advantage of context, users would have to constantly browse postings to find convenient service requests. This is because their context is constantly changing, so transaction opportunities are convenient only at certain times and places. The near-impossibility of finding convenient transaction opportunities may help explain why many requests for services in timebanks go unanswered, a serious cause of frustration and disillusionment [53].
To promote service exchange among P2P-VST service users, we have been developing context-aware technology that canautomatically identify opportunities for variable types of transactions to occur at the right time and place, without requiring users to actively ask/wait for them. Our users getproactive(prompted by the system not
requested by the user) recommendations, even if they have not previously posted any transaction requests or offers. They get a recommendation because their current or future context and/or information in their profile is compatible with the transaction opportunity.
In this paper, we present anin situstudy to demonstratethe impact of contextual targeting of transaction recommendations on how users rate the convenience of providing services and how likely they are to accept the transaction in the requested context. In our study, we focus onpotential service providersrather than receivers because the convenience of satisfying a service request is especially context-sensitive; that is, needs (unlike abilities) often crop up in-the-moment (e.g.,I need someone to repair my bicycle tonight,versusI can repair bicycles) and tend to coincide with the context (and convenience) of the one who has the need. But providers must consider the differences between their own current and future contextandthe context in which the service is required (the amount of inconvenience). However, despite our focus on providers for the purposes of this paper, our system is capable of making recommendations to both providers and receivers.
A previous desk-based study, where users assessed match recommendations from their personal computer, [33] showed howstaticmatching, based on analyzing users’ (relatively static) profiles, significantly improved subjective assessments of the goodness of transaction recommendations. By contrast, we present a mobile study that shows how users are amenable to proactive recommendations on their mobile phone and howdynamic (changing) context-awareness increases subjective ratings of the convenience and likelihood of providing a service.
Our novel contributions are as follows:
(1) We show how context detection and predictive modeling can be used to increase the time-sensitivity and convenience of recommendations for variable service transactions and show that this increases the subjectively assessed likelihood of entering a service transaction compared to static profile-based matching, of the type described in [33].
(2) We show that people rate themselves as more willing to perform services, if requests come at the right time and place, even if they have not actively volunteered for that type of service. We will describe how this finding can greatly lower the barriers to participation since providers do not have to post offers and people in need do not have to browse offers.
(3) We report on the relative importance of contextual parameters in a user’s decision to accept a service transaction, and discuss the implications of our work for the design of future proactive context-aware P2P-VST systems.
In the following sections, we review related work on P2P transaction systems, context-aware computing and matching systems. We then describe our study methods and findings.
2
BACKGROUND AND RELATED WORK
2.1
Peer-to-Peer Transaction Systems
Peer-to-peer transaction systems (P2P-Ts) include any services where individuals can find others to engage in transactions (usually one-off) where goods or services are exchanged [11]. Starting in the late 2000’s a rapid upsurge of computer-mediated P2P-T services eventually began to be referred to in the press as the Sharing Economy2,Collaborative Consumption[5, 10] or theGig Economy[21]. An ideal vaunted by this popular movement is that sharing can reduce consumption and so increase efficiency and sustainability of economic activity [10, 11, 45]. However, this ideal may be far more salient to the platform providers than to their users, who are more attracted to instrumental benefits and a more social experience than conventional services provide [8]. Further, the movement and its disruptions to traditional businesses have attracted criticisms, particularly
associated with the service transaction platforms (P2P-STs, notably Uber and Lyft) for introducing job insecurity and questionable employment practices [57].
Notwithstanding the criticisms, the rapid rise of this new more sustainable economic model makes it an appealing target for technology to increase its efficiency and competitiveness [7]. As mentioned, we have focused on P2Pservicetransaction systems (P2P-STs), because they are more technically challenging, and would benefit more from the capacity for tight coordination of service providers and receivers. We have further focused on variable service transaction systems (P2P-VSTs) because not only is tight coordination required, but also skills or abilities must be considered when creating matches. Our target user community has mostly come from timebanks because they are true peer-to-peer systems, whereall membersof a timebank reallyare equal peers, able to both provide and receive services. In this study, however, we extend our user population to non-timebankers to evaluate the general effect of proactive context-aware recommendation in entering service transactions.
2.1.1 Timebanking: A True Peer-to-Peer Variable Service Transaction System. In a modern timebank, members use a web application to post offers and requests for services and pay for services with time dollars, which are banked in the website [16]. However, the concept of timebanking goes back almost 200 years [7], with paper scrip being used to document transactions in early incarnations such as the ’Cincinnati Time Store’ established and run by Josiah Warren in the US from 1827 to 1830.
In recent research, Collomet al.[17] showed that timebanking enhances the social ties within communities by prompting people to feel grateful to one another. They demonstrated that timebanking promoted physical health and sense of belonging, particularly among older and lower-income persons, and people who live alone. Collom [16], also found that timebanking makes the elderly more active. In 2010, Knappet al.[36] estimated savings from timebanking to the UK’s National Healthcare Service at an average of 850 pounds per member per year. Ozanne [45] studied timebanking within an affluent community and concluded that its benefits go far beyond money, with members enjoying extending their connections, range of opportunities and increasing trust. Seyfang [50, 51] lists many benefits such as self-esteem, development of friendships and being more involved in the community. VÃąlek and JasÃŋkovÃą found that timebanking brings satisfaction to individuals about the work they do and makes them feel good about doing it [56].
Beyond these benefits, timebanks epitomize the idealistic values of the sharing economy or collaborative consumption movement because of their focus on tapping into private (individual) and often underutilized community resources for the wellbeing of the community, without recourse to the conventional professionalized economy for needed services [37, 50]. As well, timebanking can open up new opportunities for people to enrich their lifestyles and live up to their values through these more informal, local and sociable economic exchanges [23].
However, the currency-and-banking metaphor has a number of shortcomings that can get in the way of altruistic community-enriching activity [7], and local currencies in general have been critiqued as unlikely to succeed as currently conceived [20]. For example, a key ideal of timebanking that all community members are valued equally [12, 13, 17, 29], is also an economic impediment in that all individuals must work on the same time-based compensation scale (one time dollar per hour), regardless of the true economic value of their labor. This means that, for the most part,higher-skilled services are in short supply in timebanks[20, 53].
2.2
Context-aware Computing
Context-awareness - a system’s ability to adapt its behavior in response to a user’s changing context - has been intensively studied over the past 20 years (e.g.,[2, 18, 22]). Significant effort has gone into tools for building aware applications, and implementation of such applications. However, the application of context-awareness to recommender systems is relatively new. The main challenge in context-aware systems is to identify what information is contextually relevant for the user [18]. Depending on the application, relevant context can
be one or a combination of different factors. For example, in a social context-aware system, a person’s mood is a significant contextual factor in indicating whether the system should initiate a social introduction [42], whereas in a context-aware city guide application, location is a more useful contextual trigger [7].
2.3
Matching and Recommenders
Despite, and partly because of, the shortcomings of timebanks, we propose that lowering the effort associated with the exchange of services by giving contextually targeted recommendations of service receivers to providers for whom a service is minimally inconvenient should make timebanking or similar P2P-VST systems more practical. By making variable transaction opportunities easy to find and making those transactions easier to execute, we may be able to ameliorate the skill shortage problem noted above. For example, spending less time on tasks would make compensation far less of an issue. Also, shorter time requirements for services would allow skilled but busy people, whose spare time is extremely precious, to perform services for others and enjoy the psychological benefits that come from helping others [40]. Making recommendations for transactions could also reduce the stigma of asking for help by framing the transaction opportunity discovery experience as a successful match between people whowant to transact on both sides of the service equation.
2.3.1 Profile-Based Matching.One of the ways to match providers and receivers is to analyze online profile information to determine if they havesimilar interests. But matching of timebankers or members of other true peer-to-peer variable service transaction systems also requires us to determine if theirabilitiesandneedsare complementary; that is, that their social connection will have high value because each one’s abilities match the other’s needs. Junget al.[33] investigated matching timebankers to each other by analyzing their profiles. They designed an algorithm specifically tailored towards satisfying the reciprocity rule [56], which is currently an obstacle in timebanking; specifically, if A performs a service for B, B would prefer to be able to provide a service for A. In other words, B would prefer to reciprocate in kind, regardless of paying with time dollars [8]. Junget al.’s algorithm analyzed profiles by classifying text in timebankers’ offers and requests in terms of the offer/request category label and then used that to classify text in timebankers’ profiles. This classification significantly improved users’ ratings of the goodness of the match of recommended timebankers to transact with. A variety of other application domains for profile-based matching have been explored. In online dating (e.g., Match, OKCupid, Tinder) [27, 28] and reciprocal recommender systems [19, 39, 47], users can express their preferences for a matched user. Similarly, in talent-matching systems (e.g.,space, Jobscan.co, Taskrabbit), users (job seekers and recruiters) are matched on their preferences for each other [39, 41]. In expertise-seeking systems [4, 25, 48, 58], users are matched to individuals who have the expertise that meets their requirements. Expertise in all of these applications is generally inferred from text that individuals or institutions have entered into a system in online profiles or forms, and so on.
2.3.2 Location- and Proximity-based Matching.In contrast to a taxi or Uber or Lyft or Postmates, where the driver’s task is simply to drive, in true peer-to-peer ridesharing (where everyone can be a driver or passenger), the driver already has a personal destination in mind, so matching should take this into account to minimize the driver’s detour. A simple method is to create matches using explicit user departure and destination location, and timing specification (e.g.,[15, 30, 58]). Somewhat more advanced is the idea of tracking drivers (who have signed up to give rides) in real time as they drive, to find another match if the best initially matched volunteer driver gets stuck in traffic (e.g.,[44]).
The closest approach to our preferred method is the idea of modeling travel patterns in general to match potential riders and drivers (e.g.,[1, 38, 59]). However, in addition to a different technical approach, our modeling of daily travel and location patterns goes beyond ridesharing and is used topredictpeople’savailabilityand convenienceto opportunistically perform different types ofservice transactions(including transportation and
delivery) in anear future context(time and location) as desired by transaction partners. We seek to lower the effort of volunteering to perform tasks that would present a barrier to busy individuals. Whereas prospective rideshareparticipants are motivated to find a partner to share the cost of driving,service providershave no such motivation for signaling their availability everywhere they go, just in case their services are needed - having to do so would be perceived as a burden.
Another similar line of work to ours is mobile crowdsourcing (also called physical crowdsourcing) where individual workers opportunistically view and perform tasks based on their proximity to a certain location [3, 34, 35]. The widely-used scenario for mobile crowdsourcing is collection of information about the physical environment, the so-called participatory sensing where individuals report on conditions in the environment (e.g.,the temperature or pollution level). For example, Creekwatch3uses the location of participating workers to acquire watershed measurements. Companies such as Gigwalk4, and FieldAgent5, match the crowd, based on their location, to help consumer businesses with, for example, checking whether their products are stocked correctly. Favor6provides food-delivery and all-purpose courier services using the crowd. In all of these services, the user identifies tasks to perform by browsing the entire list of tasks close to their current location. No prediction of routes or activities is performed.
Ta$ker [34] and on-the-go crowdsourcing [35] explored both opportunistic and proactive notifications of tasks in mobile crowdsourcing. On-the-go [35] studied the effects of notification policies on participation and task completion in package delivery and lost-and-found scenarios. They showed that at-location notifications increased the task pickup rate compared to in-range notifications. Ta$ker [34], a recent prototype studying campus-scale mobile crowdsourcing, is closest to our approach with route prediction and a push mechanism to match tasks to workers, based on their predicted movement patterns. A study of Ta$ker found that pushing matches to workers increased the task completion rate compared to the pulling condition where workers manually pulled the list of nearby tasks. Community Reminder [49] used crowdsourcing to deliver safety relevant information in local communities by allowing community members to create contextual reminders for other members in the community. A filed study of the system showed that involving community members and delivering contextual reminders can broaden participation in local communities. The findings in Community Reminder and Ta$ker are aligned with our results discussed later in the Results section. However, Community Reminder focuses on information delivery (not service exchange) and Ta$ker, studies a set of easy and quick micro-tasks with specific outcome measures (e.g.,whether the library is too cold at a certain time of day) to collect data, as is the general goal in crowdsourcing. Therefore, in such systems, physical proximity to the location of tasks is the predominant indicator of task acceptance and completion.
In proactive P2P-VST recommendation, however, the requested services range from simple tasks (e.g.,delivery) to more complex skilled-oriented services (e.g.,tutoring) where skills, preferences, and other situational factors may be just as influential on task acceptance and outcome as location proximity. It is, therefore, important to compare the impact of different factors to understand the degree to which each contributes to successful service transactions in P2P service exchangebeforethe actual implementation of the system. In the rest of this paper, we provide evidence that profile and preferences play a major role in users’ decisions to enter service transactions, but contextual convenience makes people accept transactions even if they don’t match their preferences.
Various mobile and sensor-based applications have used physical and geographical proximity to connect and match people mostly for social relationships. Early applications such as Nokia Sensor [46] and Serendipity [24] used a Bluetooth sensor and profile similarity to introduce people in close proximity and in a certain social context to each other. ActiveMap [43] used indoor location tracking to encourage informal and opportunistic
3https://www.scientificamerican.com/citizen-science/creek-watch/ 4http://www.gigwalk.com/
5http://www.fieldagent.net/ 6https://favordelivery.com/
interactions between co-workers. Similarly, Social Net [55] introduced people in close proximity to each other using a friend they had in common. Other applications use proximity to form social groups based on similarity and preferences (e.g.,Flocks [9] and Smart-Its Friends [31]).
Mayer et. al. [42] explored’the design of opportunistic social matching systems that introduce people proactively without a specific user query or explicit user goal, but instead when the opportunity arises’. A mobile experience sampling method was used to understand matching interests of users in a social context. The motivation of this work is similar to ours in the sense that it seeks to use context to proactively introduce people without an explicit query. However, while initiating connections in a social context is more about people’s similar interests in that current context, our proactive context-aware approach is targeted towards connecting potential transaction partners based on both their service preferences and their abilities in changing contexts.
We now describe our own work in which we combine skills, abilities, and preferred services in a user’s profile, her current location and her predicted locations in peer-to-peer variable service transaction partner matching to understand the impact of each factor in people’s decision to enter service transactions. The following describes the design of anin situstudy to measure the impact of those factors in facilitating service transactions.
3
IN SITU
STUDY DESIGN
Our goal is to demonstrate the effect ofcontextually targeted, and therefore more convenient, transaction recommen-dationson thewillingness of service providersto provide a service. To achieve this, we designed anin situstudy to collect contextual information about people and to recommend relevant service transaction opportunities. Byin situstudy we mean anexperimentconducted in areal-world setting, allowing us to collect data from real contexts. However, we control when and what transaction recommendations, to send to participants, in order to get data about the impact of context on receptivity to a broad range of transaction opportunity recommendations whose match-worthiness and timing we manipulate.
Our hypothesis is that people are more likely to accept a transaction opportunity if it is convenient for them in terms of time, location, and availability. As mentioned above, many P2P-VST service opportunities are missed as a consequence of members not being aware of those that match their needs and/or abilities. We therefore aim to evaluate how introducing transaction opportunities with different levels of contextual convenience impacts people’s willingness to enter a transaction.
The following describes the technical steps we undertook to prepare for the study.
3.1
Sensing and Data Collection
The context of the user and her circumstances can be inferred from data about the user or the environment. Although the sharing economy can make use of all sources of information to provide better matches and recommendations, in proactive context-aware P2P service transactions,locationandtimeplay crucial roles. Smartphones provide the ability to track daily patterns of users and their environment/situation with their rich set of sensors and communication channels. We therefore use the Aware framework [26] on both Android and iOS mobile phones to collect timestamped location traces of people. The Aware client app runs in the background and uploads data regularly to a server. We chose to collect location data every 3 minutes as a tradeoff between phone battery life and having up-to-date location information.
3.2
Learning Daily Patterns
Although GPS coordinates allow for fine-grained estimation of a user’s location, they need to be processed in order to provide useful information about a user’s daily activity patterns. For our study, we developed algorithms to extract the patterns of people’ssignificant locations, places of interest and frequent routes. These daily patterns helped detect current- and predict future-context of the user.
Table 1. Categories and subcategories of service types
Category Sub-categories Examples
I am looking for a fellow who can take me to my yoga class.
I don't have any transportations and would like to have someone running errands together Could you please pick up a small package from the post office on your way?
Can someone get me a bottle of wine and do a delivery? I am planning a nice dinner with my husband. I am primarily seeking sweet red wine or other sweet full-bodied and potentially alternative fruit like blackberry. Small winery and/or homemade wine is also fine. Thank you!
I have a health appointment that I need to go to but I don't have the mobiliy at the moment. Can someone help?
I am looking for someone to assist me doing some hauling. We are scheduled to move at the end of month and I would love to move my furniture.
I need some help cleaning my house. You can clean on your own if you prefer or we can arrange a time to divide and conquer the mess.
We are looking for volunteers that would be willing to give an hour or two to a senior in need of basic care or companionship.
Are you a dog-lover? I need occasional dog-sitting for my cute 7-year small dog. She is half- Yorky and half chihuahua. Preferably one-on-one with just her or if you have a small dog that is mellow. I am trying to make a documentary about the local culture and people who live here. I don't have any particular requirement for the subjects. I would love to talk to anyone who is interested
Can someone help me with setting up a website?
My daughter wants to learn how to draw and paint. Would you be able to teach her?
Two dimmer switches need replaced. I recently have some mobility issue otherwise I would do it myself.
Some of our old chairs keep falling off and I would like someone to help my repair them
My mom doesn't really know how to bake and doesn t like me eating too many sweets. I would like someone to bake for me or with me.
Need someone to come cook with me. Are there any takers for my request? You can tell the what ingredients you may need.
1. Transportation task
2. Domestic, low-skill
3. Knowledge work
4. DIY skill
Ridesharing, Rides to grocery store, Rides to health appointment, Pickup and delivery meals and beverages, Pickup and delivery package, Other errand rides, Purchase and delivery groceries, Purchase and delivery meals and beverages
Moving assistance, House cleaning, Gardening, Elderly help, Dog walking, Pet sitting, Baby sitting
Information advice, Tutoring
Furniture repair, Bike repair, Car repair, Cooking/baking
Ideally, a proactive context-aware solution would use knowledge of what activities a potential service provider and someone in need are performing in the near future to identify variable service transaction (VST) opportunities (for example, if someone is going to go grocery shopping in an hour, she could easily shop for another person at the same time). In this study, we focus on learning only a subset of daily patterns, both due to the short period of study and the fact that learning certain routine activities (e.g.,cooking or cleaning) requires additional equipment (e.g.,wearable and embedded sensors in users’ homes). We do, however, extract users’availabilityto provide services (see feature extraction section ahead).
3.3
Transaction Matching: Experimental Manipulations
Although some service categories are more context-sensitive (e.g.,ridesharing, which is dependent on both place and time) than others (e.g.,gardening, which is mainly dependent on place), most services might benefit from being recommended to potential providers at the most opportune/convenient situation to increase the chance of being seen and fulfilled. As mentioned, providers are more context-sensitive than receivers, since the place and possibly specified time of a request are more likely to match the receiver’s context by default (e.g.,a ride request is usually specified to be convenient for the receiver), so providers must be concerned with both their own and the service’s context, which will not always be compatible. In our study, we were interested in the following questions:
• What personal factors facilitate transactions?
• How does contextual convenience affect the likelihood of entering a transaction when the requested service category is or is not one that one has expressed a preference for providing?
Table 2. Samples of profile descriptions used in the study
Profile Description
Besides practicing law for 28 years I have taught from third grade through university levels
We are a local organization that helps build senior networks. We regularly organize events, offer helps to seniors in groceries and transportation, etc. I am a certified licensed massage therapist with a passion for helping people get out of pain
I love the outdoor hiking and walking with my dog
I am a certified licensed massage therapist with a passion for helping people get out of pain
I am a event planner and coordinator. I love traveling and helping out with community projects.
A hiker and software engineer
I am a master student in psychology. I like to socialize and meet new people I am a parent of 2 children. I am involved in church and bible study. I am an active member in my community helping people, especially elderlies. I have work experience as a small business owner operator We are local farmers. We grow organic vegetables. I am a senior living alone
I like doing photography and creative stuff on computer. Also a cat lover I have been in this area for over 30 years. I run an organization that helps connect elderly communities.
To address these, we varied our service request recommendations such that they were more or less matched to the participant’sprofileand orsensedcurrent andpredictedfuture context at the time of delivery. We created the following types of matching:
(1) Profile-only match(P) – requests were only matched withprofile(service category preferences) of the transaction partners without considering their current or future context. Profile matching was performed by matching the service request category (timebank requests are always categorized by requestors) to the preferred service categories in each participant’s profile, which was created at the start of our experiment. (2) Context-only match(C) – requests were only matched with sensedcurrentor predictedfuture contextof
the transaction partners without considering their profile. Contextual matching was performed by taking records of users’ movements over time to build a probabilistic model of where they were most likely to be and to be going at any given time of day and day of the week. Based on the model, we added a nearby location and time to the request description that was sent to the participant.
(3) Profile and Context match(P&C) – requests were matched withbothprofile (service category prefer-ences) and sensed current or predicted future context of the transaction partners.
We generated 334 unique experimental service requests using the service categories in Table 1. Some requests and profiles were real anonymized examples taken from the hOurworld Timebank and others were generated to cover the service preferences of the study population, taken from initial survey responses (described in the next section). We then customized each with a requestor profile (from a set of 122 fake user profiles that we created) and a contextual situation (time and place specific or not) depending on the matching type (P, C, or P&C above) being used. Examples of requests and profiles are listed in Table 1 and 2.
Those services that needed to be performed in a participant’s sensedcurrent contextwere personalized with a nearby location based on real-time logging (from sensing) of the participant’s location. For example, the customized version of the request ’Anyone available to give me a ride home?’ would be ’Anyone available to give
Table 3. Format of experience sampling survey page that participants used to rate recommended transactions. Bold italics are features used in our analysis and Figure 3.
me a ride home? I’m at the corner of Ash St. and Grange St.’ to a participant who was currently sensed as being located within half a mile of that corner.
Other services that should be performed in a participant’sfuture contextwere customized with a time and a location close to the participant’s predicted location at that time,learnedfrom participants’ daily movements over time. For example, we would send the request ’I need to go grocery shopping this evening sometime after 6pm and would appreciate a ride. I live half a mile from South Park.’ to a participant who, according to our model, would be near South Park around 6pm.
Table 3 shows the Experience Sampling Survey (ESS) items that a participant received with each service request recommendation (comprising task description and requestor profile). Participants,did not perform the tasks, but justrated requestsin terms of how well they matched their profile in terms of ESS-sampled Abilities/Preference Level (ESS-APL), their sensed and inferred context, and willingness to accept the request. Since the focus of this experiment was to measure the impact of profile and context rather than to estimate task completion rate, each of our experimental service requests were only recommended to one participant. In a real system, a request would be sent to a list of the best-matching participants who might be offered the task to ensure that someone did accept it. As we used up all our experimental service requests over time, we reused them with new customized contextual parameters (time and place). However, we made sure nobody received the same request more than once.
3.4
Recruitment and Participants
We recruited participants by advertising on our university campus, a local advertisement website, and several timebank portals and encouraged word-of-mouth advertising. Interested volunteers contacted the research team to be screened for eligibility. They were enrolled in the study if they were at least 18 and had a smartphone with a data plan. The timebankers were recruited via email from a local subset of the hOurworld timebank network. The non-timebank population mainly consisted of students and young adults. Other occupations included retail, engineering, social/community work, business, and health. Out of 222 volunteers who signed up (60 timebankers), 123 filled out the initial survey, and 73 (48% male and 52% female) successfully installed the app. We analyzed data
48:11 from all 73, even though only 70 completed the full 5 weeks of the study. The three who did not complete the full study, participated for 2-3 weeks (None of these dropouts was due to battery issues). We excluded people who had technical issues with the data collection software or whose phone model was unable to support the app. All participants were compensated with 20 dollars (US) for each complete week of participation (100 dollars for five weeks). The compensation covered potential overuse of participants’ data plan for real time data upload and extra battery usage (i.e.,inconvenience) during the study. Participants ranged in age from 18 to 60 with 67% between 18-29, 18% between 30-39, and 15% over 40. Although we tried to recruit as many timebankers as possible, only one in six who signed up were enrolled in the study (11 out of 60) mainly due to various technical problems, such as having an older phone or not understanding how to install our app; this mainly reflects the older, and so presumably less ’tech-savvy’ demographic of the timebanking population compared to the other populations.
4
IN SITU
STUDY PROCEDURE
4.1
Service Provider Profiling Survey
Prior to receiving recommendations, all participants filled out an initial profiling survey including demographics, their daily activity patterns, their transaction preferences in terms of locations and acceptable detour distance and duration, as well as a profile including subjective ratings ofability/preference levelfor each sub-category (Prior Ability/Preference Level; P-APL, not to be confused with the ESS-APL introduced above; see Figure 2) of services they felt able to provide (for matching with the profile of a service requester, which we termprofile match). P-APL was collected as a baseline to measure participants’ perceived skill level in each category to be compared to ESS-APL, the actual subjective measure of skills for a particular request (See Table 5). This information was used to prepare matching service requests for participants. For example, if a person chose to offer services in the transportation and knowledge work categories, we prepared request services/recommendations for those (category 1 and 3 as shown in Table 1; transportation [e.g.,ridesharing or delivery] and/or knowledge work [e.g., proofreading]).
In the profiling survey, participants indicated preferences for service requests as follows: 71% preferred transactions within one mile of their location and 75% preferred tasks requiring less than an hour. Sixty-eight percent (68%) expressed apreferencefor transacting with nearby people, 7% wouldonlytransact with people nearby and 37% had no preference in this regard. Forty-seven percent (47%) of participants did not express any preference with respect to skills, abilities, and interests, 26% preferred complementary skills and abilities, and another 26% preferred similar interests to their own. Figure 1 shows participant preferences formaximum detour distanceandmaximum service duration, indicating that transactions are rated as more likely to be completed for services that are a short distance away and that do not take too much time, like picking up groceries or returning a borrowed tool.
4.1.1 Timebank Members vs. Non-timebankers. We also compared responses between our timebank members (n=11) and non-timebankers (n=62) to see how timebanker preferences and behaviors were different from the general population (Figure 1). Timebankers’ preferences in terms of detour and maximum service duration were more flexible than non-timebankers,i.e.,timebankers were more willing to take longer detours (more than ten miles) and engage in tasks that take up to two hours to complete. These observations are not surprising since the timebankers are a self-selected population of people who want to engage in service transactions with others.
4.1.2 Participants’ Response to Privacy, Trust, and Safety Concerns.Although helping and sharing is the overall goal of P2P-VST services, privacy and safety concerns in using such services should not prove to be an insurmountable obstacle. As shown in Table 4, most of our participants were comfortable with having their profile and daily activity tracked and analyzed for the purpose of more targetedin siturecommendations and this is consistent with the findings of Junget al., [33], which showed most of their study participants were unconcerned
Fig. 1. Participant preferences for task time and distance requirements
about having their profile analyzed for the purpose of matching them to transaction partners. Yet, in both our own and Junget al.’s study, some participants were somewhat concerned about privacy and what a context-aware app might collect and infer about them. Future work must mitigate such concerns with design features such as user controls and feedback.
4.1.3 Context Dependency of Service Categories.We also asked participants to rate the level of context dependence for each service category (Figure 2). Our participants (on average), for all of the service categories we used, slightly agreed with the assertion that the service categories were context-dependent (on a scale of 1=strongly
48:13
Table 4. Participants response to concerns about data collection and inferring their daily patterns and preferences.
ϭс^ƚƌŽŶŐůLJ ĚŝƐĂŐƌĞĞƚŽ ϳс^ƚƌŽŶŐůLJ ĂŐƌĞĞ K<ǁŝƚŚŚĂǀŝŶŐŵLJ ƉƌŽĨŝůĞĂŶĚ ƉƌĞĨĞƌĞŶĐĞƐ ĂŶĂůLJnjĞĚ K<ǁŝƚŚŚĂǀŝŶŐŵLJ ůŽĐĂƚŝŽŶƐĂŶĚ ĂĐƚŝǀŝƚŝĞƐƚƌĂĐŬĞĚ ĂŶĚĂŶĂůLJnjĞĚ ,ĂǀĞƉƌŝǀĂĐLJ ĐŽŶĐĞƌŶƐĂďŽƵƚ ĐŽůůĞĐƚŝŽŶĂŶĚ ŝŶĨĞƌĞŶĐĞŽĨŵLJ ĚĂƚĂ ϭ Ϭ ͘Ϭ ϭ Ϭ ͘Ϭ ϯ Ϭ ͘Ϭ ϵ Ϯ Ϭ͘Ϭϳ Ϭ͘ϭϬ Ϭ͘ϭϯ ϯ Ϭ ͘Ϭ ϵ Ϭ ͘ϭϰ Ϭ ͘ϭϯ ϰ Ϭ͘ϭϭ Ϭ͘ϭϬ Ϭ͘ϮϬ ϱ Ϭ͘ϮϬ Ϭ͘Ϯϲ Ϭ͘Ϯϯ ϲ Ϭ ͘ϯϵ Ϭ ͘Ϯϳ Ϭ ͘ϭϰ ϳ Ϭ͘ϭϯ Ϭ͘ϭϬ Ϭ͘Ϭϵ
disagree to 7=strongly agree). They tended to agree most with transportation tasks being context-dependent (Mean = 4.8, StdDev = 1.80) and least for repair and advice tasks (Mean = 4.4, StdDev = 2).
4.2
Receiving Contextually Targeted Recommendation
The study lasted five weeks and participants were compensated with $20 a week, regardless of how many responses they gave us or how they rated the service requests. At the start, they installed the Aware client on their phone to collect their location data for the five weeks of the study. The data was collected at three-minute intervals and continuously uploaded to our server. It was processed on a daily basis to extract and update location and route patterns for each participant.
Each user received three service recommendations (one per matching type; P, C, and P&C) per day at different times throughout the study. Since requests were sensitive to time and location, we wanted participants to notice and respond to requests as soon as they received them, so we sent recommendations via text messages. Eighteen participants were not able to receive our text messages on their phone. So, we sent their recommendations via email as long as they were able to get email on theirmobilephone (in context). During the study, participants responded to 6329 out of 8361 requests (response rate∼75%).
Table 5 shows the distribution of requests in each category and participants’ corresponding responses. On average, 75.5% of requests received a response from the participants, out of which 42.8% were rated as ’acceptable’ (acceptScore>4). ’Gardening,’ ’dog walking,’ and ’proofreading’ had the highest rate of acceptable scores (61-65%) and ’tutoring,’ ’other errand rides’ involving rides of multiple kinds, and ’car repair’ had the lowest rate of acceptable scores (25-28%). This distribution is consistent with common sense expectations, as, for example, ’dog walking’ does not require specific skills or tools, whereas ’tutoring’ requires specific knowledge and abilities. On average, 91% of users responded by rating the requests they received in each category using our experience sampling survey (Table 3). While, on average, only 37.6% of those users had chosen to offer services in that same category (Min=0% in pickup and delivery meals and beverages, Max=100% in ’information advice’, ’tutoring’, and ’proofreading’), on average 66% of users ended up rating requests in that same category as acceptable (∼28% more). For example, furniture repair was the preferred offer category among only 4.2% of the users, but 67.6% of requests in that category were accepted. The requests in the furniture repair category were mostly sent in the context-only match condition since only a small number of users chose this category when indicating their preferences. The fact that the majority of users accepted the requests in this category supports our analysis finding (discussed later) that people are willing to perform tasks if it is convenient for them even if they have not expressed a preference for them.
We also looked at differences in scores between male and female participants. On average, the acceptance score among male participants was slightly higher than females (3.6 vs. 3.3) with the highest difference in bike repair
! " # # $ $ ! $ $ $ $ ! % % ! % & ' ( ) * + *"
Fig. 2. The level of context dependency of service categories and skill match (PAPL) according to participants’ ratings
(female average = 1.4 and male average = 3.4) and moving assistance (female average = 2.4 and male average = 3.8). On the other hand, females slightly favored babysitting (female average =3.7 and male average = 2.9) and dog walking (female average = 4.4 and male average = 4.1).
The averageprior(rated by participants at the start of the study) ability/preference level (P-APL) across all service subcategories was 4.2. The average P-APL for each subcategory indicated by participants who accepted requests was 4.8 (with the lowest average P-APL of 1.3 for car repair and the highest average P-APL of 5.8 for dog walking), whereas this rate fell to 3.9 for those who rejected the requests (accept score<4, with the lowest average P-APL of 1.6 for car repair and the highest average P-APL of 5.3 for elderly care). The comparison between the P-APL and the acceptance rate for each category shows despite the low match between the P-APL and the request category more users rated the services as acceptable in all categories. For example, 35.8% of users in the bike repair category and 51.4% of users in the car repair category rated the service requests as acceptable even though those categories have the lowest P-APL among all categories.
48:15
Table 5. Breakdown of requests. P-APL (2nd to last column) means prior ability/preference level and all values initalicsare percentages of the number of the responses received. Darker color shows higher values and percentages.
5
DATA PROCESSING
We now describe how we processed our data, extracted features, and used them to build conditional inference models to understand and reveal the impact of contextual factors on a participant’s decision about whether to accept service request recommendations.
5.1
Feature Extraction
As mentioned above, we used an experience sampling method to have participants rate recommended requests, based on how well they matched their profile and context (Table 3). We treat each rating item in the survey as a feature to be used in a model of each participant. These features include the participant’s match rating for each of profile (ESS-APL, sub-section 4.2), location, time, and their acceptance rating in relation to each service request.
We calculated the aggregated responses to all experience sampling survey items. Figure 3 shows distributions are grouped towards the tails,i.e.,most responses are either strongly disagree/disagree (score 1 or 2) or agree/strongly agree (score 6 or 7). We therefore chose to transform all scores into binary categories;highMatch(scores greater than 4),lowMatch(scores less than or equal to 4), and, for acceptability (acceptScore),Accept(scores greater than 4), andReject(scores less than or equal to 4) to decrease discrepancies and create a more homogeneous distribution for our inference model (the modeling section ahead gives more detail and, the reader should note, uses these binary category terms extensively).
5.1.1 Extracting Features from Reasons/Comments.The experience sampling survey (Table 3) asked for a text-input reason for the decision to accept (or not) each service request and 77% of responses (4852 out of 6329) included an explanation, giving us useful information about users’ availability/activity and/or other decision
Fig. 3. Distribution of acceptability response scores (acceptScore)
factors. Since the comments were in free text, we used LightSIDE7, a text-analysis tool to extract frequent keywords and phrases. LighSIDE grouped those words and phrases into clusters and we assigned names to these clusters as extracted’reason feature categories’(see Tables 6 and 7) to use in our analysis to better understand users’ decisions. Each request response was denoted as being related to at least one feature category (e.g.,for the extracted reason feature category that we named’availability,’’I am busy,’ availability feature value = ’no;’ ’I am available,’ availability feature value = ’yes;’ and ’I don’t know how to play piano,’ availability feature value = ’n/a’).
Table 6. Reason feature categories that were extracted from reasons participants gave for rating a service request acceptable.
Reason-category Frequency
Willingness 1714
Have the necessary skills/abilities/tools 1572
Availability 1396
Convenience 865
Need more info 476
Trustworthiness 145
Sympathy inspiring 118
5.1.2 Extracting Features from Daily Requests.We manually classified our pool of 334 service requests and 122 profiles in terms of features of the requests that could impact users’ decision to transact (because the amount of text was small, doing this by hand was faster than machine classification). We identified just three notable differentiating’feature categories’ (see Table 7): whether a request requiresspecific skills/abilities/tools (e.g., knowing how to play piano, or requiring a special power tool) value = ’yes’ or ’no’; whether arequest is sympathy inspiring(e.g.,’My dog is sick and needs to go to the animal hospital.’) value = ’yes’ or ’no’; and whether aprofile description is sympathy inspiring(e.g.,’I am a senior living alone and need help with cleaning.’) value = ’yes’ or ’no’. Table 7 lists the 3 by-hand classified feature categories along with the other features discussed above and below.
48:17
Table 7. Feature sets and the outcome response measure extracted from ratings, reasons, and service requests.
Feature
Category Features Values Recommend'n
context ratings profileMatch, locationMatch, timeMatch (high, low)
Reason characteristics
willingness, convenience, availability, trustworthiness, have necessary skills, have necessary tools, altruism, need more info
(yes, no, n/a)
Service-request reason feature categories
requires specific skills/abilities/tools, sympathy inspiring request, sympathy inspiring profile
(yes, no)
Outcome acceptScore (accept, reject)
6
MODELING OF CONTEXTUAL DECISION-MAKING IN SERVICE TRANSACTIONS
We modeled participants’ evaluation of the requested services with regard to their profile and context in order to:
• Showstatistical relationshipsbetweenacceptanceof service requests (acceptScore in Table 7) and a user’s rating of how well each request matched theirprofile(ESS-APL; see Table 3) andspatiotemporal context (indicated by locationMatch and timeMatch see Tables 3 and 7).
• Identify theimpactof eachcontextual featureand itsrelative importance, for example, whether performing a request in a convenientlocationhas more significant weight than time orvice-versa.
In the following, our results show that:
• Finding 1 (F1): Users are more likely to accept those requests that they rate as matchingboththeir profile (ESS-APL) and context.
• Finding 2 (F2): Users are willing to perform a task if it isconvenientfor them in the requested context even if the request does not match their profile(from the ESS-APL).
To achieve these findings, we use a conditional inference framework called Unbiased Recursive Partitioning (URP [32]), which embeds tree-structured regression models into permutation testing [54]. Using this framework to analyze which combinations of features were most predictive of acceptance or rejection of a request, we performed a statistical test between the features in Table 7 and, at each of a succession of branch points, URP chose the feature with the lowest p-value (least likely to be related to acceptance or rejection by chance). The same test is used to stop the recursion when no significant association between features and acceptance or rejection of a request is found,i.e.,when no p-value at the splitting node exceeds a possible chance probability threshold to create a branch (i.e.,the pre-specified p-value of 0.05 with Bonferroni correction for multiple simultaneous tests). Put simply, the URP framework output the combinations of features that are significantly predictive of acceptance or rejection of requests, and does so in a tree (see Figure 4) showing which features in any combination are more predictive (higher up towards the root of the tree) than the others in that combination (along the same branch path from root to leaf).
7
RESULTS
The conditional inference tree (Figure 4) built from our entire dataset (which includes requests in all 3 types of matches described in the design section: profile only, context only, profile and context) contributes to both F1 and F2. This dataset includes basic features that were directly collected from participants’ responses to the recommended requests (contextual match and acceptance ratings from the experience sampling survey, see Table 3) and all the service-request features itemized in Table 7. Although we built models with all features and
! " #$# ! " %#" ! " "# ! " $ &'()*+, -( # ! " $ ! " # ! " #### ! "
Fig. 4. Tree model built from the entire dataset including all 3 types of matches
observed the impact of each feature on the acceptance rate (proportion of acceptance ratings classified as Accept versus Reject, as described in section 5.1), for clarity of explanation, we present the model that demonstrates the feature combinations that lead to thehighestacceptance rate, built with an optimally minimized set of features, obtained through a step-wise feature-selection process.
Underneath each branch of the tree in Figure 4 (whose 3 levels represent the co-occurrence of 3 feature-value combinations), in the vertical bars, light gray represents the proportion ofAcceptscores and dark gray the proportion ofRejectscores (as defined in section 5.1) obtained for that combination of feature values. We now discuss the inferences shown in the tree, taking the left side first.
7.0.1 Figure 4, Left Side: When the requested task was rated as preferred (high profileMatch).As shown on the left side of the tree structure, when the participant’s ratings of profileMatch (ESS-APL), locationMatch, and timeMatch (see Table 2) are all in the highMatch binary category, 93% of the recommended service request ratings are in the Accept binary category (with statistical significance ofp<0.001). When the value of locationMatch is in the lowMatch binary category, but the value of timeMatch is in the highMatch binary category, the ratings in the binary category of Accept are 42%. When the situation is reversed (locationMatch is high and timeMatch is low) the ratings in the Accept binary category rise to 55%. However, when both contextual features (locationMatch and timeMatch) scorelow, service request ratings in the Accept category falls below 24%. All this means that
48:19 contextual match (i.e.,situational convenience) plays an important role in the participant’s decision and does so even when the profiles of transaction partners (their service category preferences) highly match. It also shows that location has a relatively higher impact in this process than time. Time may be secondary in determining acceptance because it is usually more negotiable than the location of a service.
7.0.2 Figure 4, Right Side: When the requested task was not rated as preferred (low profileMatch).The right side of the tree contributes to F2. Even when the profileMatch value is in the lowMatch binary category, if at least one contextual feature (locationMatch or timeMatch) is in the highMatch category, the Accept rate goes up to 30% when the request does not require specific skills/abilities/tools (the ’requiresSkillOrTool’ feature is absent from the left side of the tree, because its relationship to acceptance ratings with that combination of feature values is not significant enough to create a branch). This again shows that the location aspect of a contextual match positively impacts request acceptance, even when the task does not match the profile (preferences) of the provider.
The right side of the tree mostly represents data from the recommendations that were designed and targeted to match sensed context but not profile (low ProfileMatch). To get more precise results, we repeated our URP analysis with the same feature-set as before with only the data from such non-profile-matched recommendations. With this data, we find a 79% Accept rate when ratings of both location and time matches are high and the request does not require specific skills/abilities/tools. The percentage drops to 70% when the request does require specific skills/abilities/tools. In the case of a recommended request having bothlowlocation match andlowtime match, the Accept rate is only 4% even if the request does not require skills/abilities/tools. These observations mean participants are willing to accept a service if it is at least somewhat convenient for them, even if they do not express preference for the service type (low profileMatch), and this contributes to F2.
7.1
The impact of non-spatiotemporal factors on the acceptance of service transactions
Our URP analysis mostly focused on spatiotemporal context as a proxy for convenience. However, we also computed the impact of three ’other contextual features.’
Firstly, we looked atrequest sympathy, andprofile sympathytogether. We found that when spatiotemporal context does not match, the average acceptability score in ’sympathy-inspiring requests and/or requests with sympathy-inspiring requestor profiles’ is twice as high as other requests (2.8 vs. 1.4 on a scale of 1=would definitely reject to 7=would definitely accept). This shows that sympathy can influence the acceptability of inconvenient requests, although the impact of these two sympathy features were swamped by the spatiotemporal features (i.e.,convenience) prioritized in our URP analysis.
Secondly, as mentioned before, although we did not formally collect experience sampling data or sensing data on daily activities, we inferred subjective activity (e.g.,at work) from participants’ daily comments in the experience sampling survey. We classified activity types into a single availability feature (i.e.,available or unavailable) because most activities mentioned clearly implied availability or unavailability (e.g., I am at work right now). The feature ofavailabilityis among the most frequent reasons listed in the extracted terms in Table 6 (1396 instances) that described activities and states (e.g.,’at work’, ’free’ or ’busy’) given as explanations for service acceptability rating (acceptScore; Table 7). Since availability is an important contextual factor that impacts users’ decisions, we looked at the subset of service request rating response data where the value of the availability feature was ’yes’ or ’no’ (i.e.,participants had indicated textually that they were available or unavailable at the requested time, though they did not always provide this information). We found that the average acceptability rating for all these service request rating responses was 5.9 when the value of availability feature was ’yes’ whereas it was 2.3 when the availability feature was ’no’ regardless of the match score for profile, location, and time. This hints at the value of tracking a person’s daily activities to infer their availability as it has a high impact on people’s decision to enter service transactions.
Table 8. The accuracy of acquiring current and future locations of participants.
Distance between location-matched request and participant’s true location within half a mile
Distance between location-matched request and participant’s true location within one mile
Current Context 81.3% 84.9%
Future (Predicted) Context 84.9% 87.9%
Overall 83.2% 86.4%
7.2
The Impact of Predicted Context on Acceptance of Service Requests
We were also interested in understanding how accurate our inference of current and predicted future context was when we tried to generate current and predicted location-matched requests and how proximity affected users’ willingness to accept a request. To measure our accuracy, we calculated the distance of the current and predicted location-matched requests from (i) a participant’sactuallocation at the time they received a location-matched requestfor nowand (ii) theiractual location at the time specified in a request for a location-matchedfuture task. In other words, we were testing how well we matched a current location-matched request to where the participant was now and how well we matched a future location-matched request to where the participant turned out to be at the time it specified. Our distance markers (half a mile and one mile) were chosen based on the fact that the majority of our participants were willing to perform services within a distance of half a mile or one mile (Figure 1).
As shown in Table 8, the location of 83.2% of current and future requests were within half a mile of participants’ actual location at the requested time and 86.4% fell within one mile of their actual location. The lower accuracy for current location matches compared to future location matches may be explained by the fact that, since we calculated a nearby location for requests based on the latest location in our database (which was acquired every 3 minutes), the accuracy of the inferred location would be affected by participants’ change in location (if moving) and/or technical reasons including phone’s termination of background services to save battery that prevents the data collection app from tracking the most recent location. In such cases, our backend application uses the last collected location data point as the user’s current location, which indeed might not be the most recent location of the user. While our accuracy results mostly confirm the potential of tracking and using daily patterns in providing more targeted recommendations, they also encourage improvements in learning and prediction algorithms for more precise and opportunistic recommendations.
Despite the success of our algorithm in detecting current and predicting future context, we noticed that the average rate of locationMatch was relatively low (3.4, max is 7). This indicates that even though the locations of requests were less than a mile from the actual location of participants, the majority (∼62%) still rated the locationMatch as low, even though the majority of participants rated themselves, on average, as being willing to perform tasks within one mile from where they were. One explanation for the lower rating might be the fact that in our simple experimental app, we only gave the name of a place or intersection in the description of a request, rather than a map view showing current location and task location, so some participants might not have recognized the location and were unable to estimate its distance from them. Our intuition is based on the fact that our study was conducted with some participants who were new to the city. The design implication of these results, however, is to show the distance of and directions to the requested location on a map to help users make a more accurate estimation of convenience for service transactions and to navigate to the service request’s location.
48:21
Fig. 5. Average acceptance and rejection trends throughout the study. When the request matched the participant’s situation in each of conditions, it was rated on average above 4 (Accept) and when the request did not match, it was rated on average below 4, regardless of the number of days since the start of study
We also looked at the acceptance pattern over the 5-week period of study to see whether there is any trend in the acceptance rates as a result of, for example, novelty affect. The levels of acceptance ratings are relatively constant throughout the study and do not indicate such an affect. As shown in Figure 5, when requests matched participants’ situation, they were rated, on average, above 4 (Accept) and when requests did not match, they were rated, on average, below 4 regardless of the day of study. We now discuss implications of our findings in leveraging proactive context-awareness in P2P-VST services.
8
IMPLICATIONS AND DISCUSSION
8.1
Contextual Convenience Matters More Than Task Preference
Our analysis showed the impact of contextually targeted service transaction opportunities on the likelihood of accepting a transaction. Ninety-three percent (93%) of recommended services, the majority of which did not require specialist skills, were accepted when preferred task types in the participant’s profile matched and the service request was made in a spatiotemporally convenient context, whereas this percentage was only 24% when the preferred task types matched but context did not. A relatively large number of participants’ comments (865) mentioned contextual convenience as the main reason for accepting or rejecting service (e.g.,too far, close enough, and timing is good). The important implication of this finding is that recommendation algorithms should weigh contextual factors (e.g.,location and predicted location) more heavily than task history and task preference match (current approach in timebanks) in recommending non-specialist service requests.
An argument against the utility of context-awareness in P2P-VST (variable service transaction) systems could be that some tasks or services are flexible and less context-dependent, in terms of time and/or place and can be planned beforehand. For example, house cleaning or moving help are less context-dependent than ridesharing, so context-aware recommendations may not be more effective than manually searching and planning for transactions. However, our participants (on average) for all of the service categories we used, slightly agreed with the assertion that they were context-dependent. They tended to agree most with the context-dependence assertion for transportation tasks and tutoring.
In our experiment, the requests were matched on the level of service preference only, which is the current approach in Timebanking, and therefore, the most ecologically valid approach we could adopt. Although more details about participants’ skills and preferences would have some value, our experiment was more focused on evaluating the impact of context, and as mentioned earlier in this section, our analysis demonstrated that even if
