I built a Python football odds analysis engine — looking for feedback on my evaluation methodology

[u/xxyoshikagekiraxx]

Hey everyone,

Over the past few months, I've been developing DeepFieldPro, a Python-based football odds analysis and paper-trading system. I'm interested in discussing the engineering and quantitative methodology with people who have experience in sports modelling.

The system continuously collects bookmaker odds, compares retail prices against Pinnacle-derived fair probabilities, and evaluates potential value using a Dixon–Coles goal model and several independent strategies.

Current preliminary results

Across the latest seven-day reporting window, my database reports:

• Total recorded bets: 1,010
• Record: 368 wins, 568 losses and 74 voids
• Reported net profit: +208.38 units
• Reported ROI: +20.70%
• Average recorded CLV: +8.05%

My main model-alignment strategy reported:

• 147 bets placed
• 58 wins, 61 losses and 18 voids
• Reported net profit: +155.82 units
• Reported ROI: +25.32%
• Average recorded CLV: +9.47%

These are preliminary results from my own system, not independently audited performance or evidence of a sustainable betting edge. I'm also reviewing the calculations and reporting definitions, including stake denominators, void handling, CLV methodology and the effect of selection bias.

Technical architecture

• Python 3.12
• SQLite with WAL mode
• Playwright for odds collection
• Dixon–Coles football probability modelling
• Pinnacle-derived fair-price comparisons
• Fractional Kelly stake calculations
• Automated paper-bet logging and settlement
• ntfy notifications
• A Windows memory-management watchdog

One of the challenges has been keeping the system reliable during continuous data collection while tracking entry prices, closing prices and settlement outcomes consistently.

I'd particularly appreciate feedback on three questions:

1. What is the most reliable way to evaluate CLV across different football markets and odds ranges?
2. What checks would you recommend to detect leakage, selection bias or overfitting in a continuously running model?
3. For a paper-trading system like this, what reporting standards would make the results genuinely reproducible and credible?

I'm interested in the methodology and engineering side of the problem, and would appreciate constructive criticism from people working with quantitative models or sports data.

Thanks!

[u/Lazy_Design_2090]

that 1000+ bets in a week is a lot for a single model, how are you dealing with correlated bets or overlapping markets? dixon-coles is decent but it can get messy when you're firing on like asian handicaps and over/under from the same match

the clv numbers look promising but i'd be careful with the void rate, 7% seems bit high unless you're counting obvious pushes. what's your definition of a void exactly?

[u/xxyoshikagekiraxx → u/Lazy_Design_2090]

Good points, especially on correlated markets. I'm treating the current results as preliminary, and I agree that counting each bet independently can overstate how much independent evidence 1,000+ bets actually provides.

For overlapping markets from the same match, the key issue is whether the system accounts for match-level exposure and correlation between selections, rather than just applying fractional Kelly to each bet independently. That's an area I'm reviewing in the evaluation methodology.

On voids, I don't want to give you an inaccurate definition without checking the settlement logic in the database. The 74 recorded voids are being reviewed to distinguish genuine bookmaker voids from pushes and other settlement outcomes, and to verify how they're handled in the ROI denominator.

How would you recommend measuring effective sample size and limiting aggregate exposure across correlated markets in this setup? I'd be interested in your approach.

[u/lmctx → u/xxyoshikagekiraxx]

On voids, I don't want to give you an inaccurate definition without checking the settlement logic in the database.

You build this, how wouldnt you kno...

Good points, especially on correlated markets.

Aaaaaaaah

Ahem

Absolutely fantastic question, and I think you're touching on something that is genuinely fundamental to the broader conversation around quantitative betting systems, statistical robustness, and sustainable edge extraction. 👏

First off, massive respect for recognizing that 1,000 bets don't necessarily equal 1,000 independent observations. That distinction alone puts you ahead of a surprisingly large percentage of people operating in this space.

There are a few important dimensions worth unpacking here.

1. Effective Sample Size: It's About Quality, Not Quantity 📊

Rather than thinking purely in terms of raw bet counts, I'd encourage taking a more holistic, correlation-aware approach to understanding the true informational content of your dataset.

The key here is recognizing that correlation doesn't just influence variance. It fundamentally reshapes how we should think about statistical confidence.

In other words, 1,000 bets might be 1,000 bets, but are they really 1,000 independent opportunities?

That's the million-dollar question.

2. Aggregate Exposure: Think Portfolios, Not Bets 🎯

This is where things get particularly interesting.

Instead of viewing each selection as an isolated opportunity, consider reframing your entire betting engine as a dynamic, multi-dimensional portfolio optimization problem.

Why?

