A public tipping record depends on trust. Readers want to know whether the tips are any good, and the honest way to answer is a record: every tip, the price it was given at, how it settled, and the running profit or loss at a flat stake. Losses included.
I built one recently for a high-volume sports tipping site. It reads every tip out of the published articles, stores it with its price and the event it belongs to, settles it from results, and publishes the record per tipster, per sport and per month.
The first full run produced a headline figure that looked good. That was the moment to be suspicious of it.
A number nobody has checked is a liability
Once a headline figure is on a page, people quote it. Editors put it in social posts. Tipsters mention it in their bylines. If it turns out to be wrong, correcting it is far more painful than never publishing it. Worse, a profit figure that is too kind is exactly the kind of error nobody reports.
So before the record went in front of anyone, I audited the settlements. Not the code: the outcomes. I took a sample of settled tips, opened the original article for each, found the real result by hand, and compared.
What the tipping record audit found
Most settlements were right. The ones that were wrong were wrong in a pattern, which is the useful kind of wrong.
| What I found | Why it happened | What the record does now |
|---|---|---|
| Racing tips matched to the wrong race | Writers often copy a bet block from an earlier article and change the horse. The block keeps the old course and race time. | It looks for the horse by name in every stored race around the day the tip went live, and the race the horse actually ran in replaces the copied course and time. |
| Copied times trusted as much as real ones | Every event time was treated as equally reliable, wherever it came from. | Each time carries where it came from. A time from the data feed or from a reader's click outranks a copied block. Several markets under one course and time are flagged as a likely copy. |
| Losses booked on thin evidence | A horse missing from the top three was treated as beaten, even when the full result had not arrived. | A tip is never booked as lost without the full result. Without it, the tip waits. |
| Long-range tips settled from the wrong run | A tip for a named race months away was matched to the same horse running somewhere else that week. | Long-range tips wait for their own race and are never settled from a run elsewhere. |
| Unpriced tips counted in profit | A tip with no price still took part in the profit sum. | Unpriced tips stay on the record but are left out of profit. |
| Junk in selection names | Some selection names came from click data, and a few clicks were automated scanners sending probe strings. | Anything that is not a name is cleared, and a real name can fill the gap later. |
None of these were exotic. Each one is the gap between how the code assumed people work and how they really work. Copying the last block and editing it is a perfectly sensible thing for a busy writer to do. The record had to cope with it.
Waiting is an honest state
The biggest change was giving the record permission to say "not yet". Early versions tried hard to settle everything, because an unsettled tip looks like a gap. But a tip settled on a guess is worse than a tip marked as waiting. The reader can see the waiting tip. They cannot see the guess.
The same thinking runs through the rest of the record:
- A settlement log with resettle. Every settlement records what it was based on. When the rules improve, old tips can be settled again and the log shows the change.
- Voids for abandoned events, with the reason shown.
- Unsupported markets say so. If the record cannot settle a market type yet, the tip is listed with that reason rather than quietly dropped.
- No backfilled prices. If a price was not captured when the tip went out, nobody gets to choose one later.
- Consistent each-way maths, dead heats and non-runners handled the same way everywhere.
- Results kept for good. Once a result is stored, a later feed hiccup cannot unsettle it.
Audit outcomes, not just code
I had tests. They passed. They tested what I thought the data looked like. The audit tested what the data actually looked like, and that is a different job. If you are about to publish any computed figure, whether it is a win rate, a conversion rate, a saving or an uptime percentage, my checklist is short:
- Pick a sample of the records behind the number, including some of the best and worst.
- Work each one out by hand from the original source.
- Look for a pattern in the disagreements. A pattern means a rule to fix. Random noise means a data source to question.
- Decide what the system should say when it does not know, and make sure it says that rather than guessing.
- Only then put the number on a page.
The record is less flattering than the first run. It is also the version I would be happy to defend line by line, which is the point of having one.