“Real-time” ridesharing has been defined in a variety of ways. One of the first formal definitions proposed for “real-time” ridesharing was developed in preparation for a trial in Sacramento, CA in 1994 (Kowshik et al., 1996). The team behind that trial defined “real-time” ridesharing as “a one-time rideshare match obtained for a one-way trip either the same day or the evening before” (Kowshik et al., 1996). Several years later, researchers developing a similar trial in Seattle proposed that “dynamic ridesharing” be defined as “two or more people sharing a single trip, without regard to previous arrangements or history among the individuals involved…a dynamic ridesharing system must be able to match random trip requests at any time” (Dailey et al., 1997). A more recent definition proposed by ‘dynamicridesharing.org’ suggests that “dynamic ridesharing” is “a system that facilitates the ability of drivers and passengers to make one-time ride matches close to their departure time, with sufficient convenience and flexibility to be used on a daily basis” (Kirshner, 2009). Note that all three of the definitions emphasize the occasional nature of these arrangements, using the term “one-time” trips. The other main characteristic of all three of these definitions is the amount of advanced notice required for the arrangement of trips with the Sacramento definition recommending the “same day or the evening before” a trip, the Seattle definition recommending “at any time”, and the ‘dynamicridesharing.org’ definition recommending “close to [participants] departure time”. In general, “real-time” ridesharing implies that little advanced notice is needed when attempting to establish a shared trip.

For the purposes of the study presented in this paper, “real-time” ridesharing is defined as:
“A single, or recurring rideshare trip with no fixed schedule, organized on a one-time basis, with matching of participants occurring as little as a few minutes before departure or as far in advance as the evening before a trip is scheduled to take place”.

“Real-time” services tend to rely on a similar set of technologies and share similar features. The underlying technological requirements often include:

(1) Smart Phones – Many service designs rely on the recent proliferation of smart phones in the market place. The firms developing the underlying software for “real-time” ridesharing have focused their efforts on platforms with easy-to-use, attractive user interfaces such as Apple’s iPhone software and Google’s Android platform.

(2) Constant Network Connectivity – The need to communicate ride requests and accept offers on short notice requires that one be constantly connected to the network. Many smart phones are now offering (or require) unlimited data plans with new smart phone contracts, facilitating constant network connectivity.

(3) GPS Functionality – The use of Global Positioning System (GPS) functionality has been incorporated into many applications so that they become “location aware”. In other words, participants seeking a ride do not need to key in their current location because the GPS built into their smart phone knows where they are located and communicates this information automatically when trips are logged. This is often marketed as a time saving feature.

(4) Ride Matching Algorithm – All of the underlying systems use some form of algorithm to match riders and passengers. Some of the algorithms do so based only on origin and destination, while some of the newer algorithms match drivers and passengers based on the commonality of their travel route.

(5) Data Repository – All “real-time” systems (and Internet-connected rideshare systems in general) have a data repository where rideshare information is stored. The types of data stored might include a current list of ride requests and offers, individual participant profiles and summary statistics on participation.

Many (but not all) “real-time” rideshare services incorporate additional features such as:

(6) Stored User Profiles – Providers will allow users to create and save information profiles. Personal information such as name, employer, home and work locations, popular origin-destination (OD) pairs with the user’s preferred route, and a photo are common. Some systems require a photo of the driver’s vehicle and license number be provided. Stored profiles require more participant time on the front end, but make future ride requests much less time consuming.

(7) Social Network Integration – Because of the propensity of individuals to share rides with people they know or share common characteristics with, some providers have linked their services to existing social networks in an effort to improve successful matches. For some, this has meant incorporating their services with online networks such as ‘Facebook’. In these cases, only friends within a given individual’s immediate Facebook network will be considered when searching for ride matches. For other providers, ‘social network integration’ has focused on offering services to a specific organization or institution. In these cases, only co-workers at the same organization are considered as potential partners.

(8) Participant Evaluation – “Real-time” services may allow participants to rate each other, much like the online auction service ‘eBay’. After a ride has been completed successfully, both the passenger and driver are asked to rate each other. The idea behind this feature is that it allows future users to evaluate potential partners quickly, based on others past experiences. The theory is that those with higher ratings are likely to be preferable shared ride partners.

(9) Automated Financial Transactions – “Real-time” services may allow for financial transactions between participants. Some allow participants to name their own price, while others recommend a value based on standard Internal Revenue Service (IRS) vehicle cost estimates. Some providers facilitate automatic transactions through the use of online payment systems such as PayPal. Other providers simply calculate the recommended shared cost and allow drivers and passengers to negotiate and agree on a final amount and payment method.

(10) Incentives and Loyalty Rewards Linked to Participation – “Real-time” providers may offer incentives or loyalty rewards based on a given individual’s level of participation, much like airline loyalty programs. Those that participate more frequently earn more points or rewards. Providers hope that by providing incentives, existing participants will be encouraged to post rides more frequently, and new participants will be encouraged to join their service.

Comments are closed.