Nickname Change Keeps Old Leaderboard Row, 31% Rebuy the Wrong Seat

A player who changes their nickname on a Croatian-facing poker or casino platform can keep the old handle's leaderboard row for days, and the seat-preservation logic behind multi-table tournaments means roughly 31% of rebuys in fast blind structures land on a seat the player no longer owns. That second figure comes from operator-side data shared with affiliates in late 2024: across 14 tournament series on three networks, 30.8% of rebuys registered within 90 seconds of a table rebalance were applied to the pre-rebalance seat assignment rather than the player's current table. The nickname issue is older and narrower, but it exposes the same underlying problem — identity and seat state are cached separately from the account record, and the caches don't always agree.

Why nickname changes leave a ghost row

Most platforms treat a display name as an attribute of the session, not the account. When you change it, the new string propagates to the lobby, the chat, and new table instances immediately. The leaderboard is different. Leaderboards are usually materialised views — a snapshot table rebuilt on a schedule, often hourly, sometimes only once a day for weekly or monthly boards. The row is keyed on player_id but displays whatever nickname value was current when the snapshot ran.

That produces a predictable artefact: your old handle sits on the board with your points, your new handle appears nowhere or appears as a fresh entry with zero, and if the platform also allows nickname reuse, a second player can register the abandoned name and inherit the visual association. On Croatian-facing sites this is more visible than on larger international brands simply because the player pools are smaller. A €5,000 monthly leaderboard on a site with 8,000 active cash players has maybe 200 qualifying rows. Your ghost row is 0.5% of the visible board and it's sitting in the top 40 where everyone you play against can see it.

The fix operators use is a nickname alias table — old names resolve to the current player_id for display purposes. Roughly two-thirds of the platforms I've audited in the region run this. The rest either accept the stale row as cosmetic or, worse, let it persist because the leaderboard job reads from a denormalised copy that nobody owns.

The rebuy problem is the same bug with money attached

Seat assignment in multi-table tournaments is a two-phase commit. The client requests a seat, the tournament engine allocates one, and the client acknowledges. Rebuys during a rebalance window — typically 30 to 120 seconds around a table break — can be acknowledged against the old allocation. The player pays, the chips are credited, but the seat pointer is stale. In fast structures (6-max turbos, hyper-turbos, anything with blinds up every 3 minutes) the rebalance windows are frequent enough that this accumulates.

The 30.8% figure is the share of rebuys affected, not the share of players. A player rebuying three times in a turbo has three chances to hit the window. In a 180-player hyper with 2-minute levels, the expected number of rebalance windows during the rebuy period is between four and six. That's a lot of exposure.

What happens next depends on the network. Some engines auto-correct on the next hand — the player is moved to the correct table with chips intact, and the only cost is a few seconds of confusion. Others leave the player at the old seat until the next scheduled break, which in a turbo can mean playing two or three orbits short-handed or, in the worst case, posting blinds at a table they've already been broken from. That last scenario is rare but it happens, and it's the one that generates support tickets.

What Croatian players actually see

Croatia's market is small and heavily regulated. The 2023 amendments to the Law on Games of Chance tightened advertising and pushed a chunk of the affiliate ecosystem offshore, but the operational reality for players on licensed sites (and the .com sites that still accept Croatian traffic) is that most of the software is white-label. The same back end runs a Croatian skin, a Serbian skin, and a Bosnian skin, often with the same leaderboard infrastructure.

That matters because leaderboard bugs that would be fixed on a flagship brand get deprioritised on a skin with 4,000 monthly actives. The nickname ghost row is a cosmetic ticket. The rebuy seat bug is a money ticket, but only when someone complains, and most players who lose 15 big blinds to a misapplied rebuy don't file — they just stop rebuying.

There's a behavioural number worth sitting with. In the operator dataset referenced above, players who experienced a misapplied rebuy once had a 22% lower probability of rebuying again in the same session. Twice, and it dropped to 41% lower. That's not a support cost. That's a retention cost, and it's invisible on the P&L because it looks like variance in rebuy behaviour rather than a bug.

The 90-second window is where the money is

If you play turbos on any Croatian-accessible network, the practical advice is straightforward: don't rebuy in the 90 seconds after a table break. Wait for the next hand to complete, confirm you're at the right table, then rebuy. That's not a fix, it's a workaround, and it costs you roughly one big blind in a hyper — which is less than the expected loss from a misapplied rebuy.

For cash game players the nickname issue is mostly cosmetic, but it has one non-cosmetic consequence: rakeback and bonus tracking. If your nickname change triggers a new player_id on a skin that keys bonuses on display name rather than account ID — and a handful still do — your progress resets. This is rarer than it was five years ago, but it's not extinct. I've seen two Croatian-facing sites in the last 18 months where a nickname change mid-bonus silently voided the remaining wagering progress. Both fixed it after tickets. Neither advertised the fix.

The regulatory angle nobody asks about

Croatia's regulator, the Ministry of Finance's gaming division, requires licensed operators to maintain accurate player records and to be able to produce them on request. A leaderboard row displaying a nickname that no longer belongs to the account is, technically, an inaccurate record. In practice nobody is auditing leaderboard snapshots. The compliance requirement is about identity verification and transaction history, not display names.

But there's a sharper edge. If a nickname can be reused by a different player while the old row persists, and if that row is used for any promotional qualification — a leaderboard prize, a freeroll seat, a rakeback tier — then you have a payment attached to a display string that no longer maps to the account that earned it. That's the kind of thing that becomes a problem the first time someone wins a €2,000 leaderboard prize and the payout goes to the wrong player_id. It hasn't happened publicly in Croatia. It has happened on a Maltese-licensed network, and the resolution took six weeks.

Operators know this. The ones running alias tables sleep fine. The ones running denormalised snapshots are one support ticket away from a very awkward conversation.

Why the fix is cheap and still not done

An alias table is maybe 40 lines of code and a nightly job. The reason it isn't universal is that leaderboard infrastructure is often owned by a third party — a gamification vendor, a CRM tool, a promotions engine bolted on after launch. Changing the schema means a vendor ticket, a change request, a quote. For a skin with 4,000 actives, the quote is more than the leaderboard is worth.

So the ghost row stays. The player sees their old name, shrugs, and moves on. The rebuy bug stays because fixing it means touching the tournament engine, which is the one component nobody wants to touch. And the 31% keeps happening, quietly, in turbos, at 11pm on a Sunday, to players who then close the client and don't come back.

The open question is whether the next round of Croatian licensing renewals will include any requirement around display-name integrity or seat-state accuracy. Nothing in the current framework suggests it will. But the retention data says the operators should care regardless of what the regulator asks — a 22% drop in rebuy probability after a single bad experience is not a rounding error, and it's happening in the format that generates the most rake per hour.