An Esports Data Report Flawless to the Last Decimal Point — With Nothing Inside

At 2:47 a.m. on 12 December 2026, in a rented flat in the Rungkut district of Surabaya, I opened an eighteen-page PDF sent over by the analytics department of an esports team. Four heat maps. Two win-probability tables broken down by time interval. A "risks to monitor" section with seven lines. Every figure carried two decimal places. Every claim had an arrow pointing back to a source cell.

I read it in nineteen minutes. Then I did what nobody else in that production chain did that night: I walked back up to the source.

The data provider had returned no records at all. The server returned an error code. The raw file was 0 bytes long. There was no match record, no player name, no timestamp.

And yet the report was full. Win probabilities were there. Form curves were there. Seven risk lines were there.

What kept me awake was not that someone had invented numbers. It was that nobody in that chain had to. The system filled itself in. And when a system fills itself in, it does so smoothly enough that nobody thinks to check.

A report skeleton designed to be complete will always generate content on its own, even when the data source is empty — and that is the single biggest risk facing esports analytics today.

Seven years earlier, I had stood on the other side of this story.

In 2026, I was the one filling in the blanks

I was a data coordinator for Surabaya United in Liga 1 at twenty-seven. Ahead of a match against Persib Bandung, I presented the coaching staff with a tidy report: 63 percent possession, more successful passes in the opponent's half, one and a half times as many entries into the box. My recommendation was clear: push the defensive line high, squeeze in the opposition half.

We lost 0-3. Two of the three goals came from counter-attacks driven straight into the space behind our full-backs.

I sat with the footage for three nights, pulling apart every phase. The metric I had skipped was not hidden: the opponent's PPDA. They were never on the back foot. They deliberately surrendered the ball, sat deep, and waited for the right moment to spring. The 63 percent possession figure was technically accurate and tactically meaningless.

I wrote a ten-page self-critique, sent it to the coaching staff, and proposed a cross-checking protocol before every match. Three independent sources. If there weren't three, say plainly that there weren't three.

The mistake in Surabaya taught me to interrogate data, not to trust it.

What I took from it was not "stop using numbers." It was that every number must answer three questions. Where did it come from. Under what conditions was it collected. And would I know if it disappeared.

The third question was the one I forgot for seven years.

World Cup 2026 and the lesson of what never appears on the scoresheet

In 2026 I was a data editor for a major football outlet in Indonesia. On the night of 30 June 2026, France met Argentina in Kazan. The whole newsroom criticised the French defence, said it was loose, said Mbappé was carrying the team alone.

I sat down and pulled apart France's tactical foul count in the middle third. Their per-match average across that tournament was unusually high, the highest among the teams that went deep. Those fouls never appeared in attacking stat sheets, never made the post-match bulletins, never featured in the photo montages. But they were what kept the French structure from being torn apart.

I wrote an analysis arguing that Mbappé did not win it alone. It drew two million views in twelve hours. A young coach in Vietnam shared it and invited me to collaborate.

From then on I hunted for defensive metrics the media ignored. Tactical fouls. Clearances. Off-ball runs.

World Cup 2026 lifted the trophy on tackles nobody remembers.

But there was something I only understood later, after I moved into data consultancy for esports: those invisible metrics only exist when the raw data exists. No footage, no coordinates, no event log — no tackle to remember. And worse: when the raw data vanishes, the report does not announce that it is empty. It simply goes quiet and prettier.

Esports is a faster, thinner and more fragile copy of football

When I started covering Southeast Asian esports for the Indonesian market, what struck me was not the players' skill. It was the speed of the data chain.

A football match has ninety minutes, twenty-two players, thousands of data points per minute, and a data-provider ecosystem that matured over two decades. An esports match can end in eighteen minutes. A best-of-five series can end in three hours. Patches change every two weeks. And the raw data usually sits with the publisher, not with the community.

That means the verification chain is far shorter. In football, if a metric is wrong, I have three other providers to cross-check against, plus the footage. In esports, I often have one source: sometimes a screenshot, sometimes a spreadsheet someone shared in a closed group.

Based on my experience covering several seasons of Southeast Asian esports, this industry has three layers. The top layer is the publisher, holding the patch and the server data. The middle layer is the teams, the tournament organisers and the streaming platforms. The bottom layer is the media, the sponsors, and derivative products such as community rankings, match previews and prediction models.

