For the complete documentation index, see llms.txt. This page is also available as Markdown.

Predicted End Times

Many events don’t have end times, which is critical information for our transport and on-demand customers. For example, for sports events, around 80% or more of source event data doesn’t have a known end time.

This is usually because end times for a sports game or a concert are recorded after the event finishes. Yet many of our transport customers need a Predicted End Time for future scheduled events (which means providing the end time before the event finishes).

The end time and duration of an event is a key piece of information for event data. The goal of this feature is to increase our end-time coverage.

The Predicted End Times feature uses machine learning and our intelligent algorithms to predict event end times. The goal is that you can use the Predicted End Time where an actual known end time is not present.

Predicted End Times covers a subset of categories which are sports, concerts, and performing arts.

For sports events Predicted End Times covers eight sports (American football, Basketball, Baseball, Ice-hockey, NASCAR, Soccer, Rugby, and Australian rules football).

For performing arts and concerts events all performing arts events that don't have an actual end time have a predicted end time.

You can use Predicted End Times in these example use cases:

  • Workforce Optimization: For transportation companies if you want to arrange transportation for people leaving an event you can use Predicted End Times.

  • Demand Forecasting: When forecasting the impact of events in certain time periods the end time of the event is required.

How Predicted End Times are calculated

We use a combination of methods, and the availability of historical data largely determines which ones we use. For event types with historical data, we use machine learning methods including linear regression and quantile regression.

For sports, these models use features such as gender, season, and leagues. For event types without historical data, we use research-based methods e.g. using the mean, using track and series estimates for NASCAR. As a result, our predictions for these events may be less robust. Across all sports types, we cover Professional, College, and International types, where applicable.

Category
Type
Professional sport
College sport
International sport
Non-sport

Sport

Ice-hockey

Model-based

Research-based

Model-based

N/A

Sport

Rugby

Model-based

Model-based

Model-based

N/A

Sport

Basketball

Model-based

Research-based

Research-based

N/A

Sport

Australian Football

Model-based

Model-based

Model-based

N/A

Sport

American Football

Model-based

Model-based

Research-based

N/A

Sport

Football/Soccer

Research-based

Research-based

Research-based

N/A

Sport

Baseball

Model-based

Research-based

Research-based

N/A

Sport

NASCAR

Research-based

Research-based

Research-based

N/A

Performing arts

All

N/A

N/A

N/A

Research-based

Concerts

All

N/A

N/A

N/A

Research-based

Predicted End Times in PredictHQ API

The Events API supports the Predicted End Times feature through the following:

  • You can sort events on the Predicted End Time value by using the sort parameter with a value of predicted_end or -predicted_end.

  • You can filter on Predicted End Times by specifying a date range with the predicted_end.* parameter.

  • The Events API returns the Predicted End Time as the predicted_end field in the events response data. This field is present only if an actual end time is not available for the event and we have a Predicted End Time. The predicted end date of the event in ISO 8601 format.

Note: The Predicted End Time and all other start and end times are in UTC if the event time zone is provided, and in local time otherwise. For example, Independence Day falls on the 4th of July regardless of the timezone and has a null time zone.

How to use the API

If an event does not have a valid end time then the predicted_end field is present in the response. To use Predicted End Times you can implement logic that checks if the predicted_end field is present. The logic should be: - If the predicted_end field is present then use predicted_end field value for the event end time. - If the predicted_end field is not present use the end field for the event end time.

You can also use the sort parameter to sort by the end time and the predicted_end where needed.

Note:

  • A Predicted End Time is a predicted value, not an actual end time value. It is based on various machine learning models and statistical methods. We aim to have good accuracy on average but there is a margin of error in the value. Take this into account when you use the value.

  • For events that don’t have an end time the Events API sets the end time to the start time in its response.

Examples

Event with a Predicted End Time

This event has a predicted_end field in its response:

Event with a scheduled end time

This event has an actual end time and no predicted_end field:

Last updated

Was this helpful?