DEV Community: Mark Veenema

My win rate was 33%, 57% and 67% at the same time

Mark Veenema — Tue, 13 Oct 2026 13:29:48 +0000

My site showed one win rate for the Premier League on Tuesday morning. Three numbers, actually. The competition block on the tips page said 33.3%. The archive, filtered to Premier League, said 67%. And after I fixed both, they agreed on 57.1%, until I found 33.3% again on a different page an hour later.

Same database. Same table. Same four tips. Nobody had touched the data.

How I found it

Not from a test. I was looking at the Premier League tips page, read "33.3% of our published tips won", and then opened the archive the way a visitor would to check it. The archive said 67%.

That is the worst kind of bug on a site whose whole point is a public track record. Every pick is published before kickoff and settled afterwards, losses included, so that anyone can check the numbers. If two pages disagree, the checking is broken, even when nothing is technically wrong.

So I counted by hand. The Premier League main tips since our public archive starts:

SELECT result, COUNT(*) AS n
FROM betting_tips
WHERE league_id = 39
  AND is_extra = 0
  AND tip_date >= '2026-05-11'
GROUP BY result;

+-----------+---+
| result    | n |
+-----------+---+
| win       | 2 |
| loss      | 1 |
| half_loss | 1 |
+-----------+---+

Four tips. Getting from four tips to three different percentages took four separate mistakes.

Layer one: two Premier Leagues

The archive filter was built from the league name:

if (!empty($row['league'])) $leagues[$row['league']] = $row['league'];

<tr class="dsp-row" data-league="<?= esc_attr($row['league']) ?>">

"Premier League" is England. It is also Ukraine. Both arrive from the fixtures API with exactly that name, and both had tips in the table. Picking "Premier League" in the dropdown quietly merged two countries into one row of the filter. The table also had a third spelling, Premier League England, from an older import, which showed up as its own entry.

The fix keys the filter on the ID and only uses the name as a label:

function dsp_arch_league_key($row) {
    $id = isset($row['league_id']) ? intval($row['league_id']) : 0;
    return $id > 0 ? 'id' . $id : (string)($row['league'] ?? '');
}

That was a real bug, but it didn't explain the gap. With Ukraine filtered out, the archive still said 67% and the block still said 33.3%.

Layer two: what a half win is worth

Most of our tips are on Asian handicap lines, and quarter lines settle as half wins and half losses. A bet on -0.25 that ends in a draw loses half the stake and refunds the other half. That is not a win, and it is not a full loss either.

Three pieces of code had three opinions about it.

The archive summary, in JavaScript, ignored half results completely:

if (row.dataset.result === 'win')  wins++;
if (row.dataset.result === 'loss') losses++;

var winrate = Math.round(wins / (wins + losses) * 100);

The competition block, in SQL, counted a half win as half a win, but a half loss as a full loss, because it was in the denominator at full weight:

ROUND((SUM(result='win') + 0.5*SUM(result='half_win'))
      / NULLIF(SUM(result IN ('win','loss','half_win','half_loss')), 0) * 100, 1)

And the analysis script I used to write the articles on the site counted both halves as halves:

W = wins + 0.5 * half_wins
L = losses + 0.5 * half_losses
rate = W / (W + L)

Run the same four tips through each:

formula	result
ignore halves	2 / 3 = 66.7%
half win counts half, half loss counts full	2 / 4 = 50.0%
both halves count half	2 / 3.5 = 57.1%

None of these is wrong in isolation. They are three different questions. The problem was that all three were labelled "win rate".

I picked the third: it is the only one where a half loss and a half win cancel out, which is what they do to your stake. Then I put the formula in the text next to the number, so a reader can redo it.

Layer three: since when?

The block didn't say 50%, though. It said 33.3%. The last difference was the window.

The archive starts on 11 May 2026, the day the current model setup went live, and that date already lived in one constant:

define('DSP_TRACK_SINCE', '2026-05-11');

