Software Analytics

How Software Analytics works

Software Analytics is an informational and analytical service that applies statistical models to live football match data and publishes estimates of the probability of upcoming outcomes.

Operating principle

The Service continuously tracks ongoing matches and collects live indicators: score, time, team statistics, and the movement of odds at the data source.

Statistical models are built on historical data — they describe which combinations of live indicators give an above-average probability for a particular outcome (a goal in a time window, a total, a half-time result).

At the moments when the current picture of a match matches one of these combinations, the Service publishes a signal indicating the outcome under consideration and the corresponding odds.

Live data source

The Service receives a stream of live indicators from an external data provider specializing in the real-time broadcast of sports statistics. The basic update rhythm is approximately one tick every five seconds: all ongoing matches are processed at this rate.

For every match the following are collected: current score, minute and status (1st half, halftime, 2nd half, finished), bookmaker's odds on the main markets (1×2, total, handicap), and team indicators — shots, shots on target, corners, fouls, possession, cards.

Before publishing a signal the Service additionally requests head-to-head history (H2H) and extended statistics on the current match. The final decision is made only after every independent source confirms that the algorithm's conditions are met.

Four algorithms

Each algorithm works in its own time window of the match and evaluates its own class of outcomes. The algorithms are independent — a single match can produce signals from several algorithms at different times.

λLambdaGoal in the first half

The algorithm analyzes the start of a match and assesses the probability that the teams will score at least one goal before halftime.

ΣSigmaNext goal

The algorithm assesses the pace of play and the scoring form of the teams in the second half, forecasting continued scoring.

τTauGoal in the second half

The algorithm analyzes the first-half score and the historical scoring form of the teams to assess the probability of a goal after halftime.

ΔDeltaGoal in the final minutes

The algorithm assesses the motivation of the leading team and the pace of the match in its final phase.

Algorithms — detailed breakdown

Each of the four algorithms is broken down below: the phase of the match it works in, the capture conditions, and the finalization principle.

Exact numerical thresholds, filter weights, and profile parameters are not disclosed in the public description: this is the competitively sensitive part of the method. The structure is open; specific values are validated through the open Win Rate and ROI metrics on the Results page, where the outcome of each signal is visible after the fact.

λ

Lambda (λ) — goal in the first half

The algorithm works at the start of a match and assesses the probability of at least one goal being scored before halftime while the score remains nil-nil.

Match phase
The start of the first half — the phase when live indicators have settled but the pace of play is still stable.
Score condition
Score is nil (0:0).
Odds
The odds on the first-half total line must fall within the algorithm's operating range.
Additional filters
Capture is possible only in the first half; the league must be open for Lambda. Additional filters on the odds and match state are applied on the server side.
Finalization
The signal is finalized at halftime or the start of the second half. It is considered a hit if the teams scored at least one goal before halftime; otherwise it is a miss.
Profiles
The algorithm supports several profiles that differ in the pre-match ratios of 1×2 and total odds. Each profile has its own historical Win Rate and ROI statistics available on the Results page.
Σ

Sigma (Σ) — next goal

The algorithm works in the second half and assesses the probability of another goal in a match that is already productive.

Match phase
Closer to the end of the second half — the phase when the pace has settled and both teams have already scored.
Score condition
At least two goals have been scored in the match in total.
Odds
The next-goal odds must fall within the algorithm's moderate operating range.
Additional filters
Capture only in the second half; rare scenarios of total dominance in the first half are excluded; certain score configurations at the moment of capture lower the signal's priority.
Finalization
The signal is finalized at the end of the match. If the teams score at least one goal after the capture moment — the signal hit.
Profiles
The base signal works without a profile and goes into the archive marked "Base". Several profiles are also published — sub-samples of matches with more stable historical Win Rate.
τ

Tau (τ) — match total

The algorithm works at the very start of the second half (HT capture) and assesses the likely overall total of the match — how many goals there will be by the final whistle.

Match phase
The first minutes of the second half — right after halftime, while the second half has not yet produced any goals.
Score condition
A low-scoring first half without a significant lead; no goals yet in the second half.
Odds
The odds on the chosen total line must fall within the algorithm's operating range.
Additional filters
The total line is chosen by the bookmaker from a standard range; head-to-head history with a consistently high average total is taken into account; the match must run without red cards at the time of capture.
Finalization
The signal is finalized at the end of the match. On whole totals, if the actual total exactly matches the line, the signal is marked as a push (refund) and is excluded from both Win Rate and ROI.
Profiles
The algorithm supports several profiles that isolate sub-samples with especially stable historical Win Rate. A profile breakdown is available on the Results page.
Δ

Delta (Δ) — late-game goal

The algorithm works in the closing phase of a match and assesses the probability of another goal once the score leader has emerged.

