Follow these guidelines to make sure you meet data quality benchmarks and create the best experience for Transit users.
Access your QA results
You can access QA results of your Realtime feed in the Transit Data Sharing Portal. This daily validation report contains information about your data quality metrics and includes troubleshooting help.
Know the essential quality metrics
To help maintain reliable Transit information for Google Transit users, there are 3 key quality metrics for real-time data:
- Quality: What users need
- Stability: When users need it
- Coverage: Where users need it
1. Quality
We work hard to maintain strict adherence to the community-driven General Transit Format Specification (GTFS) to optimize user experiences. Learn more about our standards in our GTFS Github archive. If your information deviates from the GTFS Realtime specification, the warning and blocking errors are listed in the validation report. This includes:
- Inconsistencies with the underlying static feed
- Format and accuracy of entities
- Presence of required fields
- Time ranges matching expected values from the static feed
Learn more about feeds and entities in the GTFS Realtime reference sheet.
Tolerances and expectations
- Tolerance for warnings and errors as a percentage of affected entities is 2% and 0%, respectively. Additional details are available in the validation report.
- A regular, stable, and cyclical distribution for feed entities over time is expected, without spikes or drops in the number of feed entities (e.g., number of vehicles).
- Service alerts require proper language, consistency, and cause and effect information.
Troubleshooting
Issues with tolerances and expectations can lead to incomplete or inaccurate data shown to users This often blocks launches. Possible causes and fixes are mentioned in the report. Learn more about monitoring your Realtime feeds.
2. Stability
We require a consistent, weekly inflow of data feeds via data pushes and pulls to provide the best experience for users. Downtime is expected during setup and system improvements, but Realtime systems must remain stable and provide parsable data through the year (including weekends and public holidays).
Server uptime errors
Google monitors incoming feeds for stability over 8-16 days. Errors in data formats and corrupt protobuffers count as failed pushes or pulls (e.g., no ASCII in production). From the daily validation report, we expect to find instances of 1% or below for the following types of server uptime errors:
- Protobuf errors (format and parsing)
- Fetcher errors
Several failed fetches in a row lead to poor user experiences and get flagged, block launches, and cause feed suspension.
Feed age
Feed timestamps are used to compute Feed age and are measured in seconds since epoch (UTC). A feed age shouldn’t be older than 90 seconds when we receive it. Feed age for Service Alerts can be up to 10 minutes.
3. Coverage
Transit provides users with complete, on-ground information for their trips. Specifically, Transit aims to provide:
- Trip updates
- Complete data for areas near city centers and high-traffic areas
- Updates on most trips from the static feed, especially busy and central routes (full and partial coverage)
- Accurate and up-to-date data through service alerts and Vehicle Positions wherever possible