The archive query used it. The competition block didn't:

FROM betting_tips
WHERE $where AND is_extra = 0

So the block counted every main tip since March, including two months of an older model, while the archive next to it counted from May. For the Premier League that was 18 tips at 33.3% against 4 tips at 57.1%. Both numbers were correctly computed and neither could be checked against the other, because a visitor can only see the archive.

That is the rule I ended up with: if a reader cannot reproduce a number from the public archive, the number shouldn't be on the site. Every block now counts from DSP_TRACK_SINCE, and says so in the label: "57.1% of our main tips won, 4 settled since 11 May 2026".

Layer four: the copies

I patched the block and the archive, checked both pages, and called it done.

An hour later the competitions overview showed 33.3% on the Premier League card. That card came from a different shortcode, with its own copy of the old query, which I hadn't touched because I didn't know it existed.

This time I searched for the formula instead of the function name:

grep -n "result='win'" wp-content/plugins/betting-tips/betting-tips.php

Fifteen hits. Four of them computed a win rate that ended up on a public page:

the competition block on each tips page
the cards on the competitions overview
a second, older accuracy shortcode with the same SQL
the archive summary, in JavaScript, in the same file

Two more lived in shortcodes that no published page used any more. I checked that with a query rather than from memory:

SELECT COUNT(*) FROM wp_posts
WHERE post_status = 'publish'
  AND post_content LIKE '%[monthly_stats%';

Zero. They stay dead, and they are next on the list to be deleted, so nobody revives them with the old formula.

The fix I haven't finished

Tuesday's patch brought all four copies in line. They now use the same window, the same formula and the same minimum of three settled tips. But they are still four copies. The next person to add a fifth block will copy whichever one is closest, and the drift starts again.

The real fix is one function that owns the definition:

function dsp_win_rate(mysqli $db, string $where): ?array {
    $since = DSP_TRACK_SINCE;
    $r = $db->query(
        "SELECT SUM(result='win') AS w,      SUM(result='loss') AS l,
                SUM(result='half_win') AS hw, SUM(result='half_loss') AS hl
         FROM betting_tips
         WHERE is_extra = 0 AND tip_date >= '$since' AND $where"
    )->fetch_assoc();

    $W = $r['w'] + 0.5 * $r['hw'];
    $L = $r['l'] + 0.5 * $r['hl'];
    if ($W + $L == 0) return null;

    return [
        'rate'    => round(100 * $W / ($W + $L), 1),
        'settled' => (int)($r['w'] + $r['l'] + $r['hw'] + $r['hl']),
    ];
}

The JavaScript side is the awkward one, because it counts rows in the browser after filtering. It has to implement the same formula a second time, so it gets a comment pointing at the PHP function, and a check that runs after every deploy:

import re, subprocess

def pct(url, pattern):
    html = subprocess.run(['curl', '-s', url], capture_output=True, text=True).stdout
    m = re.search(pattern, html)
    return m.group(1) if m else None

block = pct('https://dailysportpick.com/tips/premier-league-tips/',
            r'dsp-league-acc-pct[^>]*>\s*([\d.]+)%')
card  = pct('https://dailysportpick.com/competitions/',
            r'Premier League</span>.*?([\d.]+)% win rate')

assert block == card, f'block says {block}, card says {card}'

It is crude. It would have caught the fourth layer an hour before I did.

What I took from it

A rate without a denominator and a window is not a number. "Win rate" meant three different things in three files. The label was identical, and the label was the only part anyone read.

Half outcomes are where definitions split. With only wins and losses, every reasonable formula agrees. The moment a result can be worth half, each developer makes a choice, usually without noticing it is a choice.

Grep for the formula, not the function. I searched for the shortcode I knew about and fixed it. Searching for result='win' found the three I didn't.

The public record is the source of truth, so everything else has to be derived from it. If the archive is what readers can check, any number that uses a different window or filter is unverifiable, and an unverifiable number on a track-record site does more damage than a low one.

