Service Metrics by Stop

Swiftly has a dataset that makes it easier to understand stop coverage and stop data quality called Service Metrics by Stop. It can be found in the Download Center as shown in the screenshot below:

Service Metrics by Stop generates a CSV data export with metrics at the stop-level based on the route and date filters as well as the aggregations selected under the "Group By" option.

With Service Metrics by Stop, users can understand the split of all scheduled stops given a time period to quickly evaluate data coverage and quality:

• Percentage of Observed Stops (column pct_observed_stops): stops for which Swiftly observed a departure data (or arrival data if it's the last stop of the trip). In an ideal world, we would love to have 100% in this category, but we know transit operations are complex and this is not always the case.
• Percentage of Missing Stops that are explained via Service Adjustments (pct_stops_explained): missing stops that a Swiftly user intentionally canceled or skipped via Service Adjustments.
• Percentage of Missing Stops that are unexplained (num_missing_stops_unexplained): Missing stops that Swiftly never recorded a stop for and there was no Service Adjustment applied to skip that stop. This field provides Swiftly's Service Adjustments customers with historical metrics of service cancelations. 

Pie chart created using Service Metrics by Stop dataset to evaluate data quality

Missing Stops: unexplained vs. explained

A missing stop is “explained” if there was an explicit cancelation via the dashboard triggered by a bulk cancelation or a user interaction. An intentional cancelation happened using Swiftly's Service Adjustment features. 

Situations where a missing stop is “explained”:

• A user cancels a trip or a block
• A user closes a stop
• A user creates a detour and closes a stop as a result
• A user duplicates a trip AND later, that duplicated trip is canceled by applying a second Service Adjustment

Situations where a missing stop is “unexplained”:

• A user duplicates a trip and the Swiftly algorithm does not assign a vehicle to it. As a result, there is no arrival or departure for the stops of the added trip. All stops will be missing_unexplained
• A user adjusts the departure time (via Modify departure time adjustment). Even if the departure time has changed, if the algorithm does not record an arrival or departure , that is considered “unexplained” because nothing indicated to the system that we should not expect any arrival or departure observation.

Agencies without Service Adjustments

If your agency does not have Service Adjustments, there won't be any missing stop explained. All stops no recorded in Swiftly will be unexplained. Therefore, column num_stop_explained will be always 0.

Columns pct_oberverd_stops and pct_stops_explained will display the same value. 

Use cases

The report has filters on the left to select your download parameters. Below you'll find a list of different use cases that you can use the Report for.

You'll find the proposed filter selection and sample charts that were created based on data exports using the Service Metrics by Stop data exports. 

1. Understand the split of all scheduled stops given a time period to quickly evaluate the impact of skipped stops with service adjustments, missing stops, and explained stop data.

Group By: Empty to get it at the agency-level. (This is the default value)
Group By: Route short name to get it at a route-level

Chart to identify routes with missing data

2. Identify potential issues with a stop, such as vehicles stopping at a different location (stop is badly located) or Operators skipping consistently a stop. Sort column pct_stops_explained in ascending order to spot the stops with the least observations.

Users can compare stops across the network. Column pct_stops_explained will enable users to identify issues with a stop across multiple routes easily.

Group By: Stop ID,Route short name to look at a Stop that is served by multiple Routes and look at the differences across all served routes

Group By: Stop ID,Direction ID to look at differences for a particular stop between 2 directions

3. Identify a trip with the wrong GTFS Shape: comparing the percentage of observed Stops by trip pattern will enable users to proactively identify inconsistencies within a specific shape and trip pattern.

Group By: Trip pattern ID

4. Identify specific day(s) of bad service over a selected time range: The ability to see the progress of the value pct_observed_stops by days or weeks will enable users to monitor the number of observed stops over time.

Group by: Service date to identify a particular day with missed data

Group by: Week to spot weekly trends for data coverage

Group by: Month to spot monthly trends for data coverage

Chart to identify daily trends for canceled data using group by SERVICE_DATE

5. Identify issues at the end/beginning of the trips. This is particularly relevant for agencies with transit centers or underground terminals.

Columns in the response num_missing_first_stops and num_missing_last_stops will indicate to users if there are any particular issues with the most problematic stops:

• missing departure observations at the first stop of a trip
• and/ or missing arrival observations at the last stop of the trip

Group by: Route short name,Direction ID to identify any issues with the first or last stops of the trip.

6. Identify issues with a faulty vehicle reporting system (malfunctioning GPS devices)

Users can compare num_observed_stops or pct_observed_stops across the different vehicles reporting to Swiftly. This will enable users to easily find out specific vehicle IDs that are capturing a low amount of Stops. This would be the case if the vehicle had a malfunctioning GPS device.

Group by: Vehicle ID to identify a particular vehicle with a big volume of missed data