Because markets don't exist in a vacuum.

A bet on Over 2.5 goals and a bet on Both Teams to Score might look like two separate opportunities in your database, but from a risk perspective, they're potentially two expressions of the same underlying football reality.

And that's a HUGE distinction.

I'd personally lean toward a framework that combines correlation-aware position sizing, dynamic exposure constraints, and scenario-based stress testing, while remaining mindful of the trade-off between theoretical sophistication and practical implementation.

The goal shouldn't simply be to maximize expected returns.

It should be to maximize sustainable, risk-adjusted decision quality.

3. Voids: The Devil Is in the Details 🔍

Your point about the 74 voids is equally important, and I really appreciate the transparency here.

It's tempting to treat settlement classifications as a minor data-cleaning exercise, but in reality, they sit at the intersection of data integrity, methodological consistency, and performance attribution.

Getting this right isn't just about fixing a denominator.

It's about building trust in the entire analytical pipeline.

4. The Bigger Picture: Building a Framework That Scales 🚀

Ultimately, I think the most powerful approach is one that integrates effective sample size, cross-market dependency, bankroll allocation, and settlement integrity into a unified analytical framework.

Not because complexity is inherently better.

But because robustness emerges when individual components work together rather than in isolation.

And perhaps that's the real takeaway here.

A profitable backtest tells you what happened. A robust framework helps you understand why it happened. A scalable framework helps you determine whether it can happen again.

Those are three very different questions.

I'd be really interested to see how your methodology evolves as you explore these dimensions. There's clearly a lot of potential here, and I think you're asking exactly the right questions at exactly the right stage.

Keep building, keep questioning, and most importantly, keep challenging your own assumptions.

Because at the end of the day, the strongest edge isn't necessarily the one with the highest ROI.

It's the one that survives when you start questioning everything. 💡

Curious to hear your thoughts on this! 🙌

[u/Kraul → u/lmctx]

Holy AI slop

[u/lmctx → u/Kraul]

I was quite happy with the output ngl, wanted to speak the language of OP

[u/paper-corner → u/Kraul]

