EnglishEspañol

Data

Introduction

Shared micromobility vehicles are producing a wealth of data and information that cities will need to fully understand the impact of these services on everything from operations to planning to equity.

Cities did not act quickly enough to set data-sharing standards when transportation network companies (TNCs) arrived almost a decade ago. With these new services still in their infancy, cities still have the opportunity to avoid repeating this mistake and require the data that will better inform their decisionmaking.

To do so, cities will need to set clear data-sharing requirements for operators that identify what information they’re seeking, how it will be managed and stored, the quality, accuracy, format and frequency of the requested data, as well as determine privacy guidelines for its collection, storage and usage. Additionally, the definition of personally identifiable information (PII) is rapidly changing and varies considerably from jurisdiction to jurisdiction, so it will be important for cities to be clear about what their city and state consider PII and how best to manage and protect those data.

National Standards

All local governments developing shared micromobility policies should include these general provisions to ensure that their regulations address these issues similarly across communities.

  • 1

    Fleet API

    Cities should require public application program interfaces (APIs) - a software intermediary that allows two applications to talk to each other - with data from all companies to allow the city to monitor and enforce fleet operations and other regulatory requirements.

  • 2

    Data Format

    Ideally cities should strive to require and utilize an authenticated, standardized API, such as the General Bike Share Feed Specification (GBFS) or Mobility Data Specification (MDS) formats. But some cities may still need to request data in .xsl, .csv, or another format the city requests.

  • 3

    Historical Ride Activity Data

    Cities should require operators to provide historical ride activity data on a regular basis as determined by the city.

  • 4

    Privacy

    Cities should create strict data privacy practices and requirements from providers including:

    • Compliance with city, state and federal privacy standards;
    • The prioritization of data collection from vehicles over users, especially location based data;
    • A clear policy of protecting personally identifiable information from public disclosure without prior aggregation or obfuscation;
    • The use of the service shouldn't be tied to access to personal data or device;
    • Opt-in requirements for access to any element of a user's device including camera, contacts, or location;
    • Operators should clearly articulate the data they are collecting from users and explain why they are collecting it;
    • A prohibition on the sale of data to third party entities.

  • 5

    GPS Tracking

    Vehicles should "ping" their location every 90 seconds and make the data available to the city and all location data released to the city over the operator's API should come from the vehicle and not the user's GPS.

Back To Top

Policy Sections

Data Ownership

Cities are able to access more data than they ever have before with the introduction of so many new mobility services. But, along with this new data comes new responsibilities to determine how it should be stored for aggregation and analysis.

Governing Agency

Requested data is provided to the governing agency directly.

Pro

Lots of control over data and analysis; avoids conflicts over transferring data from one party to another and any related legal requirements.

Con

Entity may not have the experience or capacity to manage, analyze or secure this data effectively; could create privacy issues in jurisdictions that have open records laws.

Third-party

Requested data is provided through a third party such as an academic institution, non-profit, or data analysis platform.

Pro

Entity is likely built for this purpose; greater ability to manage, analyze and secure data; may ameliorate privacy concerns; may offer value-added analysis tools to aid the city in interpretation of the data and its use for enforcement, evaluation and planning purposes.

Con

Could create less control over the data and its uses; may create funding issues; could create vendor lock-in or a continual reliance on a subscription to access the data; in an academic setting, could suffer from matriculation related turnover issues.

Methods Of Collection

As cities track the use of these services, they will need to develop a clear sense of the data they need to collect and ensure operators are able to provide it.

Real-time Data

Real-time data is information that is delivered immediately after collection.

Pro

Up to the minute information on what’s happening across the community; effective for real-time compliance and enforcement; Can be provided via API for city or third-party analyses platforms.

Con

Entity may not have the capability or capacity to manage real-time data; could create privacy issues in jurisdictions that have open records laws; must be continually collected and archived to use for historical analyses.

Case Study

