Micromobility data sharing is the structured exchange of trip and vehicle data between shared e-scooter and e-bike operators and the public agencies that regulate them, carried out through shared open specifications, chiefly the Open Mobility Foundation’s Mobility Data Specification (MDS) and MobilityData’s General Bikeshare Feed Specification (GBFS). A rider unlocks a scooter, the operator starts emitting records, and the city receives them through an interface it can actually query. That is the whole mechanism, and the rest is policy, plumbing, and privacy.
This guide walks the process end to end for city staff, developers, and mobility providers. It covers what gets collected, how it travels, which standards make it usable, and what usually goes wrong.
Key takeaways:
- Micromobility data sharing is a regulated data exchange between private operators and public agencies, not a public dataset by default.
- Two specifications do most the work: GBFS describes where vehicles are, MDS describes what happened and lets a city set digital policy.
- MDS 2.0 collapsed the old Agency and Provider APIs into one specification, so the only real difference now is push versus pull.
- Geospatial trip traces can identify a person, so most programs aggregate, de-link, or truncate that data before it is stored permanently.
- Program Requirements, introduced in MDS 1.2, are how a city states its required versions and endpoints in machine-readable form.
Table of Contents
- What Is Micromobility Data Sharing?
- What Data Do Micromobility Operators Collect?
- How Does the Data Move Between Systems?
- Which Standards Make the Data Usable?
- How Micromobility Data Sharing Works Across Organizations
- How Do Cities Use Shared Micromobility Data?
- How Is Privacy and Security Protected?
- What Makes a Data-Sharing Program Work?
- What Are the Common Barriers?
- Frequently Asked Questions
- What is included in micromobility?
- How does bike sharing work?
- What does shared mobility mean?
- What is another word for micromobility?
- What is the difference between MDS and GBFS?
- Do micromobility companies have to share trip data with cities?
What Is Micromobility Data Sharing?
Micromobility data sharing is the practice of moving operational and trip records from shared micromobility operators to the agencies that own the sidewalk, curb, and bike lane those vehicles use. Without it, a dockless scooter is a private device parked on public ground, and the city has no way to count it, cap it, or move it.
Three terms get mixed up in this space. Shared mobility is the broad category covering anything rented by the trip or the hour, including cars and vans. Shared micromobility narrows that to low-speed, low-mass vehicles, mostly bikes and scooters. Mobility as a service goes further, describing a single interface that bundles transit, micromobility, and other modes into one payment and one trip plan.
The organizations involved are consistent. Operators run the fleets and own the raw records. Public agencies hold the right-of-way permit. Cities, counties, and transit authorities consume the data for permits, device caps, parking enforcement, and service planning. Third-party aggregators sit in the middle, and their role matters more than most explainers admit.
Aggregators exist because a city with eleven operators would otherwise maintain eleven integrations. A provider registers a global identifier in the Open Mobility Foundation’s provider registry, the city contracts with one aggregator, and the aggregator holds a separate connection to each operator. That shortcut introduces a party who holds every operator’s data at once, which is a governance decision cities should make deliberately rather than by default.
What Data Do Micromobility Operators Collect?
Operators collect far more than they are required to share. The data that crosses into public hands is a smaller, deliberately shaped subset.
Vehicle and status records cover device identifiers, battery level, vehicle type, position, and whether a unit is reserved, active, disabled, or out of service. Telemetry adds a timestamped path so the system can reconstruct where a vehicle moved between two points, which is what makes geofencing and parking validation possible at all.
Trip records carry the start and end of a rental, the start and end coordinates, trip duration, distance, and the vehicle used. MDS 2.1 added a dedicated incidents and crashes endpoint, so injury reports can travel as structured records rather than free-text notes.
Operational records add parking events, charging and redistribution moves, service-area boundaries, and jurisdiction boundaries. Commercial records cover pricing, promotions, and fee calculations, which cities need when they charge per device or per trip. Fields vary considerably by operator and by version, so a data dictionary matters as much as the data itself.
A useful distinction is between shared operational data and rider-identifiable information. A device ID tied to a trip timestamp and a home address is not anonymous. The same trip with the trace shortened to a start and end zone is. Most programs share the first and restrict the second.
How Does the Data Move Between Systems?
Data moves in two directions, and only one of them is about reporting. The other is control.
Under MDS 2.x there is a single specification, and the practical distinction is push versus pull. With push, the operator posts records to the city. With pull, the city or its aggregator requests records on a schedule or on demand. MDS 2.0 unified the earlier Agency and Provider APIs, which previously forced cities into one model and operators into another.
Real-time and batch exchange sit side by side in most programs. Vehicle status and telemetry arrive continuously, because a city enforcing a slow zone or a no-parking zone needs current positions. Trip records usually arrive in periodic batches, since no one needs a completed trip the second it ends. Feeds often go to a third-party aggregator first, which normalizes them, then to the city platform, then into a warehouse, then onto a dashboard.
The return path is the one most blog posts skip. Digital policy travels from city to operator as machine-readable rules covering jurisdictions, geofences, speed limits, parking restrictions, and device caps. Version 2.1 moved further toward real-time digital policy and enforcement feedback, where a violation recorded on one side can generate a record on the other. That closes the loop between measuring behavior and changing it.
Which Standards Make the Data Usable?
A shared file format is not the same thing as a shared standard. A format describes how bytes are arranged. A standard also fixes field meanings, identifiers, update behavior, versioning, and the relationship between producers and consumers. Without those, a city ends up with a folder of feeds that each mean something slightly different.
Three specifications cover most of what a modern micromobility program touches.
| Specification | Maintained by | What it carries | Who mainly uses it |
|---|---|---|---|
| GBFS | MobilityData | Vehicle availability, position, battery, station and vehicle status | Trip planners, map apps, riders, city dashboards |
| MDS | Open Mobility Foundation | Trips, telemetry, vehicle events, parking, incidents, jurisdiction and policy endpoints | Public agencies and their data platforms |
| CDS | City open data partners | Aggregated historical records for analysis and publication | Researchers, journalists, public data portals |
GBFS answers where a bike or scooter is right now, and it is the most widely adopted of the three, with hundreds of services publishing to it. MDS answers what happened and what the city wants done about it, and it is the one written for regulation. CDS is the layer that gets published after aggregation.
Two MDS features are worth understanding even if you never touch the schema. Program Requirements, added in version 1.2, let a city declare required MDS and GBFS versions, endpoints, and fields in a machine-readable document, so a new operator learns the rules from a file rather than a PDF. Jurisdictions let a city define its territory and the operating rules that apply inside it, which is what makes geofencing auditable instead of arbitrary.
How Micromobility Data Sharing Works Across Organizations
Across organizations, micromobility data sharing runs on four repeatable moves. Operators package the records a permit requires, and nothing more. They expose those records through a governed interface with published terms, version numbers, and update expectations. Cities validate the feed against a documented field list, reject or flag bad records, and combine the accepted records with their own geography, permits, and policy. Authorized users then apply the result to a specific decision, with an audit trail showing which feed version produced which number.
Every handoff between those moves is where programs fail. A field that means end-of-trip in one feed and last-telemetry-fix in another will quietly corrupt a metric, and nobody notices for a quarter.
How Do Cities Use Shared Micromobility Data?
Once the data lands, the use cases fall into a handful of recurring groups.
Network and fleet planning covers service-area sizing, where to authorize operation, and how many devices to permit. Trip density, dwell time, and time-of-day patterns tell a city more than a count of vehicles ever will.
Curb and sidewalk management uses parking validation data to find which blocks accumulate scooters, where sidewalks are being blocked, and whether designated corrals are working. A city that has ignored this data is usually arguing about complaints rather than measuring outcomes.
Device caps and permitting enforcement work because geofencing generates events, not opinions. A cap set at 1,500 devices citywide becomes a live number once the jurisdiction feed reports vehicles entering the boundary.
Safety and incident analysis became materially better with MDS 2.1, since structured incident records can be mapped against corridors, speed limits, and lighting rather than read one report at a time.
Transit integration uses first- and last-mile patterns to place corrals near stations and to time rebalancing runs. Equity analysis looks at where service is absent, which is often the more useful question of the two. Capital planning, fee assessment, performance reporting, and public dashboards all draw on the same records without needing anything extra.
How Is Privacy and Security Protected?
The privacy problem is specific and well understood. A start point, an end point, and a timestamp is a location history, and location history identifies people with startling ease. Workplace, home, school, and medical visits are all inferable from it. NACTO and IMLA make the point plainly in their Managing Mobility Data guide: geospatial trip data is personally identifiable in practice, regardless of what a contract says.
That guide offers four principles that still frame most programs. Public Good means the data supports a real public purpose. Protected means it is secured and minimized. Purposeful means it is collected for stated uses rather than speculative ones. Portable means it does not lock a city into one vendor’s platform.
Alongside those sit the Privacy Principles for Mobility Data, developed by NUMA, the Open Mobility Foundation, and NABSA, which set out seven guiding ideas for both public and private sectors. And because most cities have no dedicated privacy staff, the Mobility Data Collaborative built the Mobility Data Sharing Assessment, a self-assessment tool a team can complete without hiring a specialist.
Technically, protection means data minimization, aggregation to zones before permanent storage, short retention limits for raw records, role-based access, and audit logs. The MDSA tool exists because of an important structural fact: the city can aggregate what it stores, and the operator cannot un-share what it has already sent.
What Makes a Data-Sharing Program Work?
The programs that survive past the pilot phase tend to share a short list of habits.
Clear ownership means one department is accountable for the feed, the contract, and the dashboard, rather than three each assuming another owns it. Documented fields means a published data dictionary that defines every required field, its type, its units, and how nulls behave. Reliable updates means a stated maximum interval, plus an alert when it is missed. Quality checks mean automated validation on arrival, with a rejection log, because a feed that silently degrades is worse than one that fails loudly.
Transparent permissions mean analysts can see who can query what, and why. Clear agreements define retention, breach notification, third-party access, and what happens to data when a permit ends. Staff capacity is the quiet one. A city that mandates feeds and then has nobody to reconcile them has built a compliance theater.
Open data publication comes last, deliberately. It happens after aggregation, and it is what turns a regulatory feed into a public asset. Portland’s Bureau of Transportation is the reference practice here: it collects only a portion of each trip, de-linked from the rest, so the record serves program management without reconstructing an individual’s movement.
What Are the Common Barriers?
Inconsistent fields across operators is the most frequent complaint, and it is rarely malicious. Two operators can both claim MDS compliance and still send different meanings for the same field.
Operators that never connect are a real operational risk. Some build the integration late, some subcontract it, and some argue the requirement is not a permit condition. This is why the requirement belongs in the permit and the ordinance, not only in a side letter.
Stale feeds look like working feeds. A dashboard with a week-old snapshot still renders charts, and a reader has no way to know. Publishing the last successful update time next to the map solves most of this for a few dollars of engineering.
Unclear governance causes the slowest damage. If nobody can say who may query raw trip data, or how long it is kept, or whether the aggregator may resell it, the program quietly accumulates risk that only surfaces during an audit.
Poor metadata and commercial concerns close out the list. Metadata problems mean a schema file that lists fields but not meanings. Commercial concerns are real, since operators see trip data as a business asset, which is why city staff lean on permit conditions and published policy rather than goodwill. The resolution is to ask for less, document exactly why, and let the operator see the aggregate use their data supports.
Frequently Asked Questions
What is included in micromobility?
Micromobility covers small, low-speed, low-mass vehicles used for personal travel, mostly shared bikes and e-scooters, plus mopeds, e-bikes, and manual four- and six-wheeled cycles. In city programs the term usually means the permit-holding shared fleet rather than privately owned devices. It excludes full-size cars, buses, and freight, which fall under separate shared mobility and commercial vehicle rules.
How does bike sharing work?
A rider finds a bike on a map, scans its code or uses an app to unlock it, rides, and ends the trip at a dock or a marked parking zone. The operator records a vehicle status change, a trip start, a telemetry path, and a trip end, then checks the parking location against local rules. Those same records are what the city receives through GBFS and MDS to count trips and enforce parking.
What does shared mobility mean?
Shared mobility is any transport service where people rent a vehicle for a trip or a period rather than owning it. It includes bike and scooter share, car share, ride-hailing, and microtransit. Shared micromobility is the subset limited to low-speed, low-mass vehicles, while mobility as a service describes bundling several of those modes behind one interface and one payment.
What is another word for micromobility?
The common synonyms are light micromobility, active micromobility, and micro-mobility, and the last is only a hyphenation difference. Some documents use small mobility or microtransit, though microtransit more often means a scheduled demand-responsive shuttle. No single alternative has displaced micromobility as the standard term in US city policy.
What is the difference between MDS and GBFS?
GBFS publishes current vehicle availability, position, and battery state so trip planners and map apps can show riders where things are. MDS is built for public agencies and carries trips, telemetry, parking, incidents, jurisdiction boundaries, and digital policy rules. In short, GBFS tells a rider where a bike is, and MDS tells a city what happened and what it wants to happen next.
Do micromobility companies have to share trip data with cities?
In most US cities, yes, because the permit or ordinance is written to require it, and operators need that permit to use the public right-of-way. Requirements usually name a specification version, an endpoint, an update interval, and a retention period. The data is typically aggregated or de-linked before storage, and a growing share is then published on open data portals for public use.
Start with the permit, not the dashboard. Decide what fields you need, name the MDS or GBFS version you require, publish that requirement as a Program Requirements document, and write a data dictionary before the first operator connects. The cities that get clean data are the ones that were specific about what they asked for on day one. Last reviewed for 2026; specification references follow MDS 2.1.0, MDS 2.0.2, and GBFS 2.0.
