Esports has a promising set of conditions: a participant base unlike traditional sports, and pricing that may be less mature. I finished the fee-layer work and then stopped somewhere earlier — I cannot get odds data. This entry is about a path rejected by the data layer rather than the strategy layer.
| Condition | Detail |
|---|---|
| Different participant base | little overlap with traditional sports audiences |
| Fast-moving titles | patches, rosters and rules change often, so historical data decays quickly |
| Pricing maturity | below that of major traditional leagues |
| Books | comparatively thin |
Row three is the attraction; rows two and four are its price. These three usually arrive together — where pricing is immature, data is also hard to get and books are also thin. Not a coincidence: they are three symptoms of one cause, which is that few people work on it.
I verified the fee structure and it is no different from other categories — the same taker fee formula, the same rebate rules, weighted into the ladder by category weight. So there are no surprises on the cost side and the known arithmetic applies directly:
The value of having finished this layer: it is not the obstacle. If this path dies, it will not die on cost.
This is a measured result rather than an estimate: the mainstream odds data services I checked have no esports coverage at all.
Which means the entire methodology in devigging — gather odds from several books, devig, recover fair probabilities, compare against the quotes — has no input in this category. The method is ready and there is nothing to feed it.
Each alternative has its own problem:
| Alternative | Problem |
|---|---|
| Scrape bookmaker pages yourself | high build and maintenance cost, and liable to be blocked |
| A specialist esports data vendor | additional subscription — compute the cost first |
| Model it yourself without odds | needs team and player ratings, and patches invalidate history quickly |
| Use only book-internal information | gives up the external informational advantage and degrades to pure microstructure |
To be clear: I have not killed this path. A kill requires a reading, criteria and a verdict (see kill rules). This one stopped at the data layer and never entered testing.
| A kill | This | |
|---|---|---|
| Did it run | yes | no |
| Is there a reading | yes | no |
| Conclusion | "this road is closed" | "an input is missing" |
Keeping those apart matters: a kill is knowledge; a shelving is a to-do. If the odds problem is solved someday, this path must be re-evaluated — not dismissed by citing this page as though it had been tried.
The order should be: can I get the data → does the cost work → does the strategy work. Most people run it backwards, spend weeks producing an elegant strategy, and then discover there is nothing to feed it or that the data subscription exceeds the expected return.
Same shape as other lessons here: confirm your tooling can perform the action before hunting the opportunity, and confirm the subsidy arrives before depending on it — all instances of validate the precondition before researching the main body.
This path was not rejected by the strategy layer but by the data layer — the method exists and has nothing to consume. So its status here is shelved, not killed: "an input is missing" and "this road is closed" are different statements.