Austin, TX
Austin's rules states that the licensee shall provide the Director or a Director-authorized third party, with real time and historical information for their entire fleet through a documented web based application programming interface (API). The licensee is directly responsible for providing the API key to the Director and shall not refer the City to another subsidiary or parent company representative for API access. The API shall deliver data according to the most current Director authorized specifications, in a manner that protects individual user privacy. Austin's Final Director Rules for Deployment and Operation of Shared Small Vehicle Mobility Systems

Historical Activity Data

Activity data provide a greater depth of insight into the utilization of micromobility services.

Pro

Allows for a deeper analysis of trends including trip data, ridership, maintenance and safety issues, and others.

Con

Entity may not have the capability or capacity to manage data; could create privacy issues in jurisdictions that have open records laws; does not provide data for daily operations and management.

Survey Data

Survey data comes from the result of directly engaging and surveying users.

Pro

Can get qualitative feedback on services and operations; can ask questions on demographic data or other information that may not be collected by operators due to privacy concerns; will require staff time and resources to work with operators to develop survey.

Con

Can be time consuming and costly to manage; should be limited to once per permit renewal period or annually, whichever is less frequent.

Case Study

St. Louis, MO
Bike Share operators must be willing to distribute a customer survey, to be provided to the City of St. Louis, to all users and non-users at a maximum frequency of yearly. St. Louis' BikeShare Program Permit Requirements

Recommendations

Cities should require regular and frequent (weekly/monthly) activity history reports in order to have up-to-date information on how these services are operating in their communities. Real-time data on vehicle availability and operations should also be available via API for use by the city or third-party analysis platforms.

Cities should require vendors to conduct user surveys on a frequent and regular basis to better understand how riders are using the service, who is using it, and gather qualitative information on how it could improve. Cities should work collaboratively with vendors in order to formulate questions for the survey that will be helpful in understanding the impact of the shared services and to distribute it to riders and users. Cities may also choose to partner with academic institutions and operators to formulate a survey.

Cities should also consider using a standard approach to data collection across cities, such as Los Angeles’ Mobility Data Specification, to develop a consistent set of data they want from operators when negotiating any data sharing agreements.

Data Verification

With so much data available and questions of data efficacy in the recent past, it will be important to create processes to verify the received data is accurate and reliable.

National Household Travel Survey Verification

Conducted by the Federal Highway Administration, the National Household Travel Survey (NHTS) is the only source of national data that allows one to analyze trends in personal and household travel. It includes daily non-commercial travel by all modes, including characteristics of the people traveling, their household, and their vehicles.

Pro

The NHTS provides high quality data to verify operator collected data against.

Con

The NHTS is only conducted every 10 years and, therefore, will be out of date most years.

Regular Data Audits

A data audit is to assess the data quality or utility for a specific purpose. These audits should be designed to audit compliance with datasharing requirements without sacrificing exposure of personally identifiable information.

Pro

Direct and clear way to validate data.

Con

Can be time consuming and expensive.

Case Study

San Francisco, CA
Permittee agrees to make its policies, procedures and practices regarding data security available to the SFMTA, upon request, and further agrees that the SFMTA reserves the right to hire a third party to perform a security audit mid-way through the permit term, or at any time SFMTA determines that an audit is warranted. San Francisco's Powered Scooter Share Permit Terms and Conditions

API

Pro

Can use up to the minute information on what is happening.

Con

Does not provide complete picture of everything city will want to see.

Recommendations

There isn’t a clear and generally agreed upon standard for cities to be sure the data they’re receiving is accurate. Cities should work with other jurisdictions, data-focused nonprofits and academic institutions to conduct data audits regularly and determine the best methods for insuring accuracy and efficacy.

Cities should include provisions to revoke permits for any company that fails to provide data, fails to provide data as requested, or that knowingly provides inaccurate data.

Back To Top

Potential Data to Collect

While there isn't a wholly codified mobility data standard yet across the country, Los Angeles’ Mobility Data Specification (MDS) and the General Bikeshare Feed Specification (GBFS) are rapidly evolving and offer the most promise for standardized data collection and analyses between cities and private mobility operators.

