Revenue was flat for three months, which the owner read as stability. Same monthly total, give or take, a nice steady line. The city closed in March. The line had been flat because the same nineteen people were buying more each month while everyone else quietly stopped logging in, and by the time the money moved, the community it came from had already gone.
Store data is the last thing to react when a server is in trouble, and the first thing owners look at. Read it the right way, though, and it turns into an early warning system, because the composition of your sales changes weeks before the total does. Here are the five numbers worth checking monthly, what each one means when it moves, and what to actually do about it.
Revenue is a lagging indicator, and a flattering one
Total revenue answers "did people spend money", which is the least diagnostic question available. It lags because purchasing decisions trail engagement by weeks: a player who is drifting away today bought their supporter tier three weeks ago and will simply not renew, quietly, later.
So keep the total for your accounts and stop using it to judge the health of the server. Everything below is more useful and none of it takes longer than twenty minutes a month to pull together.
The five numbers
Distinct buyers. How many different people bought anything this month. This is the headline number. Revenue flat with distinct buyers falling means your base is shrinking and your remaining regulars are covering the gap. That is the pattern in the opening paragraph, and it is the single most reliable early warning you have.
Repeat rate. What share of this month's buyers also bought in the previous three months. Rising repeat rate with falling distinct buyers is the same story from another angle: nobody new is converting. A healthy store has a steady trickle of first time buyers every single month.
New player conversion. Of the people who joined the city this month, what fraction bought anything. You need your own join data alongside store data to get this, and it is worth the joining up. When it falls, the problem is almost never the store. It is the first hour of the player experience.
Package concentration. What share of revenue comes from your top selling package. Concentration above roughly half means your store is one product, and anything that damages that product, a rules change, a balance pass, a competitor doing it better, takes most of your income with it.
Refund and chargeback rate. Both as a percentage of orders. Refunds trending up is a delivery or expectation problem. Chargebacks trending up is a trust problem, and it is the one that can cost you the ability to take payments at all. Neither is about the money, both are about what they tell you.
Reading the spikes
Every server gets sales spikes after an update, a promotion or a video. The spike itself means nothing. What matters is the baseline afterwards.
A spike that lifts the baseline means the update gave people a reason to invest in staying. A spike that returns to exactly the previous line means you sold novelty, which is fine occasionally and hollow as a strategy. Compare the four weeks before with the four weeks after, not the spike day with the day before.
The same logic applies to a promotion. A discount that pulls next month's purchases into this month looks like a great week and shows up as a hole later. Check the following month before calling it a win.
The signals that look like good news
Priority queue sales rising. People are paying to skip a queue, so revenue is up, so everyone is happy. What it actually tells you is that your peak capacity is too small for your audience, and every non paying player is having a worse evening. Treat it as a capacity alarm that happens to make money.
Average order value rising while orders fall. Your most committed players are subsidising a shrinking base. Nice this month. Grim by the quarter.
One package doing enormous numbers. See concentration above. Enjoy it and start building the second thing.
What to do with each signal
- Distinct buyers falling: work on retention and the first hour, not the store. Store changes cannot fix a leaky city.
- New player conversion falling: look at onboarding, the first job, and whether anyone speaks to a new arrival in their first ten minutes.
- Concentration too high: build a second package that appeals to a different motivation, not a bigger version of the same one.
- Refunds up: check delivery. It is almost always delivery, or a package description that promised something different from what arrived.
- Chargebacks up: answer support faster, publish your policy clearly, and refund proactively rather than arguing.
- Everything flat: ship content. Sales follow content with a lag of weeks, and a city that has not changed in two months is a city people stop thinking about.
That last one is the least glamorous and the most reliable. A new job, a new area, a new activity, shipped on a schedule people can predict, does more for store numbers than any pricing experiment. If you are building the content yourself, the walkthrough on how ESX jobs and grades are put together is a good starting point, and if the schedule matters more than the building, buying a ready made resource and spending your weekend on the roleplay design around it is a perfectly respectable trade.
Joining store data to server data
Every number above gets sharper when you put it next to something from the game server, and almost nobody does the join because it lives in two places.
The three pairings worth building once and reusing forever:
Buyers against active players. Distinct buyers divided by distinct players who logged in that month. This is your conversion rate, and it is the number that tells you whether a change to the store did anything, because it controls for how busy the city was.
Purchase date against join date. How long after someone's first session do they buy. If your median is day two, your store is doing the convincing. If it is day thirty, your community is, and you should be spending on retention rather than on packages.
Buyers against playtime. Do your buyers play more than your non buyers, and did they already play more before they bought? This one prevents the most expensive mistake in server monetisation, which is concluding that selling more caused people to play more when the causation runs the other way.
Pulling the server side of that is a query against your own database rather than anything clever:
SELECT DATE(first_seen) AS joined, COUNT(*) AS players
FROM users
WHERE first_seen > NOW() - INTERVAL 90 DAY
GROUP BY DATE(first_seen)
ORDER BY joined;Your column names will differ, and plenty of servers do not record a first seen date at all, which is worth fixing today because you cannot backfill it later. Export the store side to a spreadsheet once a month and keep both in the same file.
The whole thing takes an hour to set up and about ten minutes a month thereafter, and it turns the five numbers above from a dashboard into something you can actually act on.
The monthly ritual
Twenty minutes, same day each month, five numbers in a spreadsheet that goes back a year. Distinct buyers, repeat rate, new player conversion, top package share, refund rate. Then one line at the bottom: what you are going to do about whichever one moved most.
The spreadsheet matters more than the analysis. A single month's numbers tell you almost nothing. Twelve months of the same five numbers will tell you exactly when the trouble started, and usually what you were doing at the time.
Practical takeaway
Watch distinct buyers rather than revenue, watch the baseline rather than the spike, treat rising queue sales as a capacity warning, and treat refunds as a delivery bug rather than a cost of business. Do it monthly, write it down, and the store stops being an accounting exercise and starts being an instrument panel.
The city in the opening had every one of those signals lit up by January. Nobody was looking at anything except the flat line, which was, right until the end, the most reassuring number on the page.