The problem is this: the bottom layer is the most crowded, the loudest, and the hardest to verify. A wrong community ranking will be read by hundreds of thousands. A machine-generated match preview will be reshared without anyone asking where its numbers came from.

During the transfer window the pressure is even greater. The market needs news every day. Teams need announcements. Fans need predictions. Data providers need traffic. When every party needs content, treating an empty report as a failure becomes almost the default.

The anatomy of one silence

Three failure modes produce an empty report that still looks full.

The first is a fetch failure. The source returns nothing. The server hangs. The connection drops. The raw file is 0 bytes. This is the loudest failure mode and the easiest to catch — if anyone actually looks at the raw file.

The second is a parser failure. The data arrives, but the processor cannot read it. The format changes. Field names change. A new patch shifts the structure of the event log. From the end user's perspective the result looks identical to the first: an empty array. But the cause is entirely different, and so is the fix.

The third is a routing failure. A document that does not belong to a given domain is nevertheless labelled as belonging to it. The label comes from a system default rather than from content. This one is the most dangerous because it does not produce an error. It produces a document that looks valid in the wrong place.

These three modes leave very different traces. But they share one property: if the system does not log the status code, the raw byte length and the parser's exit code, all three collapse into a single state — silence.

And silence, inside a complete report skeleton, always gets filled.

The design flaw: a field defined by another field

There is a design flaw I keep running into across the analytical frameworks teams and tournament organisers use, and it deserves to be named.

The "entities involved" field is defined by the instruction: "identify from the information points above." It sounds reasonable. But if the "information points above" are empty, this field is permanently empty too. It never throws an error, never warns, never halts the pipeline. It is simply empty.

In football, this is like a tactical brief that reads: "the starting eleven will be determined from the starting eleven." Nobody writes a sentence like that. But in data system design, that sentence shows up every day.

The result is a structural null, logically guaranteed, undetectable by inspecting any single field in isolation. You have to inspect the whole chain.

Generation pressure: why the system always chooses to fill

When I present this to an analytics group, the first response is always: "Then just add a null guard and it's solved."

I used to think so. Until I asked myself: if the null guard works correctly, what happens?

The report is blocked. No product. No bulletin. No prediction table. The analytics department has nothing to hand in. The client opens their inbox and finds it empty.

In every system I have worked in, the state of "empty" is treated as failure. Nobody praises a blank dashboard. Nobody sponsors a season with no bulletins. So systems are built never to be empty — not by improving the data source, but by loosening the conditions for filling.

This pressure does not come from technology. It comes from incentives.

Nine boxes in an analytical framework will always be filled, because an empty box is the only thing nobody wants to see.

In esports the pressure is stronger still, because tournament cycles are short. A tournament lasts three weeks. After three weeks the content is worthless. Nobody has time to wait for data to be verified. And when time is the scarcest resource, the final checking step is always the first one cut.

The tackles nobody remembers, esports edition

If you want to know whether an esports report is real, do not look at the flashy metrics. Look for the invisible ones.

In a team game, what decides a match usually does not sit in the kill scoreboard. It sits in the timing of rotations. In the distance between two players before a major objective spawns. In a team forcing an opponent to burn a healing ability twenty seconds earlier than planned. In whether the front line retreats before or after the back line gets pushed.

None of this appears in public stat sheets. It exists only if there is coordinate data, timing data, and a complete event log.

So this is my test: if a report writes about rotation timings, formation spacing and objective pressure tempo — without naming the raw data source, without a date, without a patch version — then there are two possibilities. Either the author has private data they are keeping quiet, or the author is writing from an empty source.

Based on my experience covering matches, the second possibility is far more common than this industry wants to admit.

Context variables: what a clean dataset never tells you

In 2026 the pandemic halted every league. I was a data consultant for a club in Jakarta and found myself with no matches to analyse.

Instead of waiting, I assembled data from forty closed-door friendly matches involving Southeast Asian teams. The result surprised me: without crowds, sideways passing rose by roughly eighteen percent and long-range shots fell by roughly nine percent. Match tempo slowed, and teams leaned toward safer options.

