Civic Analytics Network Dockless Mobility Open Letter

By Civic Analytics Network • December 3, 2018

Dear Urban Mobility Solution Providers,

The launch of dockless, electric vehicles in our cities has been exciting for all of us. The innovation in transportation is greatly appreciated. As Chief Data Officers of major cities, we face common challenges in using data to understand when and where these devices are being used - and if they are benefiting residents and visitors from all walks of life.

One of the largest issues is that each real time API provider has to figure out how to provide data - coming up with a schema, an API, data format decisions, etc. Because these devices are a new form of service delivery, cities are also likely asking for all sorts of customized data reports - making it more time consuming for companies to scale.

By providing clear expectations, we hope that both cities’ and providers’ jobs will be made easier. Cities will receive data in a standardized way that allows us to integrate data from all providers and build shared tools amongst cities. Providers will benefit from having a single, standard data sharing agreement with their customers - reducing the need to customize agreements and avoiding unnecessary development time.

The Civic Analytics Network (CAN) has these data recommendations for cities working with dockless and docked new mobility companies.

Many of these guidelines align with NACTOs’ guidance.

Data Policy

1) Data standards

The Mobility Data Specification (MDS) is recommended for all internal and external API formats as it encompasses General Bikeshare Feed Specification (GBFS) and is quickly becoming a well adopted standard.

Alternately for public APIs, a GBFS feed can be used for the public facing real-time data feed of availability. But MDS can be used for this as a subset of GBFS required for the public is defined inside of MDS (#realtime-data).

2) Data access

Access to raw data from mobility providers to cities is essential for internal urban planning, accountability of mobility providers following policy and agreements, ensuring equitable distribution, calculating fees based on policy, and mobility infrastructure improvements for the safety of pedestrians, motorists, and new mobility riders.

Real time API in GBFS (part of MDS) format that shows locations of available scooters, and this API should also be published directly to the public, like DC requires. (required)

Historic API in MDS format of more detailed trip information including routes as GeoJSON, for more detailed analysis. (required)

Location of distribution points across the city with quantity of units allowed per location. This is shown in app already and this data feed should be public facing. Cities can use it to validate equitable distribution, for example. (required)

Monthly data file containing origin/destination full lat/lons, start and end time, distance traveled, and trip ID at a minimum. Useful for planning, mapping, and aggregating for privacy for easily sharing via open data and open records requests, without the need for building tools. (recommended)

Web Dashboard where city leaders can login and see stats, graphs, and heatmaps of historic and real-time usage by day, week, month, or year. (recommended)

3) Open data

News media and the public have the right to aggregated but sufficiently raw data about trips including origin and destination points, real-time availability for inclusion in transit applications, and to follow local open data and state open records laws.

Origin/Destination Historic Data

Block level aggregation (eg, 3 lat/lon decimal places) is good for scooter data and protects privacy of residents. This same aggregation level works well for crime reports, 911 emergency calls, and other more sensitive open data as a national best-practice. Start and end times can also be binned into 15, 30, or 60 minute increments.

This data should include the trip ID, company, vehicle type, origin lat/lon, destination lat/lon, start datetime, end datetime, distance traveled fields.

Note that the raw data of the path of individual routes should not be shared due to privacy concerns. Aggregated visualizations of this data can be shared, for example, showing all routes at once for a time period, route animations, or heatmaps.

Policy Documents

Documents related to city mobility policy should be published online and easily findable via open data sites. These documents include descriptions of all the items listed in this document, including fee structure, data policy, distribution requirements, device caps, operating zones, equity options, etc.

Usage Statistics

Cities can share usage statistics with the public, other agencies, and city council as open data and on demand. These stats can be derived from raw data provided by companies, or via companies directly. They include information like number of devices deployed in public, unique riders, number of rides, deployment locations, average ride length, average speed, rides per device, crash reports, public comments, total miles ridden, average miles per trip, mean miles per trip, total hours ridden, average minutes per ride, mean minutes per ride, total estimated ride costs, average estimated cost per ride, and mean estimated cost per ride for various time periods.

4) Open Records Requests

Where allowed by local law, data shared via Open Records Requests (ORR) should be the same data shared via open data. In fact, open data allows cities to fulfill ORRs more quickly and reduce their frequency. Each state has its own rules for exempting records from ORR or sunlight requests, and not every state may allow for redactions or blurring of geographic information. It may be helpful to have your city attorney’s office weigh in on your options for responding to requests for unredacted records.

General Policy

5) Fee structures

Earmarking some of fees for infrastructure improvements is recommended.

Compiled city fees can be found here for reference. Please request edit access to contribute.

6) Equity

Create zone distribution areas and percents required to each area.

Option to use service without a smartphone, for example, by text message only. Cash only option using PayNearMe or similar service. SNAP or other low income discounts encouraged.

7) Compliance

Create a new 311 category to track reported resident issues from the public more easily. Consider implementing a manual or automated way to forward on any issues that the company can resolve, along with replies when they are resolved with the outcome attached.

Companies should provide a detailed report each month of complaints it has received from residents, including location, date, time, resident description, and outcome. Require real-time reports of more serious issues like injuries, property damage, explosions, etc.

8) Capacity Monitoring

All devices still in the public or right-of-way count against the capacity cap, even if some vehicles are lost, broken, or non-functional.

Other Points


Cities should work collaboratively to build common open source tools to process the API and monthly data internally for analysis. Since data is a common format from the same scooter vendors, analysis tools should be able to be shared across jurisdictions.

Data Intermediaries

Good for many other use cases, but for scooter data it is unnecessary due to governance concerns, speed of data access, bottlenecks, gatekeeping concerns, control of companies, possible future costs/fees, private funding sources and influence, and concerns about transparency and about bypassing open records laws. Cities can and do handle sensitive data every day, have good controls in place for protection and privacy, and with scooter data there is no explicit PII.

Sharing with partner entities

Cities often partner with other entities to do transportation data analysis. County government, MPOs, state DOTs, and transit agencies may all benefit by working with mobility data. Cities should clarify their list of potential data sharing partners as part of the licensing process and ensure that any data license agreement preserves the right to share data. Mobility companies may try to restrict data sharing in ways the preclude important analysis with partners.

Resident Survey

An optional user survey designed by the city and distributed to users by the mobility companies (as a requirement of license) can provide valuable insight into behavior patterns, preferences, and customer satisfaction. Portland, OR’s survey offers a good model for this type of data collection.


Civic Analytics Network members:

Erin Dalton, Allegheny County

Brandon Crowley, Cincinnati

Julie Kanzler, DC

Dave Edinger, Denver

Eric Roche, Kansas City, MO

Sari Ladin-Sienne, Los Angeles

Michael Schnuerle, Louisville

Melissa Schigoda, New Orleans

Tim Wisniewski, Philadelphia

Laura Meixell, Pittsburgh

Maksim Pecherskiy, San Diego

Santiago Garces, South Bend

Erica Garaffo, San Jose

About the Author

Civic Analytics Network

Established with the support of the Laura and John Arnold Foundation, the Civic Analytics Network is a new national peer network of urban Chief Data Officers (CDOs). The Civic Analytics Network collaborates on shared projects that advance the use of data visualization and predictive analytics in solving important urban problems related to economic opportunity, poverty reduction, and addressing the root causes of social problems.

Email the author.