How to Build and Evaluate an MLB Betting Model

To build a probability model for one MLB market, first define the outcome, settlement rules, and prediction cutoff. Use only information available by that cutoff, create a simple baseline, evaluate predictions on later games, and compare the estimated probability with the available odds. Calculate expected value and stake size only after that evaluation—and treat both as conditional calculations, not promises of profit.

Probability, a winner prediction, and a favorable price are different things. A model estimates the probability of an outcome; a prediction selects an outcome; comparing probability with price shows whether modeled expected value is positive, assuming the probability estimate is sound.

Choose one outcome and a prediction cutoff

Start with the MLB moneyline market, and specify exactly which outcome the model will predict and when it will make that prediction.

Before preparing the data, record:

• Target outcome: the selected team wins under the rules of the specific market.
• Settlement rules: the operator’s conditions for postponements, suspended games, starting-pitcher changes, and other exceptions.
• Prediction cutoff: the timestamp after which new information cannot be used for that prediction.
• Unit of observation: one game and one selected outcome.
• Comparison price: odds for the same outcome and settlement rules, available at the prediction cutoff.

Keep MLB moneyline separate from the run line. A run line model needs a target that incorporates the offered handicap. A totals model needs a target tied to the specific total-runs line. A win-probability model does not automatically provide probabilities for those markets or for player props.

Freeze a pregame data snapshot

For every historical prediction, preserve the information available at the chosen cutoff. Information appearing in a database today was not necessarily available before the game.

Useful records include the game identifier, prediction timestamp, source of each feature, availability timestamp, and missing-data flag. For the starting pitcher, lineup, and bullpen, record what was actually known at that time.

Retrosheet provides historical game and event records. Comparing a model with prices requires a separate odds archive. Without suitable historical prices, you can evaluate probability forecasts, but you cannot reproduce historical betting returns at those prices.

Handle missing values using a rule established in advance. Do not replace a lineup that was unknown at the prediction cutoff with the actual game lineup: that introduces future information.

Build a simple baseline and meaningful features

For the home-team moneyline market, start with a repeatable educational recipe. Normalize historical Retrosheet game records into one row per game, with a binary label of 1 for a home-team win and 0 for a home-team loss. These records provide game data, not sportsbook odds.

Set a prediction cutoff for each game. Calculate each team's win percentage using only completed prior games strictly before that cutoff. Use one initial feature: the home team's win percentage minus the away team's win percentage. Specify how to handle missing values, such as when a team has no prior games.

Split the data chronologically: an early training period, a later validation period, and a final held-out test period. Use explicit date or season boundaries to accommodate MLB's irregular schedule. The simplest baseline assigns every game the home-win frequency in the training data. Next, fit logistic regression on the win-percentage difference and obtain the home-win probability through predict_proba, selecting the column for class 1. The LogisticRegression documentation describes this probability-estimation method; it does not establish the model's performance on MLB games.

Keep every feature calculation strictly before its game's cutoff. Fit imputation and any other data-dependent preprocessing on the training period only, never using future outcomes to construct features. Compare settings on validation data and reserve the test period for the final evaluation. This is an educational baseline, not a strategy with validated profitability. Compare more complex models and additional features, including the metrics below, against these starting points.

Player statistics can be features, but they are not ready-made betting probabilities:

• Expected weighted on-base average (xwOBA) is a Statcast measure of batting-event value based mainly on exit velocity and launch angle. It is not win probability. See the MLB xwOBA definition for its scope.
• Fielding Independent Pitching (FIP) is an ERA estimator based on strikeouts, walks, hit-by-pitches, and home runs, under average balls-in-play and timing assumptions. It is not an outcome probability; see the FanGraphs FIP explanation.
• Expected FIP (xFIP) uses a similar framework but replaces the home-run-to-fly-ball rate with a league-average rate. That is a distinct assumption, not another name for the same estimate; see the FanGraphs xFIP explanation.

Define the calculation window for historical features in advance. Each row must use only events completed before its prediction cutoff. No “best” algorithm or universal feature set is established here: their usefulness must be evaluated on held-out data.

Interpret park factors by metric and time window

Use a Statcast park factor as an index of park effects for a particular metric and time window—not as a universal multiplier for a single-game run projection.

The official Baseball Savant leaderboard with 2025 selected and a three-year window covers 2023–2025. It lists these values for Coors Field:

An index of 100 represents average for the selected metric. The comparison adjusts for players and handedness; the different metrics are not interchangeable.

Official English Baseball Savant screen showing Statcast park factors

Original English-source capture from Baseball Savant, with 2025 selected and the three-year 2023–2025 window.

Do not directly multiply a single-game run projection by a value in this table. A park factor describes an aggregate relationship under a specific methodology. If you include it as a model feature, its implementation and usefulness need the same chronological evaluation as other features.

The full 2023–2025 window also cannot be used for an early prediction within that period: it includes later events. Historical evaluation requires a version of the statistic that was available at the relevant cutoff.

Evaluate on later games without data leakage

Split the data chronologically: use an early period for training, the next period for tuning, and a later holdout period for final evaluation. Randomly shuffling games does not reproduce forecasting the future.

