You’ve reached the end of the line.
Evaluating GBFS feed quality for shared mobility services
Shared mobility succeeds when it’s easy to find and integrated with public transit. One of the best ways to do this is with GBFS, the open data standard that allows people to find available shared bikes, e-bikes, e-scooters, and even carshare vehicles.
GBFS has grown since it first launched in 2015 to help cities and operators ensure that all of their shared mobility services can be easily integrated with multimodal trip planning in apps like Transit or Google Maps. And it’s not just apps: GBFS is also used by academics, advocates, researchers, and mobility data managers like Ride Report and Populus to study shared mobility options and help cities make the most of these services.
According to the North American Bikeshare & Scootershare Association, 69% of cities in North America already require an open, public GBFS feed for shared micromobility services on their streets — and a growing number of companies are providing public GBFS feeds whether a city requires them or not.
But GBFS is more than a checkbox. Just as real-time transit countdowns are only helpful if they’re accurate and readily available, GBFS feeds need to be accessible, reliable, and high-quality so that shared mobility is properly represented in the multimodal mix.
If GBFS is going to live up to its promise, the devil is in the details. So let us be your guide. We’ll take a look at what makes a good GBFS feed, see how different feeds stack up, and explain what cities and operators can do to make sure their GBFS data is top-notch.
Our open approach to Mobility-as-a-Service brings together all modes and operators, making it simple for riders to take multimodal trips when they open Transit. The app already uses more than 180 shared mobility feeds across 130 cities, uniquely positioning us to evaluate quality and provide feedback about what makes an accessible, reliable, and high-quality data feed.
Listed in GBFS GitHub: To be GBFS-compliant, a feed must be listed in the systems.csv page of the GBFS GitHub repository so that GBFS consumers, including apps and researchers, can easily find and use the feeds. We looked at seven operators and found a wide range of compliance, with some listing nearly all available feeds while others listed some or even none at all.
No authentication keys: NABSA’s Data Good Practices for Municipalities advises against authentication keys, which require GBFS users to request permission from the operator before being granted access to a feed. Authentication keys limit access and slow down the process of ensuring that shared mobility is easily discoverable, yet we found they continue to be used by one major operator.
99.9% uptime: A feed’s uptime is crucial. If a feed is unable to achieve 99.9% uptime, there’s a good chance that it won’t be available when riders are looking for nearby services. We examined 40 GBFS feeds from eight different operators and found that nearly half were unable to achieve expected 99.9% uptime.
Using the latest version of GBFS: As GBFS has grown, apps and operators alike have contributed to its evolution. The latest version, GBFS 2.3, includes information about geofenced service zones, as well as standardized fields for various vehicle types like pedal bikes, e-bikes, and scooters. Having feeds use the latest version of the specification ensures that this information is easily available to riders.
Feed uptime during the one week examined in this data varies significantly by provider and even across different cities. While it’s not necessarily representative of uptime over a prolonged period, this data does show the importance of reliable GBFS feeds. Downtime has a real impact on people looking for shared mobility services: even an uptime of 84 percent, like we found for LINK in Seattle, means that the feed is down for 26.5 hours in a week, or the equivalent of more than one whole day. Ensuring 99.9% uptime is crucial to having a reliable GBFS feed.
After this report was published, LINK let us know that they had recently updated their infrastructure to address downtime issues. We performed another analysis of their data by looking at the period after the update, and found most of their feeds achieved 99.9% uptime.
A more recent analysis of GBFS feeds from Spin in July 2022 shows a 100% uptime. Spin reached out after this report was published to explain the lower-than-expected uptime we initially reported was a result of rate-limiting to protect its GBFS feeds against denial of service attacks. Spin has since allowed Transit’s servers to bypass these checks, but rate-limiting may continue to impact the the uptime experienced by other GBFS consumers that have not been allowlisted by Spin.
For GBFS feeds to be truly available, they need to be listed in a central location so GBFS users can easily find them. Fortunately, the systems.csv file of the GBFS GitHub repository acts as this central clearinghouse. However, not all operators post all of their feeds there: Bird posts only about one third, while Lime posts less than one quarter and VeoRide posts none at all.
GBFS is now up to version 2.3, which includes information about geofenced service zones, parking zones, and no-ride zones, as well as standardized fields for various vehicle types like pedal bikes, e-bikes, and scooters. Most scooter operators, including Bird, Lime, LINK, Spin, VeoRide, and Wheels, are up-to-date with the latest version of GBFS. But Lyft Bikes & Scooters, PBSC, and BCycle are still using modified versions of GBFS 1.0, which doesn’t represent the increased complexity of shared mobility systems and forces GBFS users to parse custom fields that represent vehicle types. As shared mobility becomes even more complex with additional vehicle types, service zones, hybrid systems, and vehicle information, it’s important to make sure that GBFS feeds are updated to match the latest version of the specification.
In our examination of major operators, only VeoRide requires authentication keys for its GBFS feeds, which force a GBFS user to contact the operator and request permission before accessing the feed. Authentication keys run counter to the spirit of open data requirements from cities: they slow down the process of ensuring that shared mobility is easily discoverable and make it more difficult for smaller actors, such as part-time app developers, students, and advocates, to access GBFS data.
In addition to being used by apps to display real-time availability of shared mobility services, GBFS provides a vital source of information to the public about services permitted to operate on city streets. Some operators, such as Lime and Bird, limit GBFS use to real-time display of vehicles in apps and prohibit additional types of data usage or storage. Others, like Spin as well as Lyft’s Citi Bike and Divvy systems, are less restrictive
Bikeshare in New York, NY: Advocates and journalists at Streetsblog used Citi Bike’s public GBFS feed to verify a sudden drop in the number of available bikes in September 2018. By comparing the drop to bikeshare systems in other cities, they identified a bike maintenance problem in New York and pressed the operator for service improvements.
Scooters in Chicago, IL: Academics at DePaul University’s Chaddick Institute for Metropolitan Development issued a report in August 2019 that used GBFS feeds to analyze how scooters were distributed across different neighbourhoods. The researchers found that while operators were deploying fewer vehicles than permitted by the city, they were meeting the city’s goal of equitably distributing available scooters in priority areas.
Having a successful shared mobility program involves more than just checking a box to say that a GBFS feed exists. For the program to succeed, GBFS data needs to be accessible, reliable, and high-quality. Fortunately, there are concrete steps that cities and operators can take:
✔️ Strive for 99.9% uptime for GBFS feeds through improved system monitoring
✔️ Use NABSA’s Data Good Practices for Municipalities and MobilityData’s GBFS and Shared Mobility Data Policy
✔️ Require and produce GBFS feeds that are compliant with the latest version of the specification
✔️ Have all GBFS feeds posted in systems.csv on the GBFS GitHub repository
✔️ Eliminate the use of authentication keys to restrict GBFS access
✔️ Become involved with the continued development of GBFS through MobilityData’s work on the specification at mobilitydata.org
From: we who ride the bus.
To: those who run them.
Because there’s nothing quite like New York in late December… except Miami
App expertise from Transit and operational know-how from Keolis delivers better rider outreach, innovative AV solutions, and more