Match phase
The final phase of the match — when the score structure has settled and about twenty minutes remain in the game.
Score condition
The match has a score leader (not a draw).
Odds
The next-goal odds must fall within the algorithm's moderate operating range.
Additional filters
Capture only in the second half; the score leader must not be an overwhelming favourite — its win probability must fall within a moderate range; sufficient head-to-head history is required; the match must run without red cards at the time of capture.
Finalization
The signal is finalized at the end of the match. If any team scores after capture — the signal hit.
Profiles
Delta has no profiles: the strategy makes the entire decision based on the composition of conditions, without sub-classification.

Comparison table

A summary of the key characteristics of the four algorithms in one table — match phase, half, market, and whether profiles are used. Exact numerical parameters are intentionally omitted (see the note above).

AlgorithmMatch phaseHalfMarketProfiles
λ LambdaStart of 1H1stOver 0.5 first halfseveral
Σ SigmaEnd of 2H2ndNext goalbase + several
τ TauStart of 2H2ndMatch totalseveral
Δ DeltaLate game2ndNext goal—

What profiles are

A profile is a category of pre-match conditions under which an algorithm has historically shown different levels of predictability. Different profiles can apply to the same signal depending on the relationship between the pre-match odds.

When publishing a signal the Service indicates the matched profile (e.g., P1, P2, and so on — by the number of profiles for the specific algorithm). This lets the user understand how typical the picture of the algorithm is in the current match.

Quality metrics

Every signal in the Service archive comes with metrics that let you evaluate the historical effectiveness of the algorithm and profile.

Win Rate (WR)

Share of hits out of all completed signals. The basic measure of an algorithm's accuracy.

ROI

Average return on a hypothetical flat stake. Unlike WR it accounts not just for hit frequency but also for the size of the odds.

Coverage

Share of signals with a full set of live statistics available for post-match analysis. The higher it is, the more reliable the statistical conclusions.

Push (refund) — when it applies

A push is a case where the actual outcome on a whole total exactly matches the line. On the betting market this means the stake is refunded — no win and no loss.

At Software Analytics a push applies only in the Tau algorithm and only on whole match totals: 1.0 (exactly one goal in total) and 2.0 (exactly two goals). On fractional totals (0.5, 1.5, 2.5) a push is impossible by definition — the line cannot equal a whole number of goals.

When calculating ROI and Win Rate, refunded signals are excluded from both numerator and denominator — they affect neither return nor accuracy. In the archive and tables such signals are marked with the letter P.

How we calculate Win Rate and ROI

All numbers on the Results page are calculated using a simple, verifiable formula — without smoothing or Bayesian correction.

Win Rate is the share of hits out of total completed signals: WR = W ÷ (W + L). Pushes (P) are not counted in the numerator or denominator. Pending signals (not yet finalized) are also excluded — while a match is in progress, the signal does not affect statistics.

ROI is the return on a hypothetical flat 1-unit stake per signal. For a hit, the return equals the odds taken; for a miss, zero. ROI = (sum of all returns − number of signals) ÷ number of signals. Pushes return 1, which is equivalent to excluding them.

Example: 100 completed signals, of which 60 hit at average odds of 1.65 — that's a 60% Win Rate. ROI = (60 × 1.65 + 40 × 0 − 100) ÷ 100 = −1%. A positive Win Rate alone does not guarantee a positive ROI: the difference in average odds can outweigh accuracy.

Aggregation by period (week / month / all time) uses the same definition. All values on the page are raw observed frequencies, so the user can judge the degree of uncertainty by sample size.

Signal lifecycle

Every signal passes through four stages — from appearance to fixing the result.

1
Capture

The algorithm detects a match between the current picture of the match and a statistical pattern, and publishes a signal with the odds.

2
Tracking

While the signal is active, the Service records changes in the odds and stores the peak value.

3
Finalization

After the match ends or the signal's time window closes, the Service records whether the considered outcome occurred.

4
Result

The signal is marked as a hit (W), a miss (L), or a push (P, for specific cases on whole totals).

Which leagues are excluded and why

Some leagues and tournaments are automatically excluded from the algorithms' work. The main reasons: incomplete statistics from the data provider (no shots and corners), small historical sample, unstable live odds movement, or administrative closure due to systematically low predictability.

The block list is maintained separately for each algorithm: the same league can be open for Lambda and closed for Sigma — that is normal, because different algorithms use different subsets of data and respond differently to source quality.

For the user the main point is this: a Software Analytics signal is an already-filtered event on top of which the algorithm has run its assessment. Tournaments that fail the quality filter never enter the Service.

How we avoid overfitting

The main risk of any backtest approach is finding pretty numbers on the historical sample that do not hold on new data. Software Analytics uses several techniques to reduce that risk.

Out-of-sample validation. Each algorithm's parameters (minute windows, odds thresholds, score filters) are tuned on one slice of historical data and verified on another that the algorithm did not "see" during tuning. Only if the out-of-sample metrics are comparable to in-sample are the parameters locked in.

Minimum sample size. Profiles are considered stable only after several hundred signals have accumulated. Below that threshold a profile is marked "insufficient data" and the user sees only the base Win Rate of the algorithm.

