Mobility Brief #2: Micromobility Data Policies: A Survey of City Needs
In the past year, cities have been prompted to rapidly re-examine the management and regulation of transportation services due to the influx of micromobility. This recent movement has illuminated major opportunities to expand transportation options while highlighting several challenges for widespread adoption and support. In the context of data, the conversation has evolved quite differently from TNCs just a few years ago. Cities are creating detailed data requirements for operators and are successfully obtaining that information as an input for smarter future transportation plans.
We surveyed over a dozen emerging micromobility data sharing policies in places like Nashville, Chicago, Seattle, Portland, Santa Monica, Dallas, San Francisco, Austin, Denver, Pittsburgh, Houston, Durham, Salt Lake City, and Chattanooga. These policies represent a combination of exploratory pilot programs, post-pilot permits, and even one emergency rule. Based on our research, we see these core data sharing policy features:
- Universal agreement on the need for trip and fleet availability data
- A range of expectations for data update frequencies
- A variety of approaches toward customer feedback and other data
- The need for data sharing agreements between private vendors and public authorities to meet transportation, safety, and equity goals.
Most cities have specified minimal requirements for fields and content from providers. The Los Angeles Department of Transportation has made an additional effort to codify these into the Mobility Data Specification (MDS), a new data sharing standard intended for use in and beyond Los Angeles. MDS prescribes a data format for trip data, fleet status, and communication expectations between city regulators and private fleet providers. It meets most of the broadly-specified policy aims from cities like Nashville, Santa Monica, San Francisco, and others. MDS is being developed via an iterative, public process on Github with participation from cities and vendors alike.
Boston’s former CIO Jascha Franklin-Hodge outlined a structure for cities to think about these policies in “The Scooter Data Opportunity.” We’ll distill the content of our surveyed cities’ policies against those criteria.
Data For Individual Trips
Trips are the most consistent and potentially transformative kind of data cities are requesting. Individual trips from vendors will result in enormous volumes of data. Just one vendor, Lime, recorded “10 million rides in about the same period of time it took Lyft to do its first 1 million,” says their head of Policy & Public Affairs, Emily Castor Warren. A few takeaways:
- Every city policy is asking for consistent trip-level data;
- Data directly supplied by vendors can help cities plan; and
Why it’s important
Until now, cities like Nashville often relied on analyzing inferred trip data from sources such as surveys, complex travel demand models, or smartphone location data aggregators to achieve this goal. With micromobility, the data can be retrieved from its source at the provider level, allowing cities to work more quickly with private partners to reach mutual success. As an implementation example, Santa Monica is requesting information in an emerging open data standard called MDS. In addition to the real-time and historical trip and availability data cities are looking for, MDS provides a method for cities to digitally communicate operational restrictions to multiple providers.
Trip-level data is most useful for understanding new mobility options’ impacts on other city infrastructure, such as transit and streets, which helps explain why we find this requirement coming from cities of all sizes and regions. Possibly wanting to make-up ground from the first era of app-based mobility several years ago, cities are proactively asking for highly detailed, but anonymous, trip information from micromobility providers. The policies we reviewed show a clear consensus on what a “trip” means to them. Cities from Chicago to Houston want to see:
- Start and end times of individual rides on each micromobility device;
- The path of each ride; and
- The unique identification number of the device used for each ride.
Trip data enables cities to make informed observations about the land uses most supportive of micromobility device use, the streets most in need of multimodal design treatments, and how these new modes interact with the rest of the transportation system, among countless other analyses.
For example, Nashville’s micromobility policy states a desire to
“…encourage and provide for new transportation options for Nashville residents and visitors…[and] encourage and foster innovative transportation options in Nashville to ease the city’s increasing traffic congestion.”
How it’s implemented
Given the volume of trips riders take once micromobility providers launch, the amount of trip data may become difficult for cities to work with. A city like Los Angeles, which plans to permit over 10,000 scooters to operate on its streets, will have to process data for a similar number of trips each day. To account for this, many cities request trip data via an API. This provides both a real-time interface city staff can check at any time and an infrastructure for compiling archival data. Many city policies we reviewed recognize the need for both current and historical trip data to see both current activity and travel behavior over time. Seattle went farther by breaking down each requested field:
Cities who didn’t specify trip data delivery via an API, like Salt Lake City, requested it in a static format at regular intervals. Though this may not give cities a real-time picture of the provider’s fleet, the archival data is still crucial for understanding a micromobility provider’s place on the transportation spectrum.
Fleet Availability Data
Second to trip data in importance to policymakers is fleet availability data. Just as users need a picture of available devices near them, cities require this information to identify underserved (or oversupplied) neighborhoods and hold providers accountable for proper device rebalancing and/or recharging. Overall, we found that cities requested the following to understand if they were achieving their desired supply and rebalancing goals:
- Real-time locations of active and inactive devices
- The provision of availability data in the open GBFS standard (see more on GBFS below).
Why it’s important
Fleet availability data serves multiple purposes. Providers display this information so users can locate vehicles. It’s also a core operational component of each provider’s service. Users of each micromobility app need to see current device locations to make use of the service. This same data is also useful to cities managing their public right-of-way. For example, like many cities, the Los Angeles Department of Transportation (LADOT) intends to enforce a cap on the number of deployed devices within city limits. They are able to do so by using fleet availability data to measure whether operators are complying with their rules.
Fleet availability data sharing requirements are also integral to measuring the success of policy goals around equity. Cities like Santa Monica cite “community wellbeing, sustainability and equity” in their policies, and that up-to-date fleet data can be used to verify that fleets are being rebalanced to serve lower-income communities. Nashville’s policy asks for scooters “to be available in neighborhoods and communities that are underserved by mobility and transportation options.” Location-enabled fleet availability data can help a city determine whether a provider’s device placement is equitably serving the public. Up-to-date fleet data can be used to verify that fleets are being rebalanced to serve lower-income communities and achieve intended equity goals.
How it’s implemented
Nine cities in the group we surveyed request real-time availability and a smaller number ask for data at lower frequencies, such as weekly or even quarterly. There’s a more established practice around fleet data, with a standard from the North American Bikeshare Association (NABSA) called GBFS (short for General Bikeshare Feed Specification). It’s important to note that GBFS is not used for historical data. Five cities in our set mention GBFS by name.
Standards like GBFS don’t require that data be made available to the general public, but some city policies take this extra step. Santa Monica asks that operators make live GBFS data “available to the public for viewing data, querying data, and mapping.” In Chicago, “companies must publish the GBFS feed where it can be accessed without a username or password. Companies may request a token or authentication be used to access the GBFS feed; however, the process to receive a token needs to be available to the public.” Publicly available fleet data allows third-party developers to present it in a user-friendly format alongside other transport data, such as transit schedules, which in turn gives consumers broad insight into their local transportation ecosystem.
Update Frequency: APIs or Reports?
Asking for data is important, but without specifying the frequency at which they’d like to receive it, cities risk making decisions based on outdated information. Luckily, all the policies we reviewed specify how often they want to receive data, either through:
- Real-time updates via API
- Static, periodic reports
Nine of the city policies we looked at mention real-time or multiple daily updates via an API for data about trips and fleets. Only a handful ask for lower frequencies such as monthly or quarterly submissions. APIs (an acronym for application programming interfaces) are a new idea in government technology and may be unfamiliar to city government IT organizations accustomed to working with packaged, periodic reports.
Why it’s important
APIs offer a technical process to request and receive data between computers. A more traditional data sharing requirement might look like Chicago’s, where companies “are required to submit details on trip, maintenance, and customer reported issues on a monthly basis. Companies must follow the specified schemas when reporting the data and pass validation checks before it is accepted by the City of Chicago.” A real-time API requirement would sound like Nashville’s, where operators
“…shall provide the Metropolitan Information Technology Services Department with real-time information on the entire fleet … through a documented application program interface (API). The permitted operator is directly responsible for providing an API key and REST specifications to Metro ITS.”
How it’s implemented
Chicago and Nashville’s requirements serve similar needs, and we can unpack them to illustrate the difference between periodic data reports and a real-time approach.
In Chicago, the city expects data to be delivered by a vendor by a specified date each month. The onus for sharing data lives with the vendor while the city waits for reports to arrive. With an API, Nashville’s technology department can set up scheduled tasks on city-owned computers to ask for this data from each operator’s servers on a regular basis.
A good analogy might be a person refreshing their social media to check for new posts from friends. Instagram provides a standard interface on their web page to look at recent photos. A user can check anytime, day or night, to see the most recent updates, or even ask the Instagram app to check Instagram’s API on their behalf and notify them when a friend has started a live video. With an API, a computer can do the work for you. Terms like “REST” and “API key” in Nashville’s policy show that they’d like operators to set up secure, easy-to-read, regularly-updated feeds of data for the city to consume as-needed. Nashville can look at operator data any time of the day or night to maintain a continuous picture of fleets in the city as often as it needs.
Chicago also describes validation checks and a formal acceptance process. Vendors deliver data to the city and it’s checked for compliance. Nashville’s policy documents up-front the data in a vendor’s API responses such as device type and geographic location. Each vendor creates a location on the web where the city can read up-to-date device information, and this data is checked by the city at the start of the vendor relationship. From that point onward, the city and the vendor have an established relationship by way of the API. The data can be checked continuously because its format and validity were set up just once.
Potential implementation challenges
Nine of the cities we surveyed specified a real- or near-real-time API approach in their policy documents. They’re choosing to meet the implementation challenges of consuming real-time data in order to realize the benefit of a dynamic view of micromobility on the public right-of way. The Los Angeles DOT Mobility Data Specification meets the goals described in each policy document that mentions an API approach.
Assessing User Experience with Surveys
Raw data on trips and fleet availability is crucial for understanding a mobility providers’ impacts, but the numbers can’t capture equally valuable qualitative assessments of the user experience of micromobility. To account for this, cities are asking providers to survey their customers periodically as a condition of their permits.
Rather than document specific trip- or fleet-related events, properly designed customer surveys can provide cities (and micromobility providers) high-level answers on:
- Users’ typical mode split for commute, recreational, and commercial trips;
- The degree to which the micromobility service has replaced or augmented other modes in a user’s mode split;
- The types of trips users take with the service; and
- The users’ overall opinion of the service and any competitors.
Most data policies we surveyed didn’t outline the specifics of the content of the customer surveys they requested, but nearly all of the nine cities who requested them required providers to administer them at regular intervals (usually once over the course of a conditional permit period or every six to twelve months for a permanent arrangement). Additionally, all required providers to seek city approval of survey questions before releasing them to users, and most indicated that survey development should be a collaboration between the city and the provider. Few cities specify specific survey questions in their policies, ostensibly tabling this for discussion with the selected micromobility provider(s).
Other Requests
While there’s broad agreement on the need for trip, availability, and user experience data, we’ve also found that a majority of the roughly dozen cities had requirements covering the following topics:
Parking
The recent influx of micromobility devices has increased competition for already scarce city sidewalk space, prompting a flurry of press coverage of scooters and dockless shared bicycles parked in the pedestrian right-of-way. Especially in dense urban areas, GPS may not be accurate enough to pinpoint the legality of a mobility device’s parking. In response, providers have built features into their consumer-facing apps that require users to take a photo of their parking in order to end a ride. Few cities we reviewed, however, touch on the subject of parking in their data policies. Nashville does request near real-time locations of parked devices explicitly for the purposes of parking enforcement, and others, such as Chicago and Seattle, require regular reports of parking compliance from providers. Chicago lumps parking under “violation data,” a comprehensive look at what can go wrong:
“…bikes parked outside of pilot area, bikes blocking the public right of way, bikes parked on private property, bikes locked to private property, [and] bike-related parking irregularities (e.g., bikes deposited in waterways, suspended from trees or other fixtures)…”
Maintenance & Safety
Any public fleet of shared vehicles will be subject to heavy use (and abuse), so timely and thorough vehicle maintenance is essential. Damaged vehicles present safety risks that providers should help mitigate. Many providers’ bikes and scooters are designed for individual consumers rather than as commercial vehicles, making them especially vulnerable to vandalism and rapid wear and tear. In response, many cities are requesting maintenance records from providers to hold them accountable for the safety and usability of their devices.
Seattle stands out for the specificity of its maintenance records requirements. In addition to service histories, the city requests information on product recalls, user reports of unsafe or damaged vehicles, and tallies of vehicles taken out of service for repair, all on a monthly basis.
Most city policies we surveyed that included language about incident reporting asked for summary data on weekly or monthly cadences. None required details regarding the severity, mode type, or weather/road conditions surrounding the collisions, which are common amongst already established state and local collision record-keeping systems for vehicles.
Data Validation
Given the diversity in quality and legibility of mobility data, cities may not have the capable software or staff to parse or debug raw data. Unfortunately, very few cities we surveyed mentioned data cleaning or validation in their policies. Nashville, however, asks applicants to take specific actions:
“All permitted operators will first clean data before providing or reporting data to Metro. Data processing and cleaning shall include: removal of staff servicing and test trips; removal of trips below one minute; trip lengths are capped at 24 hours.”
Requirements like Nashville’s will save the city time and effort in separating the signal from the noise in the data they receive. However, data quality variations are all the more reason to support flexible, widely-held standards.
Making data work for cities
The pace at which local governments have to come to terms with the latest round of micromobility options is overwhelming, especially compared to new entrants in the past. Fortunately, cities have never been in a better position to gather the information needed to make decisions in the public interest.
Our Policy Team is compiling data policies from cities across the United States and are happy to share our insights. If you’re interested in guidance to craft your micromobility policies around data or other elements of shared mobility, contact our team. If you’d like to download this report in PDF format, you can do so here.
Charlie Bailey contributed substantial content and review. This article also includes words and feedback from many helpful people including Paul Supawanich, Courtney Sung, Dan Getelman, and the authors of each city policy we’ve surveyed here. Thank you.