Follow this sequence:

1. Define period boundaries by date or season.
2. Prepare features and train the model on the early period.
3. Use the next period to select settings and, if needed, a probability-calibration method.
4. Freeze the final model.
5. Generate predictions for the later holdout period without using its outcomes for tuning.
6. Compare models on the same games, outcomes, and prediction cutoffs.

For repeated historical evaluation, apply the same sequence so that training uses only information from before each evaluation period.

Do not assume that splitting by row order is automatically appropriate. The TimeSeriesSplit documentation specifies equally spaced samples for comparable test periods. MLB games occur irregularly, so define custom date- or season-based folds explicitly.

Check especially for these sources of leakage:

• Lineups published after the cutoff.
• Later confirmation of the starting pitcher.
• Actual weather substituted for information available at the time.
• Statistics containing the game being predicted or later events.
• Closing odds substituted for the price available at an earlier prediction cutoff.
• Data transformations fitted on the entire dataset.

Compare the model with at least a simple baseline and an odds-derived baseline, where prices at the same cutoff are available. If you use one outcome’s raw implied probability without removing bookmaker margin, state that limitation.

Evaluate probability quality separately from profit

Use a probability-calibration curve, Brier score, and log loss to assess forecasts. None of these diagnostics alone proves that betting will be profitable.

Definitions and calculation methods are available in the documentation for probability calibration, Brier score, and log loss.

Compare scores on the same target and sample. For a calibration curve, report the number of observations in each group so readers can assess how stable the observed relationship may be. No universal quality threshold or sufficient sample size is established here.

If you change the model after examining the later holdout period, that period has become part of development. An independent final evaluation then requires a subsequent, unused period.

Compare probability with odds: example 1

With hypothetical decimal odds of 2.00 and a model probability of 55%, the probability-point difference is +5 percentage points, while expected return on stake is +10%. These are different measures.

For decimal odds, raw implied probability is one divided by the odds. It represents the price of one outcome before removing bookmaker margin—not an established “true” probability.

A winning payout at decimal odds of 2.00 includes the returned stake; net profit equals the stake. A loss forfeits the stake. That is why the winning component of the EV formula uses odds − 1.

The denominator for expected return here is the stake at risk, not the bankroll or payout. A difference of +5 percentage points does not mean a return of +5%.

This calculation assumes two settlement outcomes: a full win or a full loss. Other possible settlements must be accounted for separately. The 55% probability is hypothetical: this is neither a prediction for a specific game nor a betting recommendation.

The odds converter helps obtain implied probability and compare odds formats. American odds are a separate way of expressing a price, not a separate type of probability. The converter performs calculations but does not validate a user-entered model probability. See the expected value glossary for more on interpreting EV.

Enter an explicit bankroll and Kelly fraction: example 2

With odds of 2.00, probability of 55%, an explicit $1,000 bankroll, and quarter Kelly, the calculator capture shows a $25 stake. Enter bankroll separately; do not infer it from a wager amount or the number of wagers.

In the corresponding controls of the Kelly calculator, enter:

• Odds: 2.00.
• Probability: 55%.
• Bankroll: $1,000.
• Kelly fraction: quarter Kelly.

For decimal odds, the full Kelly fraction is:

[p × (odds − 1) − (1 − p)] / (odds − 1)

Fractional Kelly reduces the resulting fraction. It does not correct a probability error or make a wager safe.

Applying expected return of +10% to the $25 stake gives $2.50 in EV before rounding. The interface displays $3, rounded to a whole dollar. This is neither expected payout nor realized net profit.

English Kelly calculator on localhost with a $1,000 bankroll and a $25 stake

Capture of the project’s English calculator on localhost, not the production site. For these inputs, displayed EV is rounded to a whole dollar.

In this calculator, the “edge” figure of +10% means expected return on stake, not the probability-point difference. Kelly stake sizing uses the explicit bankroll; expected return uses the stake as its denominator.

The calculator implements arithmetic using the inputs supplied. It does not evaluate the model, validate the 55% probability, or guarantee profit.

Decide what the evaluation actually supports

Treat the result as an evaluated procedure for estimating probability, not a promise of winning. Comparing with prices is meaningful only when you can reconstruct the data and prediction at the chosen cutoff.

Before applying the model, check that:

• The target and settlement rules are unambiguous.
• Pregame snapshots contain no future information.
• Model and baseline forecasts were compared under the same conditions.
• The later holdout period was not used for tuning.
• Probability calibration and forecast scores were assessed separately from financial results.
• EV was calculated using an available price.
• Bankroll was explicit, and stake and EV rounding were understood.

Closing line value (CLV) can provide an additional diagnostic: compare the obtained price with the closing price for the same market and settlement rules. CLV is not a measure of realized profit, and closing prices must not enter features for an earlier prediction.

If you are considering the less likely team, the MLB underdog betting strategy concerns outcome and price selection; it does not replace probability evaluation.

Even positive modeled EV depends on the quality of the estimate and can accompany losses. A credible model reports more than a probability: it records when the estimate was made, what information was available, how it was evaluated, and which assumptions govern the calculation.