I sent the report to the board and proposed changing our pressing approach even in matches where opponents sat deep. After the league resumed, my club went seven matches unbeaten.

The lesson was not "empty stadiums are easier." It was that when context changes, the meaning of a number changes. The same metric, the same value, read under two different conditions, yields two opposite conclusions.

In esports there are even more context variables: connection latency, the tournament server version versus the practice server version, playing on a stage with a crowd versus in a closed room, a player crossing two time zones in the same week.

A clean dataset will tell you none of this. Which is why I never conclude from a dataset alone.

Clean data does not mean the truth.

The contrarian angle: the industry is blaming the wrong thing

When I tell the story of the eighteen-page PDF in Surabaya, the most common reaction is to blame artificial intelligence.

I think that reads the problem wrong.

First, generating content from an empty source is not a new behaviour. It is the default behaviour of any system built to always produce output. Humans did this long before machines. I did it in 2026, by hand, in Excel, with the confidence of a twenty-seven-year-old.

Second, when we say "the tool invented numbers," we implicitly accept that the tool is responsible for a design choice made by people. Nobody is forced to build a report skeleton that demands every cell be filled. That is a decision. And it was made because it was convenient.

Third, and this is the point I want to press hardest: sports analytics generally, and esports analytics specifically, has built excellent skills for detecting wrong data, and almost no skills for detecting missing data. We are trained to ask "is this number correct," not "is there a number to ask about at all."

The two questions sound similar but lead to entirely different systems. The first assumes data exists. The second assumes nothing.

And when you assume nothing, you discover something uncomfortable: most of the reports you have read in your career have never been tested with the second question.

Arguing against myself: a null guard is not the answer

At this point I have to argue against myself.

The natural technical response is to build a guard: if the input is empty, halt the pipeline. It sounds sensible. But guards break too, get disabled for deadlines, and get bypassed by an exception added at eleven o'clock at night before publication day.

And even if the guard works perfectly, it still does not solve the root problem: nobody wants to submit an empty report.

The real fix is not technical. It is that a report stating plainly "insufficient data to conclude" must be treated as a valid result, not a failure. In medicine, an inconclusive test is valuable information. In sports analytics, it is treated as weakness.

Until those incentives change, every null guard is just a coat of paint.

There is one more point I consider a bigger risk than a single fabricated report: a corrupted corpus.

A fabricated report is forgotten within a week. But two hundred fabricated reports stored in the same database begin to cross-reference each other. Report number twelve cites report number seven. Report number seven was built from an empty source. Six months later, those two reports become each other's evidence. And when someone raises a question, the answer will be: "two independent sources confirm it."

This is not a hypothetical. It is the normal operating mechanism of any knowledge base without a purification process.

Signals to track in the next cycle

During the transfer window, when the market is flooded with rumours about contracts, transfer fees and release clauses, data risk runs higher than usual. Money moves faster, information arrives later, and the pressure to reach a conclusion is greater.

There are five signals I will be tracking over the next six months.

Successful fetch rate. If a system cannot publish the share of records returning empty, it cannot detect its own incidents.

Null-guard coverage. Check whether any record reaches the final analytical layer with an empty data array. One record is enough to know the system is exposed.

Domain-label provenance. Whether the label is generated from content or from a default configuration. This is the simplest question and the least asked.

How many records have an "entities involved" field that merely echoes its own instruction. If that count is non-zero, the defect is systemic, not incidental.

And finally: back-test the old reports. Sample a few dozen published reports and look for any where every cell is filled in perfectly but no raw data source is attached.

I ran that last test on my own archive. The result forced me to rewrite my process.

What I think will make the difference

Sports analytics, in both football and esports, is entering a phase where data is no longer scarce. Everyone has data. Everyone has a dashboard. Everyone has a model.

The next scarce thing will be a data chain of custody. The ability to show which source a number came from, on which date it was collected, under which patch, under which match conditions, and which verification steps it passed through before reaching the reader.

Teams can copy a patch. They can copy a roster. They cannot copy a chain of custody built over years, because that demands patience rather than budget.

And in a market where thousands of bulletins are generated every week, patience may be the last remaining competitive advantage.

The question I leave for the next cycle is not how to get more data. It is: if all your data sources disappeared tomorrow, how long would it take you to know?