The devil in the data details

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.

What makes a good GBFS feed?

🔍 Discoverability

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.

📡 Reliability

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.

💯 Quality

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.

🔐 Freedom of use

Non-restrictive terms: Some operators impose policies that limit GBFS use to real-time display of vehicles in apps and prohibit additional types of data usage or storage, while other operators are less restrictive. Liberal terms of use give advocates, academics, and the media the freedom to store and analyze GBFS data to evaluate their city’s shared mobility services.

Methodology

We looked at the availability of 40 feeds from eight different operators between April 25, 2022 at 2 PM ET and May 2, 2022 at 2 PM ET to calculate uptime. We used this same list of eight operators to look for feeds that are restricted without an authentication key, to determine if the feed was using the latest version of the GBFS specification, and to examine terms of use.

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.

👎 Outdated versions of GBFS

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.

👎 Limiting access with authentication keys

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.

👎 Restrictive terms of use

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

What you can do

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

✔️ Ensure that GBFS terms of use do not include restrictions on storage and analysis of vehicle availability data

✔️ Become involved with the continued development of GBFS through MobilityData’s work on the specification at mobilitydata.org

Have questions? Want to learn more? Curious what Transit’s data team has learned about the quality of your GBFS data? Drop us a line at partners@transitapp.com.