Fixing the copies is not the same as removing them. I'm writing this partly so that the next commit actually happens.

The numbers in this post come from Daily Sport Pick, a football prediction site I run on my own. It publishes every pick before kickoff and keeps the losses in the archive, which is exactly why three numbers for one league was a problem worth a morning.

My pipeline ran green for 8 days while importing nothing

Mark Veenema — Wed, 07 Oct 2026 14:22:42 +0000

Every morning at 13:20 a cron job on my VPS imports holiday park accommodations from eleven affiliate XML feeds. Every morning it exited 0. The log said "klaar" (done). Nothing in Sentry, nothing in the mail.

For eight days, one of those eleven feeds imported exactly zero rows.

How I found it

Not from an alert. I was adding a column to a dashboard and noticed one provider's parks all had the same stale timestamp:

SELECT adverteerder,
       MAX(laatste_feed_seen) AS laatst,
       COUNT(*)               AS rijen
FROM accommodaties
WHERE actief = 1
GROUP BY adverteerder
ORDER BY laatst;

+--------------+---------------------+-------+
| adverteerder | laatst              | rijen |
+--------------+---------------------+-------+
| Landal       | 2025-09-08 13:21:04 |  1126 |
| Roompot      | 2025-09-16 13:22:11 |  1402 |
| EuroParcs    | 2025-09-16 13:22:40 |   389 |
| ...          | 2025-09-16 ...      |   ... |

Ten providers from yesterday. One from eight days ago, across 1126 rows. Nothing had errored. The feed had simply stopped matching anything my parser looked for.

Layer one: the country filter

The script starts by throwing away everything outside the Netherlands:

if eigenschap(p, 'country') != 'Nederland':
    continue

The feed used to say Nederland. It now says NL. Every single product hit that continue on the first line of the loop, so the parser did its full run over 1887 products and wrote nothing. No parse error, because nothing got far enough to parse.

NL_CODES = ('NL', 'NLD', 'Nederland')

if eigenschap(p, 'country') not in NL_CODES:
    continue

I expected that to be the whole bug. It was the first of four.

Layer two: renamed fields

With the filter fixed, products got through, and every one of them came out with nulls where the useful data should be. The provider had migrated the feed to a new schema and renamed four fields:

old	new
`ParkCode`	`parkID`
`city`	`place`
`zipcode`	`postal_code`
`province`	`region`

Any sensible parser asked for a missing field returns None. Mine returned None four times per product and wrote the row anyway, because every column except the key was nullable.

The region rename came with a value change too. Provinces arrived in English, underscored:

REGIO_MAP = {
    'North_Holland': 'Noord-Holland',
    'South_Holland': 'Zuid-Holland',
    'Wadden':        'Friesland',
}

def landal_provincie(p):
    r = eigenschap(p, 'region')
    return REGIO_MAP.get(r, r)

Wadden is not a province at all, it is an island group. It maps to Friesland for my purposes. A straight string pass-through would have created a province page for a thing that is not a province.

Layer three: the field that kept its name and changed its meaning

This was the expensive one, and it is the reason I am writing this post.

<name> still existed. It was still a string. It still looked completely reasonable:

<product>
  <name>Amerongse Berg</name>
  ...

In the old feed, <name> was the accommodation name: "Veluwelodge XL 6 personen". In the new feed, <name> is the park name, and the accommodation name moved to a different element.

So my parser ran clean, my import reported success, and it inserted 1887 accommodations all called "Amerongse Berg". Rows where every unique thing about the accommodation had been replaced by the name of the site it sits on.

I shipped that. It went live for about twenty minutes before I noticed a category page listing the same lodge forty times.

DELETE FROM accommodaties
WHERE adverteerder = 'Landal'
  AND aangemaakt_op >= CURDATE();

The fix reads both, preferring the explicit park field and falling back to the old element:

