Two DFS tools both project Aaron Judge at 9.4 DraftKings points tonight. Identical numbers. You'd think they're the same.
Tool A got there with a spreadsheet: season batting average times expected plate appearances times a park factor it hasn't updated since April.
Tool B got there with a trained model: 14 input features, rolling performance windows, real-time weather, opposing pitcher arsenal analysis, and a feedback loop that's been recalibrating all season.
Same output. Completely different reliability.
DFS projections are the foundation of every lineup decision you make. They determine which players your optimizer selects, which stacks get built, and how your lineups are constructed. A 0.5-point projection error on a single player doesn't seem like much — but multiplied across 10 roster spots and 20 lineups, small systematic errors compound into meaningful edge loss over the course of a season.
Most DFS players never look under the hood of their projection system. They see a number, assume it's reasonable, and move on to lineup building. But the method that produces the number is the real product. Two tools can output the same projection for a player tonight and have wildly different accuracy profiles over 500 games. The process matters. Here's how ours works.
WHAT GOES INTO
A SINGLE PROJECTION
Every player projection in DFS Only is computed from multiple categories of input data. None of these inputs alone is sufficient. The power comes from combining them in a model that learns which factors matter most and how they interact.
PLAYER PERFORMANCE — ROLLING WINDOWS
The most intuitive input: how has the player actually been performing? But the question is over what time period.
A full-season average is stable but slow. It doesn't capture the fact that a hitter has been on a 10-game tear or that a pitcher's velocity has dropped 2 mph over his last three starts. A 7-day sample is responsive but noisy — a 3-for-4 night can make an average hitter look like an MVP for a week.
DFS Only uses multiple rolling windows simultaneously. The model sees a player's performance over the last 7 days, the last 14 days, the last 30 days, and the full season. It learns how to weight each window based on which time horizon has been most predictive of next-game performance historically. Early in the season, when sample sizes are small, the model leans on longer windows and prior-year data. Mid-season, the shorter windows carry more weight because they better reflect current form.
The specific stats tracked per window include DraftKings fantasy points per game, isolated power, strikeout rate, walk rate, barrel rate, hard-hit rate, and plate appearances. For pitchers: fantasy points per game, strikeout rate, walk rate, ERA, WHIP, innings per start, and pitch velocity trends.
MATCHUP DATA — THE OPPONENT MATTERS
A hitter's projection should change based on who he's facing. A right-handed power hitter facing a soft-tossing left-handed pitcher with a high walk rate is a different DFS proposition than the same hitter facing a right-handed flamethrower with elite strikeout numbers.
Opposing pitcher quality: The model incorporates the starter's season stats, recent form (rolling windows again), handedness, and strikeout-to-walk ratio. A pitcher who walks a lot creates more baserunners, which means more RBI and run-scoring opportunities for opposing hitters.
Handedness splits: Left-handed hitters perform differently against left-handed pitchers than right-handed pitchers, and vice versa. The model uses platoon splits at both the individual and league-average level (blending the two when individual sample sizes are small).
For pitcher projections: The same logic runs in reverse. The opposing lineup's aggregate strikeout rate, power numbers, and recent form all factor into the pitcher's expected performance. A pitcher facing a lineup that strikes out 27% of the time projects differently than one facing a lineup that only strikes out 19% of the time.
CONTEXT — BATTING ORDER, VEGAS, ENVIRONMENT
Batting order position: A hitter batting 2nd gets more plate appearances than a hitter batting 8th. Over 9 innings, the difference can be a full plate appearance, which translates to roughly 15-20% more scoring opportunities. The model adjusts for this directly — same player, different lineup slot, different projection.
Vegas implied run totals: Derived from DraftKings sportsbook over/under and moneyline data. The implied run total for each team is the market's best estimate of how many runs that team will score. This single number captures information from hundreds of sharp bettors who have already evaluated the pitching matchup, the lineup, the park, and the weather. The model uses it as a strong prior for team-level offensive output.
Park factors: Every stadium has a scoring multiplier based on historical run-scoring data. These are seeded for all 30 MLB parks and applied at the game level.
Weather: Real-time temperature, wind speed, and wind direction data from Open-Meteo for all 30 stadium coordinates. Dome detection automatically bypasses weather adjustments for indoor games. Weather effects are applied as continuous adjustments, not binary flags.
HOW THE INPUTS
BECOME A PROJECTION
Once all the inputs are assembled for every player on the slate, the machine learning model takes over. The model is a trained function that maps inputs (player stats, matchup data, environmental factors) to an output (expected DraftKings fantasy points).
The key word is trained. Unlike a spreadsheet formula where a human decides that park factor should be weighted at 10% and opposing pitcher quality at 15%, the ML model learns these weights from data. It has been shown thousands of historical player-games — the inputs that were true before each game, and the actual DraftKings score that resulted — and it has adjusted its internal weights to minimize the gap between its predictions and reality.
This matters because the optimal weight for each input isn't obvious, isn't static, and isn't the same for every player type. Park factors might matter more for power hitters than contact hitters. Weather might matter more in certain stadiums. Opposing pitcher quality might be more predictive for certain batting order positions. A human analyst can't hold all these interactions in their head simultaneously. The model can.
A SPREADSHEET PROJECTION IS A HUMAN GUESS ABOUT WHAT MATTERS. AN ML PROJECTION IS THE DATA'S ANSWER TO WHAT ACTUALLY MATTERS.
The model doesn't just produce a single projection number. It produces a distribution — a floor (10th percentile outcome), a projected value (expected outcome), and a ceiling (90th percentile outcome). These three numbers define the range of plausible DraftKings scores for a player on a given night, and they're what feed the Monte Carlo simulation engine.
A player with a projected value of 9.0, a floor of 2.0, and a ceiling of 28.0 is a high-variance play — boom or bust. A player with a projected value of 8.5, a floor of 5.0, and a ceiling of 16.0 is a low-variance play — consistent but capped. Both might look similar on a projection-only tool, but the simulation treats them very differently because it's modeling the full range of outcomes, not just the center.
WHY ML PROJECTIONS
GET BETTER OVER TIME
This is the most important difference between a machine learning projection system and a static one. Static projections use the same formula all season. The weights don't change. The methodology doesn't adapt. If the formula undervalues weather by 3% in April, it still undervalues weather by 3% in September.
ML projections improve through a feedback loop. After every night of games, the system compares its projections to actual results. Every player, every game, every night — a continuous stream of new training data.
HOW THE MODEL LEARNS FROM EVERY GAME
Before the game: The model generates projections using all available inputs — rolling stats, matchup data, Vegas lines, weather, park factors.
After the game: Actual DraftKings scores are recorded. The model compares projected vs. actual for every player.
Error analysis: Where was the model most wrong? Was it systematically over-projecting hitters in cold weather? Under-projecting pitchers with high K rates? The errors reveal which input features need more or less weight.
Recalibration: The model's weights are adjusted based on the accumulated error data. Features that were underpredictive get more weight. Features that were noise get less.
Next game: The updated model generates new projections with the recalibrated weights. The cycle repeats.
Over the course of a full MLB season — roughly 2,400 games and 50,000+ individual player performances — the model sees enough data to calibrate its weights with high confidence. By August, the projection model is meaningfully more accurate than it was in April. By October, it's been trained on the entire season's worth of data and is operating at peak accuracy.
This feedback loop is why we track historical projection accuracy and expose it to users. It's not just a marketing metric — it's the mechanism by which the model gets better. Every time you see an "actual vs. projected" comparison, you're seeing the same data the model uses to recalibrate itself. Transparency about accuracy isn't just honest; it's how the system works.
PROJECTIONS ARE THE
FOUNDATION, NOT THE ANSWER
Here's the thing about projections that most DFS tools won't tell you: the projection itself is not what you should be optimizing around.
A projection tells you the expected value — the center of the distribution. But DFS tournaments are not won by expected values. They're won by the right tail of the distribution — the outcomes where everything goes right for a correlated set of players simultaneously. A projection of 9.0 tells you nothing about how often that player is part of a tournament-winning lineup.
That's why the ML projection is an input to the Monte Carlo simulation engine, not the final output. The projection, along with the floor and ceiling estimates, defines the probability distribution for each player. The simulation then draws random outcomes from those distributions — correlated at the team and game level — 100,000 times. The simulation results (sim win rates, leverage scores) are what actually drive lineup construction.
The projection system's job is to produce the most accurate distributions possible. The simulation's job is to find the optimal combinations within those distributions. The optimizer's job is to build salary-legal lineups from the simulation's output. It's a pipeline — each stage feeding the next.
FROM RAW DATA TO OPTIMIZED LINEUPS
Stage 1 — Data Collection: Player stats (MLB Stats API), Vegas lines (DraftKings sportsbook via Tank01), weather (Open-Meteo), park factors (seeded reference table), batting orders (daily lineups).
Stage 2 — Feature Engineering: Rolling performance windows, matchup quality scores, handedness splits, positional adjustments, environmental multipliers.
Stage 3 — ML Projection: Trained model generates projected points, floor, and ceiling for every player on the slate.
Stage 4 — Ownership Modeling: Separate model estimates projected ownership for each player based on salary, projection, matchup appeal, and market behavior patterns.
Stage 5 — Monte Carlo Simulation: 100,000 correlated game outcomes. Sim win rates and leverage scores computed.
Stage 6 — ILP Optimization: Integer linear programming builds salary-legal, stack-correlated, exposure-controlled lineups from the simulation output.
Stage 7 — Output: Optimized lineups with full player data — projection, floor, ceiling, sim win rate, ownership, leverage, value score — ready for CSV export to DraftKings.
WHY THE METHOD
MATTERS MORE THAN THE NUMBER
You might be wondering: if two systems both project a player at 9.0, does it matter how they got there?
Yes. Because a projection isn't a prediction about tonight. It's a process that runs every night for 180 nights. Over one night, any method can look right or wrong — baseball has too much variance for a single game to validate or invalidate a model. Over 180 nights, systematic errors compound. A model that's 0.3 points more accurate per player per night translates to 3 points more accurate per lineup per night, which translates to meaningfully better finishes across hundreds of contests.
The difference between a spreadsheet and an ML model isn't the output on any given night. It's the error rate over the season. Spreadsheets have fixed errors — whatever the analyst got wrong in April stays wrong all year. ML models have shrinking errors — whatever the model got wrong in April gets corrected by the feedback loop in May.
This is also why projection accuracy tracking matters. If you're using a tool that doesn't show you how its projections have performed against actual results, you have no way to evaluate whether the projections are good, bad, or getting better. You're trusting a black box with no accountability. A tool that shows you its track record is a tool that's confident enough in its process to let you judge the results.
PROJECTIONS ARE
THE ENGINE UNDER THE HOOD
You don't need to understand gradient descent or feature engineering to use DFS Only. The projections are there when you open the tool — every player, every number, every matchup factor already computed and ready. You can build lineups without knowing or caring how the math works.
But if you're the kind of player who wants to understand why you should trust a projection — or why one tool's projections might be systematically better than another's over the course of a season — the answer is in the method. Machine learning that trains on real data, adapts through feedback, incorporates 14+ features per player, and produces full probability distributions instead of single-point estimates is a fundamentally different beast than a spreadsheet with fixed formulas.
The projection is the number you see. The model is the reason you can trust it. And the feedback loop is the reason it gets better every week you use it.
ML PROJECTIONS THAT
LEARN ALL SEASON.
14+ features. Rolling windows. Real-time weather. Feedback loop. Accuracy tracking. First day free.
See Tonight's Projections →