Dynamic Labor Supply in the Sharing Economy Jonathan Hall Uber Technologies Chris Nosko University of Chicago October 18, 2015 Abstract A host of new platforms use dynamic pricing as a key tool to balance supply and demand. Dynamic prices have at least two potential effects on the market: On the demand side, they allocate resources to those with the highest willingness to pay, throttling demand. On the supply side, they signal to potential suppliers that this is a time of high demand, potentially leading to an increase of services supplied. This latter effect distinguishes dynamic pricing in this context from our traditional notions of intertemporal price discrimination. We study the case of Uber, a platform that matches riders to drivers and uses “surge pricing” during periods of high demand. We present stylized facts consistent with both demand throttling and supply-side increases. We then use a structural model to decompose these effects and consider a counterfactual world with no surge pricing, quantifying the resulting inefficiencies.
25
Embed
Dynamic Labor Supply in the Sharing Economy · Dynamic Labor Supply in the Sharing Economy ... riders to drivers and uses \surge pricing" during ... Uber employs dynamic pricing in
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Dynamic Labor Supply in the Sharing Economy
Jonathan HallUber Technologies
Chris NoskoUniversity of Chicago
October 18, 2015
Abstract
A host of new platforms use dynamic pricing as a key tool to balance supply anddemand. Dynamic prices have at least two potential effects on the market: On thedemand side, they allocate resources to those with the highest willingness to pay,throttling demand. On the supply side, they signal to potential suppliers that this isa time of high demand, potentially leading to an increase of services supplied. Thislatter effect distinguishes dynamic pricing in this context from our traditional notions ofintertemporal price discrimination. We study the case of Uber, a platform that matchesriders to drivers and uses “surge pricing” during periods of high demand. We presentstylized facts consistent with both demand throttling and supply-side increases. Wethen use a structural model to decompose these effects and consider a counterfactualworld with no surge pricing, quantifying the resulting inefficiencies.
1 Introduction
In markets with highly variable demand, prices that fluctuate over time can be used to
equilibrate the market. In a world of static prices and fixed supply, we might expect that
in periods where consumers have higher than average willingnesses to pay, demand will
outstrip supply and a number of consumer who would have been willing to pay more than
the going rate are left out of the market. Demand is matched to supply haphazardly and
inefficiently. Similarly, when demand is lower than average, a number of consumers who
would have entered the market with lower prices are forced to their outside option, leading
to deadweight loss. For this reason alone, dynamic pricing can lead to more efficient markets.
A distinguishing characteristic of the new sharing economy is flexibility on the supply
side. Rather than supply being fixed, agents enter and exit the model freely and flexibly.
Examples include Air BnB, where people decide whether or not to rent out their rooms on a
night by night basis, Taskrabit, where people supply services such as household chores, and
Relay Rides where people rent out their cars to other consumers. This flexibility comes at
a cost to the platform. Rather than being able to easily walk up the supply curve during
periods of peak demand, for instance by hiring more workers or building more widgets, the
platform must somehow coordinate agents that have their own incentives and preferences.
One method of doing this is by using prices as a signal to induce more suppliers during
periods of high demand and to reduce excess supply during periods of low demand. In these
cases, dynamic prices have both a demand throttling effect as described in the first paragraph
and a supply inducing effect. The combination of the two may well lead to more efficient
markets relative to a world of static prices.
This paper considers one such platform: Uber. Uber is a platform that connects riders to
independent drivers who are nearby. Riders open the Uber app to see the availability of rides
and the price and can then choose to request a ride. If a rider chooses to request a ride, the
app calculates the fare based on time and distance traveled and bills the rider electronically.
In the event that there are relatively more riders than drivers such that the availability
of drivers is limited and the wait time for a ride is high or no rides are available, Uber
employs dynamic pricing in the form of a “surge pricing” algorithm to equilibrate supply
and demand. The algorithm assigns a simple “multiplier” that multiplies the standard fare
in order to derive the “surged” fare. The surge multiplier is presented to a rider in the app,
1
and the rider must acknowledge the higher price before a request is sent to nearby drivers.
Despite the potential economic efficiencies of a surge pricing system, this practice has
met widespread popular criticism. Some articles discuss the pricing algorithm as “gouging”
and consumers have at times angrily complained about the practice.1 Certain municipalities
such as New York City have gone so far as to discuss banning the practice. A key discussion
in the argument is whether or not surge prices are simply a way of price discriminating
against consumers, charging them high prices to take advantage of their higher willingness
to pay, or whether it does in fact stimulate the supply side of the market. Certainly, Uber
claims that a key reason for using dynamic prices is for the latter reason.2
In this paper we examine the economic efficiencies that result from surge pricing. We
characterize demand and supply conditions during periods of normal demand and during
periods of high demand. Because surge prices are endogenous to the system, and in particular
are a direct result of increased demand, simple correlations (or regressions) of prices and
supply conditions will miss the true causal effects of dynamic prices. These correlations
could either overstate of understate the true causal effect. They might overstate the effect
because drivers, anticipating high demand, may want to be on the road, whether or not
prices increase or not. For instance, driving during rush hour (a period of peak demand)
holding everything else constant, will almost surely result in more completed trips for the
driver than driving at 2am, regardless of whether surge prices are in effect or not.3 On the
other hand, periods of peak demand might also be times when drivers’ costs, either in terms
of opportunity or otherwise, might be highest. Simply put, everybody wants to get a cab
when it’s raining out, but it correspondingly stinks to drive in the rain.
For these reasons we rely on a structural model to estimate demand and supply primitives.
We rely on variation in the pricing schedule that induced a series of different equilibria across
cities and across time. A further source of identification comes from certain changes in the
1See for example, “Is Uber’s Surge-Pricing an Example of High-Tech Gouging?” The New York Times,Jan 10, 2014.
2See, for example, Uber’s help page on the topic, https://help.uber.com/h/6c8065cf-5535-4a8b-9940-d292ffdce119 , which has the following quote: “At times of high demand, the number of drivers we can connectyou with becomes limited. As a result, prices increase to encourage more drivers to become available.”
3We note that in reality everything is, of course, not constant. In fact, periods of peak demand mightinduce more drivers onto the road such that takehome pay stays steady regardless of demand conditions.This is a point that is threaded deeply throughout analysis. For now, we just wish to make the point thatdemand alone might induce changes in driver behavior regardless of prices.
2
commission schedule across time. As an example, in June of 2014, Uber cut prices widely
across a number of different cities in different amounts. This induced corresponding shifts
in demand and supply curves across these different cities. In cutting these prices, they also
diffentitially changed commission rates across these cities. In New York City, the lower prices
were passed on to drivers in the form of lower per trip takehome. In Chicago, drivers were
“made whole” by Uber, being paid on the pre-price change rate, rather than the new lower
rate that riders saw. This effectively separates demand and supply shocks. We argue that
within a certain time window these price and commission changes were uncorrelated with
shifting driver or rider primitives.
2 Surge pricing case study
We begin with a motivating example pulled out of the Uber data.4 On March 21, 2015, pop
superstar Ariana Grande played a sold out show at Madison Square Garden.5 Attendees
attempting to get home after the concert caused a large spike in demand.
Figure 1 shows the number of riders opening the Uber app in the vicinity of Madison
Square Garden directly after the concert ended:
App openings are a good representation of those who are in the market for Uber’s services
and thus provide a nice measure of demand. As we can see from the red line, the number
of riders opening the app after the concert spiked up to 4 times the normal number of app
openings.
Because of this increase in demand relative to the number of available Uber cars in the
area, surge kicked in, fluctuating between 1 and 1.8x for over an hour after the concert
ended.6
4More details on the exact dataset we use are described below.5We chose this particular concert example in order to circumstantially match the New Year’s Eve example
described next. We looked for a spike in demand that generated surge pricing that drivers could predict –in that sense similar to New Year’s Eve. Further we used New York City and an approximately similar timeframe in order to hold as many details of the situation as constant as possible. We view this as a case studyexample and generalize in later sections of the paper.
6During the 75 minute surge period, prices were surged for 35 of those minutes: at 1.2 for 5 minutes, 1.3for 5 minutes, 1.4 for 5 minutes, 1.5 for 15 minutes, and 1.8 for 5 minutes.
3
Figure 1: Demand for Uber Spikes Following Sold-Out Concert on March 21, 2015
Figure reports the number of users opening the Uber app each minute over the course of March 21, 2015 (in red), as well as the sum of totalrequests for Uber rides in 15-minute intervals over the same time period (blue circles). Data is for a restricted geospatial bounding box
containing Madison Square Garden in New York City, roughly 5 avenues long and 15 streets wide, for uberX vehicles only. Pure volume countshave been normalized to a pre-surge baseline, defined as the average of values between 9:00 and 9:30 PM that evening, before surge turned on.
Surge period (yellow box) is the time over which the surge multiplier increased beyond 1.0x.
The first effect of surge was to increase the number of drivers in the area. Surge signaled
that this was a valuable time to be on the road, and driver supply increased by up to 2x
the pre-surge baseline.7 This increase in driver supply was a net win for riders in the area
because more of them were able to take advantage of Uber services. The supply response is
shown in Figure 2.
The second effect of surge pricing was to allocate rides to those that value them most.
Figure 3 shows that, while the number of app openings increased dramatically, the number of
actual requests didn’t increase by nearly as much. This came from riders who opened the app,
saw that surge pricing was in effect and decided to take an alternate form of transportation
or chose to wait for surge pricing to end. This was economically efficient because those that
ended up requesting a ride are those for which their outside option was worse, leading them
to value Uber more in that particular moment. The gap between the red and blue line could
be tentatively interpreted as a measure of this allocative efficiency.
7Note that we cannot make the strong claim that surge pricing caused more drivers to be in the area.We might worry, for instance, that the increase in demand was an important contributor to driver supply inand of itself. For instance, if drivers understood that the concert was ending and moved themselves into thearea to take advantage of the ease of picking up a passenger, then we would overestimate the causal effectof surge. Nevertheless, the graph provides striking correlational evidence. We also compare this situation tothe one we describe below where surge does not kick in and show that in that case drivers do not respond
4
Figure 2: Uber Driver Supply Increases to Match Spike in Demand
Figure reports the number of active uberX drivers within the same geospatial box (noted above) each minute over the course of March 21, 2015(in green). In this case, active means they were either open and ready to accept a trip, en route to pick up a passenger, or on trip with a
passenger. Pure volume counts have been normalized to a pre-surge baseline, defined as the average of values between 9:00 and 9:30 PM thatevening, before surge turned on. The surge period (yellow box) is the time over which the surge multiplier increased beyond 1.0x.
Figure 3: Supply Rises to Meet Demand Following a Sold-Out Concert on March 21, 2015
Figure reports the number of users opening the Uber app each minute over the course of March 21, 2015 (in red), as well as the sum of totalrequests for Uber rides in 15-minute intervals over the same time period (blue circles), and the number of active uberX drivers within the samegeospatial box (noted above) each minute (green line). In this case, active means they were either open and ready to accept a trip, en route topick up a passenger, or on trip with a passenger. Pure volume counts have been normalized to a pre-surge baseline, defined as the average ofvalues between 9:00 and 9:30 PM that evening, before surge turned on. Surge period (yellow box) is the time over which the surge multiplier
increased beyond 1.0x.
5
Figure 4 displays the net effect on the operating health of the system. The first key sign
that surge pricing was effectively equilibrating supply and demand is that the completion
rate – defined as the percentage of requested rides that end in a completed trip (the third
panel) – didn’t change even in the face of a large increase in demand. All of the riders who
decided that they were willing to pay the surge price and thus effectively signaled that they
had a value for Uber services in that particular moment were able to get a ride. Others had
the option of waiting until the surge multiplier fell.
Figure 4: Vital Signs of Surge Pricing on March 21, 2015
All data above is for uberX vehicles from within the geospatial bounding box mentioned earlier, aggregated into 15 minute intervals over thecourse of the evening of March 21, 2015. Requests is the count of Uber trips requested during the 15 minute interval. ETA is the average wait
time for a driver to arrive, in minutes, over the 15 minute interval. Completion rate is the percentage of requests that are fulfilled (calculated asthe number of completed trips within the 15 minute interval, divided by the sum of completed trips and unfulfilled trips). The yellow box
indicates the same surge period highlighted in Figures 1-3.
The second key sign that the surge pricing algorithm was working as predicted is that
wait times did not increase substantially. Not only did everybody that wanted an Uber ride
(at the market clearing price) get allocated one, but this allocation happened within a short
amount of time – on average 2.6 minutes.
The surge algorithm works by allocating a higher hourly income to driver-partners in
order to convince them to work where and when demand is high. A simple hypothetical
calculation shows that without surge, drivers in the March 21 concert area would have made
13% less than what they made with surge multipliers applied.8
Next, let’s consider a counterexample where demand is high but surge is not in effect. A
to an increase in demand.8Here, we simulated what driver earnings would have been had surge pricing not gone into effect – that
is, if prices had remained at the normal rate rather than 1.1x - 1.8x higher as a result of the surge multiplier.Total driver earnings from completed trips that began within the surge period (10:30 PM to 11:45 PM) –and within the same geospatial bounding box noted earlier – were $3,520 (the sum of fares minus Uber’sservice fee). Had surge pricing not been in effect, total payments to drivers would have been 13% lowerat $3,078. We note that this is a partial equilibrium calculation in that it doesn’t adjust for differences inpickups and dropoffs that might have occurred in the absence of surge.
6
nice illustration comes from New Year’s Eve, when, because of a technical glitch, the surge
pricing algorithm across the whole of New York City broke down for 26 minutes.9 Figure 5
illustrates the surge multiplier over the course of New Year’s Eve - the busiest travel time is
in the hours after midnight.
Figure 5: Twenty Minutes Without Surge on New Year’s Eve (January 1, 2015)
Figure reports the surge multiplier for a given minute over the course of New Year’s Eve, December 31, 2014 to January 1, 2015, for uberXvehicles within the geospatial bounding box noted earlier (blue line). Surge outage (red box) is the time period during which Uber’s surge pricing
algorithm broke down due to a technical glitch, from 1:24am to 1:50am EST
New Year’s Eve represents one of the busiest days of the year for Uber and illustrates
why surge pricing is necessary in inducing driver response. At the same time that demand
is unusually high, drivers are simultaneously reluctant to work because the value of their
leisure time (e.g., their own celebrations of New Year’s Eve) is high. Put bluntly, people do
not want to drive on NYE, and, in the absence of surge pricing, we might expect the gap
between supply and demand to be large.
Indeed, during the surge outage, the rate at which requests for rides were fulfilled fell
dramatically, as illustrated in Figure 6:
Figure 7 illustrates the impact of the surge outage on the same key metrics reported in
Figure 4 during a time of normal surge operation.
As prices fell from 2.7x the standard fare (the surge multiplier in effect prior to the
outage) to the standard fare, lucky riders took all of the available cars on the road. Once
existing supply was taken, expected wait times increased dramatically. At the low price of
1x the normal fare, driver supply likely dwindled, though unfortunately the same technical
9Note that it’s important that this glitch occurred for seemingly random reasons. We cannot simplycompare a situation where surge is occurring to one in which it is not because the demand conditions wouldbe very different from each other. Here, we know that demand is high and surge should be in effect but israndomly not in effect, giving us an effective comparison that holds demand constant.
7
Figure 6: Impact of a Surge Pricing Disruption on Completed Ride Requests on New Year’sEve
Figure reports the completion rate for a given 15 minute interval over the course of New Year’s Eve, December 31, 2014 to January 1, 2015, foruberX vehicles within the geospatial bounding box noted earlier (red line). Completion rate is defined as the percentage of requests that are
fulfilled (calculated as the number of completed trips within the 15 minute interval, divided by the sum of completed trips and unfulfilled trips).Surge outage (red box) is the time period during which Uber’s surge pricing algorithm broke down due to a technical glitch.
Figure 7: Vital Signs of a Surge Pricing Disruption on New Year’s Eve (January 1, 2015)
All data above is for uberX vehicles from within the geospatial bounding box mentioned earlier, aggregated into 15 minute intervals over thecourse of New Year’s Eve, December 31, 2014 to January 1, 2015. Requests is the count of Uber trips requested during the 15 minute interval.
ETA is the average wait time for a driver-partner to arrive, in minutes, over the 15 minute interval. Completion rate is the percentage of requeststhat are fulfilled (calculated as the number of completed trips within the 15 minute interval, divided by the sum of completed trips and
unfulfilled trips). The red box indicates the same surge outage highlighted in Figure 6.
8
flaw that inhibited surge also inhibited the collection of data that would allow a summary
similar to that in Figure 2. Perhaps most dramatically, the rate at which ride requests were
fulfilled fell steeply; a small number of riders got a good deal, but most were left without a
ride at all.
Unlike the Madison Square Garden concert example above, driver supply failed to satisfy
rider demand with low wait times. Neither of the economic mechanisms of surge pricing
were working, and that led to a low number of rides actually being completed. This low
completion rate indicates that supply and demand were severely imbalanced.
We would like to generalize from this example to ask more systematic questions around
the effects of surge. There are two challenges in doing this. First, we have very few examples
of surge randomly shutting down. Indeed this is the only one that we are aware of. While
it makes for a nice illustration, it doesn’t allow for a more complete understanding of the
whole marketplace. Second, the surge outage was unexpected. We might think that one of
the effects of surge is to coordinate driver behavior over a longer time period. For instance if
drivers know that surge is likely to occur during rush hour, this might induce them to change
their schedule to be on the road during that time period. In other words, expectations over
when and where surge will occur might be a key part of how dynamic pricing helps coordinate
supply and demand. This latter point is one that we will return to repeatedly throughout
the paper.
3 Data
Uber operates a number of different services. For this paper we concentrate exclusively on
UberX. UberX is a service that coordinates potential drivers using their own private cars with
riders. These cars are your typical run of the mill types – Honda Accords, Toyota Priuses,
etc. Drivers provide their own cars and decide when they would like to work without telling
Uber ahead of time when and where they will work. They simply turn on the app, letting
Uber know that they are available to have rides dispatched to. When they are done working
they turn off the app and go on their merry way. The Uber system keeps track of where
these drivers are using GPS, giving the algorithms a complete picture of where all drivers
are at any given moment and allowing for the efficient matching of riders to their nearest
9
driver.
A potential rider opens the app and is greeted by a map showing all of the available
cars in the area along with the expected wait time of getting a driver. At the bottom of
the screen, the user can switch between Uber’s different services. Next to each service icon
on the bottom of the screen a lightening bolt may or may not be displayed. This lightning
bolt is an indication that the service is experiencing high demand and so surge is in effect.
At this point the rider is not shown exactly what the surge price is. If these conditions
are acceptable a rider can hit a button to request a ride. Figure 8 displays a screenshot
of this situation. Notice that there is a lightning bolt for UberX but not for UberXL. This
indicates that UberX is currently undergoing surge but UberXL is not. Should a rider decide
to request a ride, if surge is in effect, they are shown a screen such as the one on the right.
Here they are told exactly the multiplier that is in effect and given the option of continuing
on to request a ride or not going any further.
Figure 8: Screenshot of the Uber app
If the driver requests a ride, the system dispatches that request to the nearest driver.
The driver is shown where the request is coming from and has 45 seconds to respond. If he
accepts the dispatch, then the rider is notified and the driver sets off to pick up the rider. If
the driver either declines the request or allows it to expire, the ride is dispatched to the next
10
nearest driver who then goes through the same process. This continues until either a ride is
dispatched or all of the available drivers are cycled through. In practice, in thick markets,
rides are almost always picked up by the first driver. Indeed drivers have strong incentives
to pick up a ride as soon as possible both for economic reasons (they only get paid when
they are on trip) and for internal Uber discipline reasons. A driver who is consistently not
picking up rides will be called out by internal teams and asked to explain themselves. If this
continues, a driver could even be kicked off of the platform. After the driver arrives at the
request location, he is given the destination address, either typed into the app by the rider
or told to the driver by the rider directly. The ride is then completed and the rider’s credit
card charged for the trip. After the ride ends, the app provides a mechanism for both the
rider to rate the driver and vice versa.
Riders are charged a trip fee that combines a fixed base fare, and a variable fare that is
a linear combination of a per minutes price and a per mile price. There is also a per trip
minimum fare – should the trip turn out to have a lower price than this minimum, the rider
is charged this minimum fee. An example with current Chicago prices is as follows:
max{$1.70 + $.20 ∗mins+ $.90 ∗miles, $4}
As mentioned earlier, when surge is in effect, the final number is multiplied by the surge
multiplier to get the final surged fare.
This fare is passed onto the driver minus a commission that Uber keeps. This commission
rate tends to be 15% of the final fare, although that number is not always the same across
cities and across time. Indeed, as discussed below, Ubers changing the commission rate
provides some useful variation for identifying driver primitives. When surge is on, drivers
takehome pay increases with the surge multiplier providing incentives for being on the road
and picking up more rides during this time period.
We stitch together three sources of internal Uber data for this paper. The first is a
complete record of every single trip that was completed between January of 2014 and July
of 2015 for 48 different cities. These cities include almost all of the cities where Uber is
operational in the United States.10 These trips logs include privacy protected IDs for the
driver and rider, characteristics of the ride (trip length, price, etc.). Importantly we have
10The missing cities are simply because they are too small to provide meaningful data.
11
information on whether the trip occurred during a surge period and if so, what the surge
multiplier was. We also have information on the takehome pay of the driver for that particular
trip.
The second set of data consists of records of whether or not the driver has the app on.
The level of observation is at the driver / hour level. For each hour where the driver opened
the app to the signal that he was available to accept rides, an observation is recorded. The
record then consists of the number of minutes that the driver kept the app open, the number
of minutes that the driver was on trip, and the number of completed trips, which, of course,
can also be calculated from the trips log. Importantly this data is quite clean in that it is
highly unlikely that a driver would keep the app on if he were not willing to accept a ride.
As discussed above, there are internal sanctions if a driver’s acceptance rate falls too low
and that is borne out in the data. We thus have an incredibly clean record of all drivers’
labor supply decisions across time. We can calculate exactly how long a driver was on the
road and the proportion of that time was spent not being paid because the driver was not
matched to a rider.
The last dataset consists of the number of users who opened the app in 15 minute
intervals. This dataset provides a clear signal of demand conditions. By combining the trips
data with this demand data, we can calculate the fraction of people that opened the app
but decided not to accept a ride, giving us the demand elasticities we need for our analysis.
We discuss this much more later in the paper. This dataset has not been delivered to me
by Uber yet. I’m still waiting on it. Thus the analysis will proceed without it for the time
being.
4 Reduced Form Analysis
In this section we present a series of graphs, tables, and reduced form analysis that highlights
properties of the Uber system and the driver labor supply decision. The goal is to understand
what properties are important to build into the model. We divide the analysis into two parts.
In the first part we discuss data that roughly reflect underlying primitives of the model – the
driver decision of when to work and the rider decision of when to open the app (the second
12
part still to come).11
4.1 Driver Heterogeneity
This section argues that there is a significant amount of heterogeneity both across drivers
and within a given driver across day of the week / hour of the day (DOW/HOD) and in the
number of hours worked conditional on the DOW/HOD.
Figure 9 plots the mean number of hours worked in a week across drivers. In other words,
for each driver take the number of hours worked in a given week, calculate the mean across
weeks, and then plot the distribution across drivers. This gives a sense of how many hours
drivers are actually on the road.12
Figure 9: Mean hours worked across driversRed = Excludes 0 weeks
0
1000
2000
0 50 100
Mean Hours Worked
Nu
mb
er
of
Dri
ve
rs
11In truth, these graphs are not strictly speaking reflections of primitives as the driver decision of whento work depends on many endogenous factors. This separation is only for expositional convenience, not areflection of economic principles.
12This is hours worked, not hours on trip, which would be a smaller number.
13
The median driver worked 15.67 hours and the mean number of hours worked was 19.22.
While there are a significant number of drivers that drive a number of hours that indicate
that this is a full time job, most drivers distinctly fall into a “part time” camp.
Next, we consider the variation within a driver. There are at least two important aspect
to consider. First, do drivers tend to work a set schedule? Do they always work evenings
and weekends or Mondays and Tuesdays? Or are they flexible with the hours that they start
their shifts on? Second, conditional on starting a shift at a certain time or on a certain day,
is there flexibility in the number of hours worked? Flexibility in hours worked is a necessary
condition for surge prices to matter in the system. If drivers worked the same schedule
and the same number of hours no matter what prices were, then changing prices could not
generate labor supply changes.
Figure 10: Variation within drivers across weeks
0
10
20
30
40
(5,10] (10,20] (20,30] (30,40] (40,50] (50,Inf]
Mean Hours Worked
Sta
nd
ard
Devia
tio
n o
f H
ou
rs W
ork
ed
(a
cro
ss w
ee
ks)
0
1
2
3
4
0 10 20 30 40 50
Mean Hours Worked (across Weeks)
Nu
mb
er
of
We
eks
Std. Dev (Across Drivers) The “Median” Driver
The left panel of figure 10 begins to unpack the question of flexibility in the driver labor
supply function. The x-axis bins drivers into the mean number of hours that they worked
across weeks. For instance, the second bin contains all drivers that on average worked
between 10 and 20 hours per week. The y-axis plots the distribution of standard deviations
within a driver across weeks, with the red dots giving the median for drivers within the bin.
Take the second bin: The median driver within that bin had a standard deviation of around
10 hours across weeks even though the he only averaged between 10 and 20 hours on the
road. This is a large coefficient of variation – the variation is large relative to the mean.
There is also a large amount of variation in the amount of variation across drivers. For
14
instance, the 95th percentile driver at a standard deviation of nearly 20 hours per week. To
further illustrate the point, the right panel of figure 10 takes the median driver in the data
and plots the number of hours worked in each week. The histogram shows that the number
of hours is quite dispersed. Drivers in the data are not working the same amount of hours
each week. Instead, they are flexibly changing their hours from week to week.