code = eigenschap(p, 'parkID') or vol_id.split('_')[0]
naam = eigenschap(p, 'parkName') or tekst_van(p, 'name')

A renamed field fails loudly. A repurposed field fails silently, passes every type check you have, and gets committed.

Layer four: the IDs changed

The last layer: my primary key for an accommodation was a SHA1 hash of the old product ID. The new feed issues different product IDs. Every row in the new import was therefore new, and the 1126 existing rows were orphans with no path back.

What survived the migration was the affiliate URL, which carries both IDs as query params. So I rebuilt the key from the URL:

def bestaande_landal_sleutels(cur):
    import re, urllib.parse
    cur.execute("SELECT affiliate_url FROM accommodaties "
                "WHERE adverteerder=%s AND actief=1", (ADVERTEERDER,))
    uit = set()
    for (url,) in cur.fetchall():
        u  = urllib.parse.unquote(url or '')
        mp = re.search(r'park=([A-Za-z0-9]+)', u)
        ma = re.search(r'accommodation=([A-Za-z0-9_-]+)', u)
        if mp and ma:
            uit.add(f"{mp.group(1)}_{ma.group(1)}")
    return uit

A one-off migration script matched old rows to new IDs through that set: 1033 updated, 93 deactivated as genuinely gone, and 114 duplicates surfaced that had been quietly sitting in the table for months. The duplicates were not caused by this bug. The bug just made me look.

The brake I added afterwards

The other half of the fix is a brake on the importer itself. New products are no longer inserted blind; they have to already exist, or they get counted and skipped:

if u['acc_id'] not in bestaand:
    telling['nieuw_overgeslagen'] = telling.get('nieuw_overgeslagen', 0) + 1
    continue

That counter is the actual alert. A healthy run skips a handful. A run that skips 1800 means the feed changed shape again, and the number lands in the log instead of 1800 junk rows landing in the database.

The script I am glad I had not written yet

The same week, I had been planning a cleanup job to deactivate accommodations that disappear from their feed. Stale inventory is a real problem: a lodge that no longer exists is a dead link and a bad search result.

If that script had existed during those eight days, it would have deactivated all 1126 Landal accommodations. Correctly, by its own logic. They were absent from the parse result on every single run.

So when I did write it, the rule went in first:

DAGEN   = 5    # comfortably above the daily cron interval
MAX_PCT = 20   # more than this share of one source: skip the source
MAX_ABS = 50   # and never more than this many at once per source

Mass disappearance is a parser symptom, not an inventory one. Real inventory decays a few rows at a time. If twenty percent of a provider vanishes overnight, the thing that broke is my code, and the correct response is to refuse to act and say so.

Ordering matters as much as the thresholds. The deactivation job runs at 13:30, after every fetcher has finished (last one at 13:25) and before the page generator at 13:35. Run it first and it deactivates based on yesterday's data; run it last and it publishes pages for accommodations it is about to retire.

What I took from it

Exit code 0 means the script finished, not that it worked. Mine finished eight times, beautifully, having written nothing.

Count what you skip, not just what you write. Every continue in a parse loop is a silent discard. One counter per skip reason, logged every run, would have caught this on day one.

Freshness is a first-class metric. MAX(laatste_feed_seen) per source, compared against the cron interval, is a four-line query and the single highest-value check in the whole pipeline. It is now the thing I look at first.

A field that keeps its name and changes its meaning is the worst case. No type error, no missing key, no exception. Just 1887 rows of plausible nonsense. The only defence is asserting on values, not shapes: if every product in a batch shares one name, something is wrong regardless of whether it validates.

Write the circuit breaker before the destructive job, not after. I got lucky on the ordering of two tasks on a list. That is not a strategy.

If you want the practical version rather than the incident, I wrote the three checks up separately: Three checks that catch a silently broken data pipeline.

The pipeline feeds Parkzie, a Dutch holiday park comparison site I run on my own. Eleven feeds, three languages, one person, which is exactly the setup where a silent failure gets to live for eight days.