Regular recalibration. Roughly every three months the statistics for each algorithm are reviewed. If a systematic divergence from historical expectations appears on the fresh sample — parameters are revised or the algorithm is temporarily paused.

Method limitations

The Service publishes probabilistic estimates based on historical patterns, but that does not make the forecasts certain. Below are the main limitations worth knowing.

It is not a prediction for a specific match. The algorithm speaks about a statistical probability, not a fixed outcome. Over the horizon of dozens of signals the numbers settle, but any outcome is possible in any single match.

Bookmaker margin (overround). The bookmaker builds a margin into the odds. This means that even on a fairly assessed 50/50 probability the odds will, on average, be lower than the theoretically fair 2.00. A positive Win Rate therefore does not equal a positive ROI.

Volatility over short periods. Win Rate over a week can differ noticeably from Win Rate over all time. That is normal statistical fluctuation — judging the quality of an algorithm makes sense over samples of several hundred signals or more.

Coverage. The algorithms are designed for tournaments with regular teams and sufficient statistical history. Friendlies, youth tournaments, and non-standard formats (for example, tournaments at neutral venues without spectators) are excluded automatically.

Glossary of terms

Short definitions of the key terms used in the Service and on the Results page.

Signal
A record published by an algorithm specifying the match, capture moment, selected market, and odds. A signal has a validity window, and when the match ends it receives status W (hit), L (miss), or P (push).
Profile
A category of pre-match conditions in which the algorithm has historically shown a different Win Rate. The profile is determined before the match starts based on the relationship between 1×2 and total odds. Some algorithms support profiles; the list and statistics for each are published on the Results page.
Odds peak (live coef peak)
The maximum odds value observed within the signal's active window. Used in the archive as an additional metric — how much the line moved in favour of the chosen outcome.
Push (refund)
A case where the actual outcome on a whole total exactly matches the line. Applies only in Tau on totals 1.0 and 2.0. Pushes are excluded from ROI and Win Rate calculations.
Win Rate (WR)
Share of hits out of all completed signals: WR = W ÷ (W + L). The basic measure of an algorithm's accuracy.
ROI
Return on a hypothetical flat 1-unit stake per signal. ROI = (sum of all returns − number of signals) ÷ number of signals. Accounts not just for hit frequency but also for the size of the odds.
Trimmed mean
The mean of a sample after cutting off the extreme ends. In Tau it is applied to the average total of head-to-head matches and helps cut bimodal and rarely-scoring histories where the ordinary mean is distorted by outliers.
H2H (head-to-head)
Statistics of previous matches between two teams. In Tau and Delta it is used as a filter before publishing a signal: the algorithm requires a sufficient number of matches and specific properties of their totals.
Blocked league
A tournament excluded from a specific algorithm's work. Reasons — missing full live statistics, small historical sample, unstable odds movement, or administrative closure.
Capture window
The phase of the match during which the algorithm can publish a signal. Each algorithm has its own phase: Lambda works at the start of the first half, Tau at the start of the second, Sigma closer to the end of the second, Delta in the closing minutes.

Frequently asked questions

Is this a sportsbook?

No. Software Analytics is an informational and analytical service. We publish statistical estimates of outcome probabilities but do not accept bets, do not act as an intermediary, and are not a financial advisor. The user makes any betting decisions on their own with their chosen bookmaker.

Can I make money on these signals?

The Service does not guarantee a profit. All published Win Rate and ROI numbers are historical observed statistics, not a promise of future returns. A positive historical ROI does not mean the next series of signals will be profitable.

Why is the ROI on some algorithms negative?

This is a normal situation for a series of limited size. The bookmaker margin makes the market slightly negative by default, and any algorithm has to clearly overcome it. On short samples a negative fluctuation is also possible — we publish the numbers as is, without smoothing.

How many signals per day?

On average across all four algorithms — about 5-30 signals per day, depending on the density of the football calendar. On weekdays and in the off-season — fewer; on weekends with many matches — more.

How often are results updated?

The Results page updates in real time as signals are finalized — that is, at the moment matches end and time windows close. Changes in Win Rate and ROI are reflected within a few minutes of the event.

What is a profile and do I need to understand it?

A profile is a category of pre-match conditions (the ratio of 1×2 odds and the total) under which the algorithm has historically shown a different Win Rate. You don't need to know the profile — the base signal works without it. Profiles are published as additional information for users who want to filter signals by historical sub-samples.

On which devices does the Service work?

Software Analytics is a web app (PWA) that runs in any modern browser. It can be installed as an app on iPhone (Safari → Share → Add to Home Screen) and on Android (Chrome → Install). Push notifications about new signals are supported in most browsers, except older versions of iOS.

What the Service does not do

  • does not accept bets and does not act as an intermediary in their placement;
  • is not a financial or investment advisor;
  • does not guarantee the forecasted outcome — the forecast is a probabilistic estimate;
  • is not responsible for decisions made by the user based on the published information.