Similar to a common language, and inspired by GBFS and the General Transit Feed Specification (GTFS), the Mobility Data Specification (MDS) is a data standard and API specification for municipalities to help ingest, compare and analyze mobility provider data to actively manage private mobility providers, such as dockless bikeshare, e-scooters, and shared ride providers who work within the public right-of-way. The specification is a way to implement real-time data sharing, measurement and regulation for municipalities and mobility providers. It is meant to ensure that governments have the ability to enforce, evaluate and manage providers.

Under the North American Bikeshare Association’s leadership, GBFS has been developed by public, private sector and non-profit bike share system owners and operators, application developers, and technology vendors. GBFS is intended as a specification for real-time, read-only data—any data being written back into individual bikeshare systems are excluded from this specification. GBFS is an open specification, developed and maintained by the community of producers and consumers of GBFS data. The specification is not fixed or unchangeable.

Below is a sample of the types of data that can be collected and analyzed through MDS and GBFS.

Fleet Data
  • Provider ID
  • Provider Name
  • Device ID
  • Vehicle ID
  • Days in service
    1. Date entered
    2. Exited service
  • Vehicle Type
    1. Bicycle
    2. Stand up scooter
    3. Scooter
    4. Moped
    5. Other
  • Propulsion Type
    1. Human
    2. Electric Assist
    3. Electric
    4. Combustion
  • Event Type (what is the status of the vehicle?)
    1. Available
    2. Reserved
    3. Suspended
    4. Removed
  • Event Time
  • Latitude
  • Longitude
  • Charge or Battery Percent
Trip Data
  • Provider ID
  • Provider Name
  • Device ID
  • Vehicle ID
  • Vehicle Type
    1. Bicycle
    2. Stand up scooter
    3. Scooter
    4. Moped
    5. Other
  • Trip ID
  • Start Time
  • End Time
  • Trip Duration
  • Trip Distance
  • Route information (including start and end location)
  • Parking Verification URL (A URL where the city view a photo of the parked vehicle)
  • Standard Cost (The standard cost to perform the trip)
  • Actual Cost (The actual cost paid by the customer)
Parking Data
  • Provider ID
  • Provider Name
  • Device ID
  • Vehicle ID
  • Vehicle Type
    1. Bicycle
    2. Stand up scooter
    3. Scooter
    4. Moped
    5. Other
  • Latitude
  • Longitude
  • Report Time
  • Reporter (who reported the status?)
    1. Vendor
    2. Public
    3. City
    4. Other
  • Report Type (what was the report about?)
    1. Obstruction
    2. Parking
    3. Idle
  • Action Time (how long did it take for the operator to respond?)
  • Action Type (what action did the operator take to resolve?)
    1. Reparked
    2. NoAction
    3. Lost
    4. Irretrievable
    5. Rider Moved
Maintenance Data
  • Provider ID
  • Provider Name
  • Device ID
  • Vehicle ID
  • Vehicle Type
    1. Bicycle
    2. Stand up scooter
    3. Scooter
    4. Moped
    5. Other
  • Latitude
  • Longitude
  • Report Time
  • Reporter (who reported the maintenance need?)
    1. Vendor
    2. Public
    3. City
    4. Other
  • Report Type (what needs maintenance?) (It will be necessary to create a codified list of all the potential reasons for maintenance for all vehicle types)
  • Suspend Time
  • Action Time
  • Action Type
    1. Repaired
    2. Removed
    3. NoAction
    4. Lost
    5. Irretrievable
    6. Moved
Incident Data
  • Provider ID
  • Provider Name
  • Device ID
  • Vehicle ID
  • Vehicle Type
    1. Bicycle
    2. Stand up scooter
    3. Scooter
    4. Moped
    5. Other
  • Incident Time
  • Latitude
  • Longitude
  • Incident Location
    1. Travel lane
    2. Bike lane
    3. Sidewalk
    4. Other
  • Reporter
    1. Vendor
    2. Public
    3. Police
    4. City
    5. Other
  • Vehicle Action
    1. Repaired
    2. Removed
    3. NoAction
    4. Lost
    5. Irretrievable
  • Injury
  • Police Report
  • Police Report Number
Back To Top
Table of Contents
General Provisions Operations Equipment & Safety Parking & Street Design Equity Communications & Community Engagement Data Metrics