How to Build an Early Live Tennis Model

Tennis is unusually well suited to in-play modelling because the scoring system is a finite set of states with known transitions. Every moment of a match can be described by the point score in the current game, the games in the current set, the sets won, and who is serving. From any of those states, only two things can happen next: the server wins the point or loses it.

That makes a Markov chain the natural first model. Give each player one number, the probability of winning a point on their own serve, and the probability of winning the match from any score follows from the rules alone. The simplest version assumes each point is independent and identically distributed given the server. That is not exactly true: Klaassen and Magnus, in a 2001 paper in the Journal of the American Statistical Association using Wimbledon point data, rejected strict independence but found the deviations small enough that the assumption remains a good approximation for many purposes. It is the right baseline to beat before adding anything more elaborate.

If the server wins each point with probability p, and q is 1 minus p, the probability of holding serve has a closed form. The server wins to love, 15 or 30 with probability p to the fourth times (1 + 4q + 10q squared). Otherwise the game reaches deuce, which happens with probability 20 times p cubed times q cubed, and from deuce the server wins with probability p squared divided by (1 minus 2pq).

As an illustration, a server with p of 0.65 holds about 83 percent of the time from 0-0. At 30-40, the same server must win the next point to reach deuce and then win from deuce, which gives about 0.65 times 0.775, or roughly 50 percent. One lost point moved the hold probability by about 33 percentage points. That sensitivity is why live tennis prices move so sharply, and why a model that is one point behind the real score is badly wrong.

These figures are illustrative arithmetic, not estimates for any player.

Sets and matches are built the same way, one level up. The cleanest implementation is a memoised recursion: a function that takes the full state (points, games, sets, server) and returns the probability that player A wins the match, calling itself for the two successor states. Each state is computed once, so the whole table for a best-of-five match is cheap enough to recompute after every point.

The details that cause bugs are the rules, not the maths:

• Tiebreaks have their own serve rotation: one point, then alternating pairs.
• Deciding sets differ by event. In March 2022 the Grand Slam Board announced, as a trial, a 10-point tiebreak at 6-6 in the final set at all four majors. Other events use standard tiebreaks or match tiebreaks in place of a third set. Encode the format per event and check current rules rather than hardcoding one.
• Best of three versus best of five changes how much the stronger player is favoured, because longer matches reduce variance.
• Who serves first in the next set depends on who served last, including after a tiebreak.

Unit-test the recursion against known results: with equal p for both players, every symmetric state should give exactly 50 percent.

Before the first point, p for each player has to come from pre-match information: historical serve and return points won, adjusted for opponent strength and surface. Barnett and Clarke, writing in the IMA Journal of Management Mathematics in 2005, described combining a server's serve statistics with the returner's return statistics to estimate head-to-head serve probabilities and update forecasts during play. The pre-match modelling side is covered in more depth in the tennis match analysis guide linked below; the in-play question is what happens next.

Updating p during the match

Building a live model needs point sequences, and testing it fairly needs in-play prices with timestamps.

Jeff Sackmann's Match Charting Project on GitHub is a widely used public source of crowd-sourced point-by-point records, with its README stating over 5,000 charted matches. It is licensed CC BY-NC-SA 4.0, which means attribution is required and commercial use is not permitted, so check the licence against your use. Charted point sequences are suitable for testing the state machine and the parameter update, but they do not give you the in-play odds you need for market comparison.

For that, you need archived in-play prices from a data provider or exchange, or your own collection from a live feed. Live official scoring data for professional tennis is commercially licensed, so terms matter for anything beyond personal research.

A live model is only as current as its score feed. Broadcast pictures, official scoring feeds and odds feeds each arrive with different delays, and the order in which your system learns about a point is not the order it happened in.

Record receipt time for every event and every price. Without it, you cannot tell whether a price you compared against reflected the score you thought it did.

Expect markets to suspend between points. In-play markets commonly suspend around each point and re-open after it, and bets are often accepted only after a delay. A model that computes a price instantly still meets the market after that delay.

Guard against stale state. If the model's score disagrees with the score implied by the feed's sequence numbers, or no update arrives when one is expected, mark the state uncertain rather than pricing it confidently.

Handle interruptions explicitly. Rain delays, medical timeouts and retirements are not points, and retirement settlement rules differ by book.

Score in-play probabilities by state, not just by match. Compute log loss at fixed checkpoints, such as the start of each set, and check calibration in high-leverage states like break points and tiebreaks. Compare against no-vig in-play prices captured at the same timestamps. If the model is consistently worse than the market at checkpoints where both had the same score, the problem is the serve probabilities, not the Markov structure.

This page describes modelling methods and is not betting advice.