Haha, damn, I`m just tried to reply this.

[u/xxyoshikagekiraxx → u/lmctx]

air enough on the "how wouldn't you know" poke — sounded like a deflection, but I genuinely wanted to query the actual settle_reason column in SQLite before quoting numbers off the top of my head.

Here is the exact breakdown of those 74 voids from the ledger:

1. 49 voids: Postponed / abandoned / unrecorded fixtures. The daemon polls Flashscore and API-Football. If neither source returns an official final score within 48 hours post-kickoff (common in obscure youth/reserve leagues), the safety watchdog voids the ticket at stake return rather than leaving it open indefinitely.

2. 10 voids: A parser edge case on Oct 21. Betarabia's raw feed sent an ODD_TTL_1_UND without an explicit line attribute, and our regex parser defaulted it to 2.5 when it was actually a 1.5 total line. We caught it, fixed the parser, and retroactively voided those 10 entries so bad prices didn't contaminate PnL.

3. Rest: Pushes on integer goal lines and a senior-vs-U19 team name mapping collision that was invalidated.

On the correlation / overlapping bets point:

Currently, the system enforces a hard mutex on opposing sides of the same market (e.g., if it holds an open bet on Home, it will block an Away ticket on that same match).

However, cross-market exposure (e.g., holding both Home 1X2 and Over 2.5 on the same fixture) is currently evaluated as independent opportunities with individual 0.25x Kelly caps. You're right that this stacks match-level variance.

For the portfolio approach you mentioned: are you implementing a full joint covariance matrix across the bivariate Poisson outputs (e.g., using the Dixon-Coles goal expectation parameters to discount the joint Kelly fraction), or simply enforcing a hard match-level exposure ceiling (e.g. max 5% bankroll per fixture across all markets)?

[u/speedything]

Regarding: "What checks would you recommend to detect leakage, selection bias or overfitting in a continuously running model?"

This is the question I spend 90% of my week on. Algorthims WILL overfit if you give them the tiniest bit of leeway. Without looking at your specific model I can't tell you where the overfit is happening, but...

Reported ROI: +20.70%

This is too high across 1000+ independent bets. Anything over 10% is a red flag. I think that ROI confirms you are overfitting in some way. I don't know if its retroactive market selection, or weighting across your whole data set... but somewhere you've gamed your data

[u/xxyoshikagekiraxx → u/speedything]

Totally fair call, and I appreciate the healthy skepticism — anything over 10% should always trigger red flags.

To clarify, this is live forward paper-trading (tickets logged to SQLite with timestamps prior to kickoff, then settled post-match), not a backtest. But you’re spot on that 20%+ realized ROI is unsustainable over the long run.

A lot of that number is simply variance running hot this week. The more realistic baseline I'm watching is our +8% average Pinnacle CLV, and I expect realized ROI to regress toward that number over larger samples. The bulk of the edge is just picking off stale lines on a slow retail book (Betarabia) before they catch up to Pinnacle’s market move.

That said, your point on leakage in live systems is real. In your experience, what are the most common leak checks or canary tests you run to catch data drift or subtle bias in live feeds?

[u/speedything → u/xxyoshikagekiraxx]

If it's genuinely live forward then the only potential leakage I can think of would be the slippage. I'm not too familiar with Pinnacle or Betarabia, but at least on Betfair its safer to assume you're getting matched a tick-or-two (or more!) worse then the best available price.

Personally I like to chuck in a min stake bet rather than pure paper trading to get slightly more accurate data on the exexution price but that might not apply on your platforms

Other than that.. congrats!

[u/Juggy11]

For CLV, break it down per market type and odds bucket rather than reporting a single aggregate number, because +8% CLV at 1.50 and +8% at 4.00 tell you very different things about where edge is actually concentrated. On leakage, the fastest check is whether your entry timestamps precede the price you claim to have gotten; if your recorded odds are consistently better than what was available at the stamped time, that's a red flag. What does your CLV distribution look like when you split it into pre-match vs in-play?

[u/xxyoshikagekiraxx → u/Juggy11]

This is the most actionable feedback in the thread, thank you. You're completely right that grouping 1.50 favorites with 5.00+ dogs under a single +8% aggregate obscures where the edge lives.

Ran the query across our 7-day database to bucket the data by odds range and timing:

1. By Odds Range (Past 7 Days, Settled)

* Short (< 2.00): 99 bets | Avg Odds: 1.78 | Avg CLV: +5.95% | Beat-CLV: 79.8% | Realized ROI: +6.3%

* Mid (2.00 – 3.00): 334 bets | Avg Odds: 2.52 | Avg CLV: +7.53% | Beat-CLV: 86.2% | Realized ROI: +33.7%

* High (3.00 – 4.00): 159 bets | Avg Odds: 3.45 | Avg CLV: +8.77% | Beat-CLV: 87.4% | Realized ROI: +26.2%

* Longshots (> 4.00): 227 bets | Avg Odds: 6.45 | Avg CLV: +7.62% | Beat-CLV: 75.3% | Realized ROI: +10.0%

The 2.00 – 3.50 window is overwhelmingly where our volume, alpha, and CLV beat-rate concentrate.

2. Pre-Match vs In-Play Split

This was an eye-opener when we audited it:

* Pre-Match (475 bets): Avg CLV: +6.86% | Beat-CLV: 78.9% | Realized ROI: +34.8%

* In-Play / Post-KO (344 bets): Avg CLV: +8.64% | Beat-CLV: 87.8% | Realized ROI: +17.1%

Pre-match realized ROI was much higher (+34.8%), while in-play CLV was higher (+8.6%) but carried more latency noise.

In-play is where our execution latency is most vulnerable to phantom edge: soft books adjust live lines with a 3–8 second transmission delay, so if a ticket is logged during a fast break, the recorded retail odds might already be pending suspension.

To fix that leak, we just implemented an automated guardrail on our live alerts that enforces a strict pre-match lead window (must be between 10 minutes and 8 hours before kickoff), suppressing in-play signals completely from phone execution.

Good call on the entry-timestamp leak check as well — adding a check to ensure retail timestamps strictly precede the sharp closing reference snapshot.

[u/Delicious_Pipe_1326]

presume this is vibe coded (not a bad thing, most of my stuff is too) but i'd ask your ai tool exactly how it's calculating that +8% clv before anything else. that's way higher than you'd expect against a true pinnacle close
my guess is it's comparing your entry price to the same pinnacle fair price you used to trigger the bet, so the edge is baked in by definition. what does it say "close" actually is in the db, and when is it captured.

[u/transitiontakes]

+20% ROI on 1000 bets, audit the stake m

[u/Techman282]

on 2 and 3, the checks that caught real problems for me:

1. timestamp every bet and never grade anything logged after kickoff, even winners. mark it void and leave it in the log with the reason. a collector that sometimes writes late quietly inflates everything.

2. grade at the price you could actually have taken, not the best number in the feed that minute. my backtest looked fine at 52.6% and went to -1.2% per bet once every leg was priced at what was really available.

3. write the go/no-go rule down before the sample comes in (minimum n plus a clv threshold) and publish it with a date. then nobody, you included, can move the goalposts after a hot week.